深入研究Kubernetes調(diào)度

“本文從 Pod 和節(jié)點的配置開始，介紹了 Kubernetes Scheduler 框架、擴展點、API 以及可能發(fā)生的與資源相關(guān)的瓶頸，并展示了性能調(diào)整設置，涵蓋了 Kubernetes 中調(diào)度的大多方面。

Kubernetes Scheduler 是 Kubernetes 控制平面的核心組件之一。它在控制平面上運行，將 Pod 分配給節(jié)點，同時平衡節(jié)點之間的資源利用率。將 Pod 分配給新節(jié)點后，在該節(jié)點上運行的 kubelet 會在 Kubernetes API 中檢索 Pod 定義，根據(jù)節(jié)點上的 Pod 規(guī)范創(chuàng)建資源和容器。換句話說，Scheduler 在控制平面內(nèi)運行，并將工作負載分配給 Kubernetes 集群。

本文將對 Kubernetes Scheduler 進行深入研究，首先概述一般的調(diào)度以及具有親和力（affinity）和 taint 的驅(qū)逐調(diào)度，然后討論調(diào)度程序的瓶頸以及生產(chǎn)中可能遇到的問題，最后研究如何微調(diào)調(diào)度程序的參數(shù)以適合集群。

調(diào)度簡介

Kubernetes 調(diào)度是將 Pod 分配給集群中匹配節(jié)點的過程。Scheduler 監(jiān)控新創(chuàng)建的 Pod，并為其分配最佳節(jié)點。它會根據(jù) Kubernetes 的調(diào)度原則和我們的配置選項選擇最佳節(jié)點。最簡單的配置選項是直接在 PodSpec 設置 nodeName：

apiVersion： v1

kind： Pod

metadata：

name： nginx

spec：

containers：

- name： nginx

image： nginx

nodeName： node-01

上面的 nginx pod 默認情況下將在 node-01 上運行，但是 nodeName 有許多限制導致無法正常運行 Pod，例如云中節(jié)點名稱未知、資源節(jié)點不足以及節(jié)點網(wǎng)絡間歇性問題等。因此，除了測試或開發(fā)期間，我們最好不使用 nodeName。

如果要在一組特定的節(jié)點上運行 Pod，可以使用 nodeSelector。我們在 PodSpec 中將 nodeSelector 定義為一組鍵值對：

apiVersion： v1

kind： Pod

metadata：

name： nginx

spec：

containers：

- name： nginx

image： nginx

nodeSelector：

disktype： ssd

對于上面的 nginx pod，Kubernetes Scheduler 將找到一個磁盤類型為 ssd 的節(jié)點。當然，該節(jié)點可以具有其他標簽。我們可以在 Kubernetes 參考文檔中查看標簽的完整列表。

地址：https://kubernetes.io/docs/reference/kubernetes-api/labels-annotations-taints/

使用 nodeSelector 有約束 Pod 可以在有特定標簽的節(jié)點上運行。但它的使用僅受標簽及其值限制。Kubernetes 中有兩個更全面的功能來表達更復雜的調(diào)度需求：節(jié)點親和力（node affinity），標記容器以將其吸引到一組節(jié)點上；taint 和 toleration，標記節(jié)點以排斥 Pod。這些功能將在下面討論。

節(jié)點親和力

節(jié)點親和力（Node Affinity）是在 Pod 上定義的一組約束，用于確定哪些節(jié)點適合進行調(diào)度，即使用親和性規(guī)則為 Pod 的節(jié)點分配定義硬性要求和軟性要求。例如可以將 Pod 配置為僅運行帶有 GPU 的節(jié)點，并且最好使用 NVIDIA_TESLA_V100 運行深度學習工作負載。Scheduler 會評估規(guī)則，并在定義的約束內(nèi)找到合適的節(jié)點。與 nodeSelectors 相似，節(jié)點親和性規(guī)則可與節(jié)點標簽一起使用，但它比 nodeSelectors 更強大。

我們可以為 podspec 添加四個相似性規(guī)則：

requiredDuringSchedulingIgnoredDuringExecution

requiredDuringSchedulingRequiredDuringExecution

preferredDuringSchedulingIgnoredDuringExecution

preferredDuringSchedulingRequiredDuringExecution

這四個規(guī)則由兩個條件組成：必需或首選條件，以及兩個階段：計劃和執(zhí)行。以 required 開頭的規(guī)則描述了必須滿足的嚴格要求。以 preferred 開頭的規(guī)則是軟性要求，將強制執(zhí)行但不能保證。調(diào)度階段是指將 Pod 首次分配給節(jié)點。執(zhí)行階段適用于在調(diào)度分配后節(jié)點標簽發(fā)生更改的情況。

