Kubernetes容器調度策略

容器編排中一個重要且複雜的方面是調度應用程序容器。如何將容器適當放置到可用的共享基礎架構資源上，是在最佳計算資源使用狀況下實現最大性能的關鍵所在。

Cattle是Rancher 1.6的默認編排引擎，提供了各類調度功能來有效地放置服務：

https://rancher.com/docs/rancher/v1.6/en/cattle/scheduling/#scheduling-services

隨着基於Kubernetes的Rancher 2.0版本的發佈，Rancher如今使用原生的Kubernetes調度。在本文中，咱們將看看Rancher 2.0中可用的調度方法與Cattle的調度的比較。

節點調度

根據原生的Kubernetes行爲，默認狀況下，Rancher 2.0工做負載中的pod將分佈在可調度且具備足夠可用容量的節點（主機）上。但就像1.6版本同樣，Rancher 2.0也有助於：

• 在特定節點上運行全部pod

• 使用標籤進行節點調度

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

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

Rancher使用底層的原生Kubernetes構造來指定節點的親和性/反親和性。相應的Kubernetes的詳細文檔參考此處：

https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity

下面的示例中咱們未來看看如何使用節點調度選項來調度工做負載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的其餘調度功能

若是您是Cattle用戶，想必您很熟悉Rancher 1.6中提供的一些其餘調度功能：

• 選擇使用容器標籤的主機：

https://rancher.com/docs/rancher/v1.6/en/cattle/scheduling/#finding-hosts-with-container-labels

• 可以根據資源約束進行調度：

https://rancher.com/docs/rancher/v1.6/en/rancher-services/scheduler/#resource-constraints

• 可以僅在主機上調度特定服務：

https://rancher.com/docs/rancher/v1.6/en/rancher-services/scheduler/#restrict-services-on-host

若是您是在Rancher 1.6設置中使用這些功能，則可使用原生的Kubernetes調度選項在Rancher 2.0中複製它們。在Rancher v2.0.8中，在部署工做負載時暫時沒有對這些選項的UI支持，但您始終能夠經過在Rancher集羣上導入Kubernetes YAML規範來使用它們。

使用容器標籤進行調度

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

https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity

如文檔中所述，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資源。您能夠在此處找到有關這些規範的更多詳細信息：

https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#resource-requests-and-limits-of-pod-and-container

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

僅給主機調度特定服務

Rancher 1.6可以在主機上指定容器標籤，從而只將特定容器調度給它。

要在Rancher 2.0中實現此目的，能夠在pod規範中使用相應的Kubernetes的「添加節點taints（如主機標籤）並使用容差」的功能：

https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/

全局服務

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

https://rancher.com/docs/rancher/v1.6/en/cattle/scheduling/#global-service

若是服務的標籤爲io.rancher.scheduler.global：'true'，則Rancher 1.6調度程序將在環境中的每一個主機上調度服務容器。如文檔中所述，若是將新主機添加到環境中，而且主機知足全局服務的主機要求，則Rancher將自動啓動該服務。

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

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

爲此，Rancher爲用戶的工做負載部署了Kubernetes DaemonSet對象（https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/）。DaemonSet的功能與Rancher 1.6全局服務徹底相同。Kubernetes調度程序將在集羣的每一個節點上部署一個pod，而且隨着新節點的添加，調度程序將在它們上啓動新的pod，前提是它們與工做負載的調度要求相匹配。

此外，在2.0中，您還能夠將DaemonSet限制爲部署到具備特定標籤的節點，具體可參考文檔：

https://kubernetes.io/docs/concepts/workloads/controllers/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。

** 總 結 **

在本文中，咱們回顧瞭如何將Rancher 1.6的各類調度功能遷移到Rancher 2.0。大多數調度技術在Rancher 2.0中都有相同的選項，或者它們能夠經過原生的Kubernetes結構實現。