在很多場(chǎng)景下，基于資源約束調(diào)度 Pod 是一種理想的行為。但是，在某些用例中，特別是一些高級(jí)調(diào)度場(chǎng)景，Kubernetes 管理員希望根據(jù)其他約束將 Pod 調(diào)度到特定節(jié)點(diǎn)。在本文中，我將回顧 Kubernetes 中高級(jí) pod 調(diào)度的一些場(chǎng)景，以及在實(shí)際情況中實(shí)現(xiàn)它的最佳實(shí)踐。這對(duì)于希望實(shí)施高級(jí)應(yīng)用程序部署模式的應(yīng)用程序工程師和 K8s 管理員特別有幫助，這些模式涉及數(shù)據(jù)本地化、Pod 共存、高可用性和 K8s 集群的資源高效利用。

1.手動(dòng)將 Pod 調(diào)度到節(jié)點(diǎn)的場(chǎng)景

在生產(chǎn) Kubernetes 設(shè)置中，自定義如何將 Pod 調(diào)度到節(jié)點(diǎn)是非常重要的。如下是一些最常見的最常見的調(diào)度場(chǎng)景：

• 在具有專用硬件的節(jié)點(diǎn)上運(yùn)行 Pod：一些 Kubernetes 應(yīng)用程序可能有特定的硬件要求。例如，運(yùn)行 ML 作業(yè)的 Pod 需要高性能 GPU 而不是 CPU，而 Elasticsearch Pod 在 SSD 上比 HDD 更高效。因此，任何資源感知型 K8s 集群管理的最佳實(shí)踐是將 pod 分配給具有正確硬件的節(jié)點(diǎn)。
• Pod 托管和相互依賴：在微服務(wù)設(shè)置或緊密耦合的應(yīng)用程序堆棧中，某些 Pod 應(yīng)該托管在同一臺(tái)機(jī)器上以提高性能，避免網(wǎng)絡(luò)延遲問(wèn)題和連接失敗。例如，在與內(nèi)存緩存服務(wù)或數(shù)據(jù)庫(kù)相同的機(jī)器上運(yùn)行 Web 服務(wù)器是一種很好的做法。
• 數(shù)據(jù)位置：數(shù)據(jù)密集型應(yīng)用程序的數(shù)據(jù)局部性要求類似于以前的使用情況。為了確保更快的讀取和更好的寫入吞吐量，這些應(yīng)用程序可能需要將數(shù)據(jù)庫(kù)部署在所在應(yīng)用程序的同一臺(tái)機(jī)器上。
• 高可用性和容錯(cuò)：為了使應(yīng)用程序部署具有高可用性和容錯(cuò)性，在不同可用分區(qū)的節(jié)點(diǎn)上部署和運(yùn)行 Pod 是一個(gè)很好的做法。

2.Pod 高級(jí)調(diào)度方法

Kubernetes 提供了許多 API 資源和策略來(lái)幫助實(shí)現(xiàn)這些場(chǎng)景。下面，我將介紹 nodeSelector、節(jié)點(diǎn)親和性和 Pod 間親和性概念。我還將向您介紹一些示例，并向您展示如何在您的 K8s 集群中實(shí)現(xiàn)它們。

使用 nodeSelector 手動(dòng)調(diào)度 Pod

在早期的 K8s 版本中，用戶可以使用 PodSpec 的 nodeSelector 字段來(lái)實(shí)現(xiàn)手動(dòng) Pod 調(diào)度。本質(zhì)上，nodeSelector 是一種基于標(biāo)簽的 pod-to-node 調(diào)度方法，用戶將某些標(biāo)簽分配給節(jié)點(diǎn)，并確保 nodeSelector 字段與這些標(biāo)簽匹配。例如，假設(shè)節(jié)點(diǎn)標(biāo)簽之一是“storage=ssd”以指示節(jié)點(diǎn)上的存儲(chǔ)類型。

要使用此標(biāo)簽將 Pod 調(diào)度到節(jié)點(diǎn)上，我將在 Pod yaml 文件中指定具有該標(biāo)簽的 nodeSelector 字段。

節(jié)點(diǎn)選擇器是最簡(jiǎn)單的高級(jí) Pod 調(diào)度方法。但是，當(dāng)在 pod 調(diào)度期間應(yīng)該考慮其他規(guī)則和條件時(shí)，顯得不是很有用。

節(jié)點(diǎn)親和度