如果規(guī)則聲明為 IgnoredDuringExecution，Scheduler 在第一次分配后不會檢查其有效性。但如果使用 RequiredDuringExecution 指定了規(guī)則，Scheduler 會通過將容器移至合適的節(jié)點來確保規(guī)則的有效性。

以下是示例：

apiVersion： v1kind： Pod

metadata：

name： nginx

spec：

affinity：

nodeAffinity：

requiredDuringSchedulingIgnoredDuringExecution：

nodeSelectorTerms：

- matchExpressions：

- key： topology.kubernetes.io/region

operator： In

values：

- us-east

preferredDuringSchedulingIgnoredDuringExecution：

- weight： 1

preference：

matchExpressions：

- key： topology.kubernetes.io/zone

operator： In

values：

- us-east-1

- us-east-2

containers：

- name： nginx

image： nginx

上面的 Nginx Pod 具有節(jié)點親和性規(guī)則，該規(guī)則讓 Kubernetes Scheduler 將 Pod 放置在 us-east 的節(jié)點上。第二條規(guī)則指示優(yōu)先使用 us-east-1 或 us-east-2。

使用親和性規(guī)則，我們可以讓 Kubernetes 調(diào)度決策適用于自定義需求。

Taint 與 Toleration

集群中并非所有 Kubernetes 節(jié)點都相同。某些節(jié)點可能具有特殊的硬件，例如 GPU、磁盤或網(wǎng)絡功能。同樣，我們可能需要將一些節(jié)點專用于測試、數(shù)據(jù)保護或用戶組。我們可以將 Taint 添加到節(jié)點以排斥 Pod，如以下示例所示：

kubectl taint nodes node1 test-environment=true:NoSchedule

使用 test-environment=true:NoScheduletaint 時，除非在 podspec 具有匹配的 toleration，否則 Kubernetes Scheduler 將不會分配任何 pod：

apiVersion： v1kind： Pod

metadata：

name： nginx

spec：

containers：

- name： nginx

image： nginx

tolerations：

- key： “test-environment”

operator： “Exists”

effect： “NoSchedule”

taint 和 tolerations 共同發(fā)揮作用，讓 Kubernetes Scheduler 專用于某些節(jié)點并分配特定 Pod。

調(diào)度瓶頸

盡管 Kubernetes Scheduler 能選擇最佳節(jié)點，但是在 Pod 開始運行之后，“最佳節(jié)點”可能會改變。所以從長遠來看，Pod 的資源使用及其節(jié)點分配可能存在問題。

資源請求（Request）和限制（Limit）：“Noisy Neighbor”

“Noisy Neighbor”并不特定于 Kubernetes。任何多租戶系統(tǒng)都是它們的潛在地。假設有兩個容器 A 和 B，它們在同一節(jié)點上運行。如果 Pod B 試圖通過消耗所有 CPU 或內(nèi)存來創(chuàng)造 noise，Pod A 將出現(xiàn)問題。如果我們?yōu)槿萜髟O置了資源請求和限制就能控制住 neighbor。Kubernetes 將確保為容器安排其請求的資源，并且不會消耗超出其資源限制的資源。如果在生產(chǎn)中運行 Kubernetes，最好設置資源請求和限制以確保系統(tǒng)可靠。

系統(tǒng)進程資源不足

Kubernetes 節(jié)點主要是連接到 Kubernetes 控制平面的虛擬機。因此，節(jié)點上也有自己的操作系統(tǒng)和相關(guān)進程。如果 Kubernetes 工作負載消耗了所有資源，則這些節(jié)點將無法運行，并會發(fā)生各種問題問題。我們需要在 kubelet 中使用 –system -reserved 設置保留資源，以防止發(fā)生這種情況。

搶占或調(diào)度 Pod

如果 Kubernetes Scheduler 無法將 Pod 調(diào)度到可用節(jié)點，則可以從節(jié)點搶占（preempt）或驅(qū)逐（evict）一些 Pod 以分配資源。如果看到 Pod 在集群中移動而沒有發(fā)現(xiàn)特定原因，可以使用優(yōu)先級類對其進行定義。同樣，如果沒有調(diào)度好 Pod，并且正在等待其他 Pod，也需要檢查其優(yōu)先級。

以下是示例：

apiVersion： scheduling.k8s.io/v1kind： PriorityClass

metadata：

name： high-priority-nonpreempting

value： 100000preemptionPolicy： NeverglobalDefault： false

description： “This priority class will not preempt other pods.”

