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

1.手動將 Pod 調度到節點的場景

在生產 Kubernetes 設置中，自定義如何將 Pod 調度到節點是非常重要的。如下是一些最常見的最常見的調度場景：

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

2.Pod 高級調度方法

Kubernetes 提供了許多 API 資源和策略來幫助實現這些場景。下面，我將介紹 nodeSelector、節點親和性和 Pod 間親和性概念。我還將向您介紹一些示例，并向您展示如何在您的 K8s 集群中實現它們。

使用 nodeSelector 手動調度 Pod

在早期的 K8s 版本中，用戶可以使用 PodSpec 的 nodeSelector 字段來實現手動 Pod 調度。本質上，nodeSelector 是一種基于標簽的 pod-to-node 調度方法，用戶將某些標簽分配給節點，并確保 nodeSelector 字段與這些標簽匹配。例如，假設節點標簽之一是“storage=ssd”以指示節點上的存儲類型。

要使用此標簽將 Pod 調度到節點上，我將在 Pod yaml 文件中指定具有該標簽的 nodeSelector 字段。

節點選擇器是最簡單的高級 Pod 調度方法。但是，當在 pod 調度期間應該考慮其他規則和條件時，顯得不是很有用。

節點親和度

與上面討論的手動放置 pod 方法相比，節點親和特性是一個質的改進。它使用邏輯運算符和約束提供了一種富有表現力的親和語言，可以對 pod 放置進行細粒度控制。它還支持“軟”和“硬”調度規則，允許根據用戶要求控制節點關聯約束的嚴格程度。在下面的示例中，我們使用節點關聯將 Pod 放置在特定可用的節點上。讓我們看看下面的編排文件：

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

Pod 間親和性

Kubernetes 中的 Pod 間親和性是一項功能，它允許您根據 Pod 與其他 Pod 的關系來安排 Pod。此功能支持各種有趣的場景，例如作為相互依賴服務的一部分的 Pod 的托管或數據本地化的實現，其中數據 Pod 與主服務 Pod 運行在同一臺機器上。Pod 間親和性的定義類似于節點親和性。但是，在這種情況下，我將使用 pod 規范的 podAffinity 字段。

與節點親和性類似，Pod 親和性支持表達式匹配和邏輯運算符。然而，在這種情況下，它們被應用于在特定節點上運行的 pod 標簽選擇器。如果指定的表達式與目標 pod 的 pod 標簽匹配，則新的 pod 與目標 pod 放置在同一臺機器上。

反親和性

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

• 避免單點故障：這可以通過將相同服務的 Pod 分布在不同機器上來實現，這需要防止 Pod 與其他相同類型的 Pod 并存。
• 防止服務間的資源競爭：為了提高某些服務的性能，避免將它們與消耗大量資源的其他服務放在一起。

Pod 到節點的反親和性可以通過 Kubernetes 中的污點和容忍來實現。讓我們仔細看看這個功能。

污點和容忍

污點（條件）和容忍度可以幫助您控制 pod 到特定節點的調度，而無需修改現有的 pod。默認情況下，所有對污點沒有容忍度的 pod 都將被拒絕或從節點中驅逐。這種行為允許靈活的集群和應用程序部署模式，如果您不希望 pod 在特定節點上運行，則無需更改 pod 定義。實現污點和容忍非常簡單。首先，向需要應用一些非標準調度行為的節點添加污點。例如：

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

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

Pod 反親和性

可以通過 pod anti-affinity 功能將 pod 相互排斥。如上所述，Kubernetes 中的最佳實踐之一是通過將 Pod 分布在不同的可用區來避免單點故障。我可以在 pod 規范的 anti-affinity 部分配置類似的行為。對于 pod anti-affinity，我們需要兩個 pod：第一個 Pod：

請注意，第一個 pod 的標簽為“security: s1”。

第二個 pod 指的是 spec.affinity.podAntiAffinity 下的標簽選擇器“security:s1”。因此，該 Pod 不會被調度到已經托管任何帶有“security:s1”標簽的 Pod 的節點。

3.總結

Kubernetes 中的高級 pod 調度允許實施許多有趣的場景和最佳實踐，以在 Kubernetes 上部署復雜的應用程序和微服務。借助 Pod 親和性，您可以為緊密耦合的應用程序堆棧和微服務實現 Pod 托管和數據本地化。在下面，您可以找到每種資源類型的一些關鍵調度場景的備忘單。

用于高級 Pod 調度的 Kubernetes 資源概覽。

使用節點互斥和污點，您可以運行具有專用于特定應用程序和服務的硬件的節點，從而實現集群中的高效資源利用。通過 pod 反親和和節點反親和，您還可以通過讓不同的組件運行在不同的節點上來確保應用程序的高可用性并避免單點故障。