與上面討論的手動(dòng)放置 pod 方法相比，節(jié)點(diǎn)親和特性是一個(gè)質(zhì)的改進(jìn)。它使用邏輯運(yùn)算符和約束提供了一種富有表現(xiàn)力的親和語(yǔ)言，可以對(duì) pod 放置進(jìn)行細(xì)粒度控制。它還支持“軟”和“硬”調(diào)度規(guī)則，允許根據(jù)用戶要求控制節(jié)點(diǎn)關(guān)聯(lián)約束的嚴(yán)格程度。在下面的示例中，我們使用節(jié)點(diǎn)關(guān)聯(lián)將 Pod 放置在特定可用的節(jié)點(diǎn)上。讓我們看看下面的編排文件：

“硬”關(guān)聯(lián)規(guī)則在 pod 編排文件 nodeAffinity 部分的required during scheduling ignored during execution字段下指定。在此示例中，我告訴調(diào)度程序僅將 pod 放置在標(biāo)簽為 kubernetes.io/cp-az-name 且值為 cp-1a 或 cp-1b 的節(jié)點(diǎn)上。為了實(shí)現(xiàn)這一點(diǎn)，我使用了 In 邏輯運(yùn)算符來(lái)過(guò)濾現(xiàn)有標(biāo)簽值的數(shù)組。我可以使用的其他運(yùn)算符包括 NotIn、Exists、DoesNotExist、Gt、Lt?！败洝币?guī)則在規(guī)范的preferred during scheduling ignored during execution字段下指定。在此示例中，它指出在滿足“硬”標(biāo)準(zhǔn)的節(jié)點(diǎn)中，我希望使用帶有標(biāo)簽的節(jié)點(diǎn)，該標(biāo)簽的鍵名為“custom-key”，值為“custom-value”。但是，如果不存在這樣的節(jié)點(diǎn)，我不反對(duì)將 pod 調(diào)度給其他符合“硬”標(biāo)準(zhǔn)的候選者。結(jié)合“硬”和“軟”規(guī)則的方式構(gòu)建節(jié)點(diǎn)關(guān)聯(lián)規(guī)則是一種很好的做法。遵循這種“盡力而為”的方法——盡可能使用某個(gè)選項(xiàng)，但如果該選項(xiàng)不可用，則不拒絕調(diào)度——使部署調(diào)度更加靈活和可預(yù)測(cè)。

Pod 間親和性

Kubernetes 中的 Pod 間親和性是一項(xiàng)功能，它允許您根據(jù) Pod 與其他 Pod 的關(guān)系來(lái)安排 Pod。此功能支持各種有趣的場(chǎng)景，例如作為相互依賴服務(wù)的一部分的 Pod 的托管或數(shù)據(jù)本地化的實(shí)現(xiàn)，其中數(shù)據(jù) Pod 與主服務(wù) Pod 運(yùn)行在同一臺(tái)機(jī)器上。Pod 間親和性的定義類似于節(jié)點(diǎn)親和性。但是，在這種情況下，我將使用 pod 規(guī)范的 podAffinity 字段。

與節(jié)點(diǎn)親和性類似，Pod 親和性支持表達(dá)式匹配和邏輯運(yùn)算符。然而，在這種情況下，它們被應(yīng)用于在特定節(jié)點(diǎn)上運(yùn)行的 pod 標(biāo)簽選擇器。如果指定的表達(dá)式與目標(biāo) pod 的 pod 標(biāo)簽匹配，則新的 pod 與目標(biāo) pod 放置在同一臺(tái)機(jī)器上。

反親和性

在某些情況下，最好采用“黑名單”方法進(jìn)行 Pod 調(diào)度。在這種方法中，當(dāng)某些條件不滿足時(shí)，Pod 被阻止被調(diào)度到特定節(jié)點(diǎn)上。這個(gè)功能是在 Kubernetes 節(jié)點(diǎn)到 Pod 反親和性和 Pod 間反親和性中實(shí)現(xiàn)的。pod-to-node anti-affinity 的主要用途是使用專用節(jié)點(diǎn)。為了控制集群中的資源利用率，K8s 管理員可以將某些節(jié)點(diǎn)分配給特定的 pod 類型或應(yīng)用程序。Pod 間反親和性的其他使用場(chǎng)景包括：

• 避免單點(diǎn)故障：這可以通過(guò)將相同服務(wù)的 Pod 分布在不同機(jī)器上來(lái)實(shí)現(xiàn)，這需要防止 Pod 與其他相同類型的 Pod 并存。
• 防止服務(wù)間的資源競(jìng)爭(zhēng)：為了提高某些服務(wù)的性能，避免將它們與消耗大量資源的其他服務(wù)放在一起。