可以通過以下方式在 podspec 中為分配優(yōu)先級：

apiVersion： v1kind： Pod

metadata：

name： nginx

spec：

containers：

- name： nginx

image： nginx

priorityClassName： high-priority-nonpreempting

調(diào)度框架

Kubernetes Scheduler 具有可插拔的調(diào)度框架架構(gòu)，可向框架添加一組新的插件。插件實現(xiàn) Plugin API，并被編譯到調(diào)度程序中。下面我們將討論調(diào)度框架的工作流、擴展點和 Plugin API。

工作流和擴展點

調(diào)度 Pod 包括兩個階段：調(diào)度周期（scheduling cycle）和綁定周期（binding cycle）。在調(diào)度周期中，Scheduler 會找到一個可用節(jié)點，然后在綁定過程中，將決策應用于集群。

工作流中的以下幾點對插件擴展開放：

QueueSort：對隊列中的 Pod 進行排序

PreFilter：檢查預處理 Pod 的相關(guān)信息以安排調(diào)度周期

Filter：過濾不適合該 Pod 的節(jié)點

PostFilter：如果找不到可用于 Pod 的可行節(jié)點，調(diào)用該插件

PreScore：運行 PreScore 任務以生成一個可共享狀態(tài)供 Score 插件使用

Score：通過調(diào)用每個 Score 插件對過濾的節(jié)點進行排名

NormalizeScore：合并分數(shù)并計算節(jié)點的最終排名

Reserve：在綁定周期之前選擇保留的節(jié)點

Permit：批準或拒絕調(diào)度周期結(jié)果

PreBind：執(zhí)行任何先決條件工作，例如配置網(wǎng)絡卷

Bind：將 Pod 分配給 Kubernetes API 中的節(jié)點

PostBind：通知綁定周期的結(jié)果

插件擴展實現(xiàn)了 Plugin API，是 Kubernetes Scheduler 的一部分。我們可以在 Kubernetes 存儲庫中檢查。插件應使用以下名稱進行注冊：

// Plugin is the parent type for all the scheduling framework plugins.

type Plugin interface {

Name（） string

}

插件還實現(xiàn)了相關(guān)的擴展點，如下所示：

// QueueSortPlugin is an interface that must be implemented by “QueueSort” plugins.

// These plugins are used to sort pods in the scheduling queue. Only one queue sort plugin may be enabled at a time.

type QueueSortPlugin interface {

Plugin

// Less are used to sort pods in the scheduling queue.

Less（*QueuedPodInfo， *QueuedPodInfo） bool

}

Scheduler 性能調(diào)整

Kubernetes Scheduler 有一個工作流來查找和綁定 Pod 的可行節(jié)點。當集群中的節(jié)點數(shù)量非常多時，Scheduler 的工作量將成倍增加。在大型集群中，可能需要很長時間才能找到最佳節(jié)點，因此要微調(diào)調(diào)度程序的性能，以在延遲和準確性之間找到折中方案。

percentageOfNodesToScore 將限制節(jié)點的數(shù)量來計算自己的分數(shù)。默認情況下，Kubernetes 在 100 節(jié)點集群的 50％ 和 5000 節(jié)點集群的 10％ 之間設置線性閾值。默認最小值為 5％，它要確保至少考慮集群中 5％ 節(jié)點的調(diào)度。

下面的示例展示了如何通過性能調(diào)整 kube-scheduler 來手動設置閾值：

apiVersion： kubescheduler.config.k8s.io/v1alpha1

kind： KubeSchedulerConfiguration

algorithmSource：

provider： DefaultProvider

percentageOfNodesToScore： 50

如果有一個龐大的集群并且 Kubernetes 工作負載不能承受 Kubernetes Scheduler 引起的延遲，那么更改百分比是個好主意。

總結(jié)

本文涵蓋了 Kubernetes 調(diào)度的大多方面，從 Pod 和節(jié)點的配置開始，包括 nodeSelector、親和性規(guī)則、taint 和 toleration，然后介紹了 Kubernetes Scheduler 框架、擴展點、API 以及可能發(fā)生的與資源相關(guān)的瓶頸，最后展示了性能調(diào)整設置。盡管 Kubernetes Scheduler 能簡單地將 Pod 分配給節(jié)點，但是了解其動態(tài)性并對其進行配置以實現(xiàn)可靠的生產(chǎn)級 Kubernetes 設置至關(guān)重要。

原文鏈接：https://thenewstack.io/a-deep-dive-into-kubernetes-scheduling/

作者：Ron Sobol. 翻譯：Bach（才云）

校對：星空下的文仔（才云）、bot（才云）

責任編輯：haq