Kubernetes容器調度怎么使用

這篇文章主要講解了“Kubernetes容器調度怎么使用”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“Kubernetes容器調度怎么使用”吧！

節點調度

根據原生的Kubernetes行為，默認情況下，Rancher 2.0工作負載中的pod將分布在可調度且具有足夠可用容量的節點（主機）上。但就像1.6版本一樣，Rancher 2.0也有助于：

• 在特定節點上運行所有pod

• 使用標簽進行節點調度

以下是1.6 UI中的調度方式。Rancher允許您在特定主機上運行所有容器，指定硬/軟主機標簽，或在部署服務時使用親和性／反親和性規則。

以下是Rancher 2.0中對應的節點調度UI，它在部署工作負載時提供相同的功能。

Rancher使用底層的原生Kubernetes構造來指定節點的親和性/反親和性。

下面的示例中我們將來看看如何使用節點調度選項來調度工作負載pod，然后看看Kubernetes YAML規范和Rancher 1.6 Docker Compose配置的對比。

示例：在特定節點上運行所有Pod

在部署工作負載（導航到Cluster> Project> Workloads）時，可以將工作負載中的所有pod調度到特定節點。

在這里，我使用特定節點上的nginx鏡像部署scale = 2的工作負載。

如果某節點有足夠的計算資源可用，Rancher將選擇該節點；如果使用hostPort，則不會發生端口沖突。如果該工作負載使用與另一個工作負載沖突的nodePort來對外暴露，那么部署是可以成功創建的，但它不會創建nodePort服務。如此一來，工作負載則完全不會暴露了。

在“工作負載/Workload”選項卡上，您可以按節點列出工作負載。在此，我可以看到我的Nginx工作負載的兩個pod都安排在指定的節點上了：

Kubernetes pod規范中的調度規則如下所示：

示例：主機標簽的親和性/反親和性**

我在Rancher 2.0集群中向node1添加了標簽foo = bar，以測試基于標簽的節點調度規則。

主機標簽親和性：硬

下圖展示了如何在Rancher 2.0 UI中指定主機標簽的親和性規則。硬親和性規則意味著所選主機必須滿足所有調度規則。如果找不到此類主機，則工作負載將無法部署。

在PodSpec YAML中，此規則將轉換為字段nodeAffinity。另外請注意，我已經包含了Rancher 1.6 docker-compose.yml以使用標簽實現相同的調度行為。

主機標簽親和性：軟

如果您是Rancher 1.6用戶，那么您一定知道軟親和性規則意味著調度程序會嘗試按規則部署應用程序，但即使有主機不滿足規則也可以成功部署。以下是如何在Rancher 2.0 UI中指定此規則：

pod的相應YAML規范如下所示：

主機標簽反親和性

除了key = value主機標簽匹配規則外，Kubernetes調度結構還支持以下運算符：

因此，要實現反親和性，可以使用運算符NotIn和DoesNotExist作為節點標簽。

使用容器標簽進行調度

Rancher 1.6中的這一功能允許您將容器調度到具有特定標簽的容器的主機。要在Rancher 2.0上執行此操作，請使用Kubernetes inter-pod親和和反親和功能：

Kubernetes允許您根據pod標簽而不是節點標簽來約束pod可以被調度到哪些節點。

Rancher 1.6中最常用的調度功能之一是使用容器上的標簽對服務本身進行反親和。要在Rancher 2.0中復制此行為，我們可以在Kubernetes YAML規范中使用pod反親和構造。例如，可以考慮使用Nginx Web工作負載。要確保此工作負載中的pod不在同一主機上，您可以使用podAntiAffinity構造，如下所示。通過使用標簽指定podAntiAffinity，我們可以確保每個Nginx副本不在單個節點上共存。

使用Rancher CLI，可以將此工作負載部署到Kubernetes集群上。請注意，上面的部署指定了三個副本，并且我在Kubernetes集群中有三個可調度節點。

由于指定了podAntiAffinity，因此三個pod最終位于不同的節點上。為了進一步檢查podAntiAffinity的應用方式，我可以將部署擴展到四個pod。請注意，由于調度程序無法找到滿足podAntiAffinityrule的另一個節點，因此無法調度第四個pod。

基于資源的調度

在Rancher 1.6中創建服務時，可以在UI的“安全/主機”選項卡中指定內存預留和mCPU預留。Cattle會將服務的容器安排到具有足夠可用計算資源的主機上。

在Rancher 2.0中，您可以使用pod容器規范下的resources.requests.memory和resources.requests.cpu指定工作負載pod所需的內存和CPU資源。

指定這些資源請求時，Kubernetes調度程序會將pod分配給具有足夠容量的節點。

僅給主機調度特定服務

Rancher 1.6能夠在主機上指定容器標簽，從而只將特定容器調度給它。

要在Rancher 2.0中實現此目的，可以在pod規范中使用相應的Kubernetes的“添加節點taints（如主機標簽）并使用容差”的功能：

全局服務

在Rancher 1.6中，全局服務是指在環境中的每個主機上部署容器的服務：

如果服務的標簽為io.rancher.scheduler.global：'true'，則Rancher 1.6調度程序將在環境中的每個主機上調度服務容器。如文檔中所述，如果將新主機添加到環境中，并且主機滿足全局服務的主機要求，則Rancher將自動啟動該服務。

下面的示例是Rancher 1.6中的全局服務示例。請注意，只需放置所需標簽就足以使服務全局化。

我們如何使用Kubernetes在Rancher 2.0中部署全局服務？

為此，Rancher為用戶的工作負載部署了Kubernetes DaemonSet對象。DaemonSet的功能與Rancher 1.6全局服務完全相同。Kubernetes調度程序將在集群的每個節點上部署一個pod，并且隨著新節點的添加，調度程序將在它們上啟動新的pod，前提是它們與工作負載的調度要求相匹配。

此外，在2.0中，您還可以將DaemonSet限制為部署到具有特定標簽的節點

使用Rancher 2.0 UI部署DaemonSet

如果您是Rancher 1.6用戶，要使用UI將全局服務遷移到Rancher 2.0，請導航到Cluster> Project> Workloads視圖。部署工作負載時，您可以選擇以下工作負載類型：

這就是上面的DaemonSetworkload相應的Kubernetes YAML規范：

從Docker Compose到Kubernetes YAML

要使用Compose配置將Rancher 1.6全局服務遷移到Rancher 2.0，請按照下列步驟操作。

您可以使用Kompose工具將docker-compose.yml文件從Rancher 1.6轉換為Kubernetes YAML，然后使用Kubernetes集群中的Kubectl客戶端工具或Rancher CLI部署應用程序。

回頭想想上面提到的docker-compose.yml規范，其中的Nginx服務就是全局服務。如下是使用Kompose將其轉換為Kubernetes YAML的方法：

下面開始針對您的Kubernetes集群配置Rancher CLI，并部署生成的* -daemonset.yaml文件。

如上所示，我的Kubernetes集群有兩個可以調度工作負載的工作節點，并且部署global-daemonset.yaml為Daemonset啟動了兩個pod，每個節點上有一個pod。

感謝各位的閱讀，以上就是“Kubernetes容器調度怎么使用”的內容了，經過本文的學習后，相信大家對Kubernetes容器調度怎么使用這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！