Pod 到節(jié)點(diǎn)的反親和性可以通過(guò) Kubernetes 中的污點(diǎn)和容忍來(lái)實(shí)現(xiàn)。讓我們仔細(xì)看看這個(gè)功能。

污點(diǎn)和容忍

污點(diǎn)（條件）和容忍度可以幫助您控制 pod 到特定節(jié)點(diǎn)的調(diào)度，而無(wú)需修改現(xiàn)有的 pod。默認(rèn)情況下，所有對(duì)污點(diǎn)沒(méi)有容忍度的 pod 都將被拒絕或從節(jié)點(diǎn)中驅(qū)逐。這種行為允許靈活的集群和應(yīng)用程序部署模式，如果您不希望 pod 在特定節(jié)點(diǎn)上運(yùn)行，則無(wú)需更改 pod 定義。實(shí)現(xiàn)污點(diǎn)和容忍非常簡(jiǎn)單。首先，向需要應(yīng)用一些非標(biāo)準(zhǔn)調(diào)度行為的節(jié)點(diǎn)添加污點(diǎn)。例如：

污點(diǎn)格式為 <taintKey>=<taintValue>:<taintEffect> 。我在這里使用的污點(diǎn)效果可以防止任何沒(méi)有匹配容忍度的 pod 被調(diào)度到這個(gè)節(jié)點(diǎn)。其他支持的污點(diǎn)效果包括 NoExecute 和 PreferNoSchedule（NoSchedule 的“軟”版本）。如果應(yīng)用了 PreferNoSchedule 污點(diǎn)，kube-scheduler 不會(huì)將沒(méi)有所需容忍度的 pod 放置到污點(diǎn)上。最后，NoExecute 效應(yīng)會(huì)導(dǎo)致所有 Pod 立即被驅(qū)逐，而節(jié)點(diǎn)沒(méi)有一定的容忍度。如果您已經(jīng)在節(jié)點(diǎn)上運(yùn)行了 Pod 并且不再需要它們，則可以使用該標(biāo)簽。創(chuàng)建污點(diǎn)只是配置的第一部分。為了允許在污點(diǎn)上調(diào)度 pod，我們需要添加容忍度：

在此示例中，我使用“Equal”運(yùn)算符添加了對(duì)上述污點(diǎn)的容忍度，也可以使用“Exists”操作符，它將容忍任何與污點(diǎn) key 匹配的節(jié)點(diǎn)。然而 value 值不是必須指定的。在這種情況下，我將使用污點(diǎn)“storage=ssd: NoSchedule”將我們上面定義的 pod 調(diào)度到該節(jié)點(diǎn)。

Pod 反親和性

可以通過(guò) pod anti-affinity 功能將 pod 相互排斥。如上所述，Kubernetes 中的最佳實(shí)踐之一是通過(guò)將 Pod 分布在不同的可用區(qū)來(lái)避免單點(diǎn)故障。我可以在 pod 規(guī)范的 anti-affinity 部分配置類似的行為。對(duì)于 pod anti-affinity，我們需要兩個(gè) pod：第一個(gè) Pod：

請(qǐng)注意，第一個(gè) pod 的標(biāo)簽為“security: s1”。

第二個(gè) pod 指的是 spec.affinity.podAntiAffinity 下的標(biāo)簽選擇器“security:s1”。因此，該 Pod 不會(huì)被調(diào)度到已經(jīng)托管任何帶有“security:s1”標(biāo)簽的 Pod 的節(jié)點(diǎn)。

3.總結(jié)

Kubernetes 中的高級(jí) pod 調(diào)度允許實(shí)施許多有趣的場(chǎng)景和最佳實(shí)踐，以在 Kubernetes 上部署復(fù)雜的應(yīng)用程序和微服務(wù)。借助 Pod 親和性，您可以為緊密耦合的應(yīng)用程序堆棧和微服務(wù)實(shí)現(xiàn) Pod 托管和數(shù)據(jù)本地化。在下面，您可以找到每種資源類型的一些關(guān)鍵調(diào)度場(chǎng)景的備忘單。

用于高級(jí) Pod 調(diào)度的 Kubernetes 資源概覽。

使用節(jié)點(diǎn)互斥和污點(diǎn)，您可以運(yùn)行具有專用于特定應(yīng)用程序和服務(wù)的硬件的節(jié)點(diǎn)，從而實(shí)現(xiàn)集群中的高效資源利用。通過(guò) pod 反親和和節(jié)點(diǎn)反親和，您還可以通過(guò)讓不同的組件運(yùn)行在不同的節(jié)點(diǎn)上來(lái)確保應(yīng)用程序的高可用性并避免單點(diǎn)故障。