將 Pod 分配給節點

你可以限制一個 Pod，使其被**限制**執行在特定的節點上，或者**傾向於**執行在特定的節點上。有幾種方法可以實現這一點，建議的方法都使用標籤選擇器來輔助選擇。通常，你不需要設定任何此類約束；排程器將自動進行合理的放置（例如，將你的 Pods 分佈在不同節點上，以免將 Pods 放置在可用資源不足的節點上）。但是，在某些情況下，你可能希望控制 Pod 部署到哪個節點，例如，確保 Pod 最終落在連線有 SSD 的節點上，或者將兩個需要大量通訊的不同服務的 Pods 放在同一可用區域中。

你可以使用以下任何一種方法來選擇 Kubernetes 排程特定 Pods 的位置：

• nodeSelector 欄位與節點標籤匹配
• 親和性和反親和性
• nodeName 欄位
• Pod 拓撲分散約束

節點標籤

像許多其他 Kubernetes 物件一樣，節點也有標籤。你可以手動附加標籤。Kubernetes 還在叢集中的所有節點上填充了一組標準標籤。

節點隔離/限制

給節點新增標籤允許你將 Pod 排程到特定的節點或節點組。你可以使用此功能來確保特定的 Pod 只在具有某些隔離、安全或法規屬性的節點上執行。

如果你使用標籤進行節點隔離，請選擇 kubelet 無法修改的標籤鍵。這可以防止受損節點自行設定這些標籤，從而阻止排程器將工作負載排程到受損節點上。

`NodeRestriction` 准入外掛阻止 kubelet 設定或修改帶有 `node-restriction.kubernetes.io/` 字首的標籤。

要利用該標籤字首進行節點隔離：

1. 確保你正在使用 Node 鑑權器 並**啟用** `NodeRestriction` 准入外掛。
2. 向你的節點新增帶有 `node-restriction.kubernetes.io/` 字首的標籤，並在你的節點選擇器中使用這些標籤。例如，`example.com.node-restriction.kubernetes.io/fips=true` 或 `example.com.node-restriction.kubernetes.io/pci-dss=true`。

nodeSelector

`nodeSelector` 是最簡單的推薦節點選擇約束形式。你可以在 Pod 規範中新增 `nodeSelector` 欄位，並指定你希望目標節點擁有的節點標籤。Kubernetes 只會將 Pod 排程到具有你指定的所有標籤的節點上。

更多資訊，請參閱將 Pod 分配到節點。

親和性和反親和性

`nodeSelector` 是將 Pod 約束到具有特定標籤的節點的最簡單方法。親和性和反親和性擴充套件了你可以定義的約束型別。親和性和反親和性的一些優點包括：

• 親和性/反親和性語言更具表達性。`nodeSelector` 只選擇所有指定標籤的節點。親和性/反親和性為你提供了對選擇邏輯的更多控制。
• 你可以指出某個規則是**軟**或**首選**的，以便排程器即使找不到匹配的節點也能排程 Pod。
• 你可以使用執行在節點上（或其他拓撲域中）的其他 Pod 的標籤來約束 Pod，而不僅僅是節點標籤，這允許你定義哪些 Pod 可以共同位於一個節點上的規則。

親和性特性由兩種親和性組成：

• *節點親和性*功能類似於 `nodeSelector` 欄位，但更具表達性，並且允許你指定軟規則。
• *Pod 間親和性/反親和性*允許你根據其他 Pod 上的標籤來約束 Pod。

節點親和性

節點親和性在概念上類似於 `nodeSelector`，允許你根據節點標籤限制你的 Pod 可以排程到哪些節點上。節點親和性有兩種型別：

• `requiredDuringSchedulingIgnoredDuringExecution`：除非規則得到滿足，否則排程器無法排程該 Pod。這類似於 `nodeSelector` 的功能，但具有更具表達性的語法。
• `preferredDuringSchedulingIgnoredDuringExecution`：排程器嘗試尋找一個滿足規則的節點。如果找不到匹配的節點，排程器仍然會排程該 Pod。

你可以在 Pod 規約中使用 `.spec.affinity.nodeAffinity` 欄位來指定節點親和性。

例如，考慮以下 Pod 規約：

`pods/pod-with-node-affinity.yaml`

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: topology.kubernetes.io/zone
            operator: In
            values:
            - antarctica-east1
            - antarctica-west1
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: another-node-label-key
            operator: In
            values:
            - another-node-label-value
  containers:
  - name: with-node-affinity
    image: registry.k8s.io/pause:3.8

在此示例中，適用以下規則：

• 節點**必須**有一個鍵為 `topology.kubernetes.io/zone` 的標籤，並且該標籤的值**必須**是 `antarctica-east1` 或 `antarctica-west1`。
• 節點**最好**有一個鍵為 `another-node-label-key`、值為 `another-node-label-value` 的標籤。

你可以使用 `operator` 欄位來指定 Kubernetes 在解釋規則時使用的邏輯運算子。你可以使用 `In`、`NotIn`、`Exists`、`DoesNotExist`、`Gt` 和 `Lt`。

閱讀運算子以瞭解更多這些運算子的工作原理。

`NotIn` 和 `DoesNotExist` 允許你定義節點反親和性行為。另外，你可以使用節點汙點來排斥 Pods 離開特定節點。

更多資訊，請參閱使用節點親和性將 Pod 分配給節點。

節點親和性權重

你可以為 `preferredDuringSchedulingIgnoredDuringExecution` 親和性型別的每個例項指定 1 到 100 之間的 `weight`。當排程器找到滿足 Pod 所有其他排程要求的節點時，排程器會遍歷節點滿足的每個首選規則，並將該表示式的 `weight` 值新增到總和中。

最終的總和被新增到節點其他優先順序功能的得分中。當排程器為 Pod 做出排程決定時，總分最高的節點將被優先考慮。

例如，考慮以下 Pod 規約：

`pods/pod-with-affinity-preferred-weight.yaml`

apiVersion: v1
kind: Pod
metadata:
  name: with-affinity-preferred-weight
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/os
            operator: In
            values:
            - linux
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: label-1
            operator: In
            values:
            - key-1
      - weight: 50
        preference:
          matchExpressions:
          - key: label-2
            operator: In
            values:
            - key-2
  containers:
  - name: with-node-affinity
    image: registry.k8s.io/pause:3.8

如果有兩個可能匹配 `preferredDuringSchedulingIgnoredDuringExecution` 規則的節點，一個帶有 `label-1:key-1` 標籤，另一個帶有 `label-2:key-2` 標籤，排程器會考慮每個節點的 `weight`，並將該權重新增到該節點的其他分數中，然後將 Pod 排程到最終分數最高的節點上。

每個排程配置檔案的節點親和性

在配置多個排程配置檔案時，你可以將一個配置檔案與節點親和性關聯起來，如果一個配置檔案只適用於一組特定的節點，這將非常有用。為此，請在排程器配置中`NodeAffinity` 外掛的 `args` 欄位中新增 `addedAffinity`。例如：

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration

profiles:
  - schedulerName: default-scheduler
  - schedulerName: foo-scheduler
    pluginConfig:
      - name: NodeAffinity
        args:
          addedAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              nodeSelectorTerms:
              - matchExpressions:
                - key: scheduler-profile
                  operator: In
                  values:
                  - foo

`addedAffinity` 將應用於所有將 `.spec.schedulerName` 設定為 `foo-scheduler` 的 Pods，並作為 PodSpec 中指定的 NodeAffinity 的補充。也就是說，為了匹配 Pod，節點需要滿足 `addedAffinity` 和 Pod 的 `.spec.NodeAffinity`。

由於 `addedAffinity` 對終端使用者不可見，其行為可能超出他們的預期。請使用與排程器配置檔名稱明確相關的節點標籤。

Pod 間親和性與反親和性

Pod 間親和性與反親和性允許你根據已在該節點上執行的 Pod 的標籤，而不是節點標籤，來約束 Pod 可以排程到哪些節點上。

Pod 間親和性與反親和性的型別

Pod 間親和性和反親和性的形式是“如果 X 中已經運行了一個或多個符合規則 Y 的 Pod，則此 Pod 應該（或在反親和性的情況下不應該）在 X 中執行”，其中 X 是一個拓撲域，例如節點、機架、雲提供商區域或類似域，Y 是 Kubernetes 嘗試滿足的規則。

你將這些規則（Y）表示為標籤選擇器，並帶有一個可選的名稱空間列表。Pod 是 Kubernetes 中的名稱空間物件，因此 Pod 標籤也隱式地具有名稱空間。任何 Pod 標籤的標籤選擇器都應指定 Kubernetes 應該在其中查詢這些標籤的名稱空間。

你使用 `topologyKey` 來表達拓撲域 (X)，它是系統用於表示域的節點標籤的鍵。有關示例，請參閱眾所周知的標籤、註解和汙點。

類似於節點親和性，Pod 親和性與反親和性也有以下兩種型別：

• requiredDuringSchedulingIgnoredDuringExecution
• preferredDuringSchedulingIgnoredDuringExecution

例如，你可以使用 `requiredDuringSchedulingIgnoredDuringExecution` 親和性來告知排程器將兩個服務的 Pods 共同放置在同一個雲提供商區域中，因為它們之間通訊頻繁。類似地，你可以使用 `preferredDuringSchedulingIgnoredDuringExecution` 反親和性將一個服務的 Pods 分散到多個雲提供商區域。

要使用 Pod 間親和性，請在 Pod 規約中使用 `affinity.podAffinity` 欄位。對於 Pod 間反親和性，請在 Pod 規約中使用 `affinity.podAntiAffinity` 欄位。

排程行為

排程新 Pod 時，Kubernetes 排程器會根據當前叢集狀態評估 Pod 的親和性/反親和性規則：

1. 硬約束 (節點過濾)

   • podAffinity.requiredDuringSchedulingIgnoredDuringExecution 和 podAntiAffinity.requiredDuringSchedulingIgnoredDuringExecution
     • 排程器確保根據現有 Pods，將新 Pod 分配給滿足這些必需親和性與反親和性規則的節點。

2. 軟約束 (評分)

   • podAffinity.preferredDuringSchedulingIgnoredDuringExecution 和 podAntiAffinity.preferredDuringSchedulingIgnoredDuringExecution
     • 排程器根據節點滿足這些首選親和性與反親和性規則的程度來為節點評分，以最佳化 Pod 的放置。

3. 被忽略的欄位

   • 現有 Pod 的 `podAffinity.preferredDuringSchedulingIgnoredDuringExecution`
     • 在為新 Pod 做出排程決定時，這些首選親和性規則不予考慮。
   • 現有 Pod 的 `podAntiAffinity.preferredDuringSchedulingIgnoredDuringExecution`
     • 同樣，現有 Pod 的首選反親和性規則在排程時被忽略。

使用 Pod 間親和性排程一組 Pod

如果當前正在排程的 Pod 是一系列具有自身親和性的 Pod 中的第一個，並且通過了所有其他親和性檢查，則允許其被排程。這是透過驗證叢集中沒有其他 Pod 與此 Pod 的名稱空間和選擇器匹配，Pod 與其自身術語匹配，並且所選節點與所有請求的拓撲匹配來確定的。這確保了即使所有 Pod 都指定了 Pod 間親和性，也不會出現死鎖。

Pod 親和性示例

考慮以下 Pod 規範：

`pods/pod-with-pod-affinity.yaml`

apiVersion: v1
kind: Pod
metadata:
  name: with-pod-affinity
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: security
            operator: In
            values:
            - S1
        topologyKey: topology.kubernetes.io/zone
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: security
              operator: In
              values:
              - S2
          topologyKey: topology.kubernetes.io/zone
  containers:
  - name: with-pod-affinity
    image: registry.k8s.io/pause:3.8

此示例定義了一個 Pod 親和性規則和一個 Pod 反親和性規則。Pod 親和性規則使用“硬”的 `requiredDuringSchedulingIgnoredDuringExecution`，而反親和性規則使用“軟”的 `preferredDuringSchedulingIgnoredDuringExecution`。

親和性規則指定排程器只有在目標節點屬於某個特定區域，並且該區域中已經有帶有 `security=S1` 標籤的其他 Pods 的情況下，才允許將示例 Pod 放置在該節點上。例如，如果我們的叢集中有一個指定區域，我們稱之為“區域 V”，它由帶有 `topology.kubernetes.io/zone=V` 標籤的節點組成，只要區域 V 中至少有一個 Pod 已經帶有 `security=S1` 標籤，排程器就可以將 Pod 分配給區域 V 中的任何節點。相反，如果區域 V 中沒有帶有 `security=S1` 標籤的 Pods，排程器將不會將示例 Pod 分配給該區域中的任何節點。

反親和性規則指定，如果節點屬於特定的區域，並且該區域中已有帶有 `security=S2` 標籤的其他 Pods，排程器應儘量避免將 Pod 排程到該節點上。例如，如果叢集中有一個指定區域，我們稱之為“區域 R”，該區域由帶有 `topology.kubernetes.io/zone=R` 標籤的節點組成，只要區域 R 中至少有一個 Pod 帶有 `security=S2` 標籤，排程器就應避免將 Pod 分配給區域 R 中的任何節點。反之，如果區域 R 中沒有帶有 `security=S2` 標籤的 Pods，則反親和性規則不會影響向區域 R 的排程。

要更熟悉 Pod 親和性與反親和性的示例，請參閱設計提案。

你可以在 Pod 親和性與反親和性的 `operator` 欄位中使用 `In`、`NotIn`、`Exists` 和 `DoesNotExist` 值。

閱讀運算子以瞭解更多這些運算子的工作原理。

原則上，`topologyKey` 可以是任何允許的標籤鍵，但出於效能和安全原因，有以下例外情況：

• 對於 Pod 親和性與反親和性，在 `requiredDuringSchedulingIgnoredDuringExecution` 和 `preferredDuringSchedulingIgnoredDuringExecution` 中都不允許空的 `topologyKey` 欄位。
• 對於 `requiredDuringSchedulingIgnoredDuringExecution` Pod 反親和性規則，准入控制器 `LimitPodHardAntiAffinityTopology` 將 `topologyKey` 限制為 `kubernetes.io/hostname`。如果你想允許自定義拓撲，可以修改或停用准入控制器。

除了 `labelSelector` 和 `topologyKey` 之外，你還可以選擇指定一個名稱空間列表，`labelSelector` 應使用與 `labelSelector` 和 `topologyKey` 相同的級別上的 `namespaces` 欄位進行匹配。如果省略或為空，`namespaces` 預設為定義親和性/反親和性的 Pod 的名稱空間。

名稱空間選擇器

你還可以使用 `namespaceSelector` 選擇匹配的名稱空間，它是一個針對名稱空間集的標籤查詢。親和性術語應用於由 `namespaceSelector` 和 `namespaces` 欄位選擇的名稱空間。請注意，空的 `namespaceSelector` ({}) 匹配所有名稱空間，而 null 或空的 `namespaces` 列表和 null `namespaceSelector` 匹配定義規則的 Pod 的名稱空間。

matchLabelKeys

Kubernetes 包含一個可選的 `matchLabelKeys` 欄位，用於 Pod 親和性或反親和性。該欄位指定當滿足 Pod（反）親和性時，應與傳入 Pod 標籤匹配的標籤鍵。

這些鍵用於從 Pod 標籤中查詢值；這些鍵值標籤與使用 `labelSelector` 欄位定義的匹配限制相結合（使用 `AND` 邏輯）。組合過濾會選擇一組現有 Pods，這些 Pods 將用於 Pod（反）親和性計算。

一個常見的用例是將 `matchLabelKeys` 與 `pod-template-hash`（在作為 Deployment 一部分管理的 Pods 上設定，其值對於每個修訂版本都是唯一的）結合使用。在 `matchLabelKeys` 中使用 `pod-template-hash` 允許你定位與傳入 Pod 屬於同一修訂版本的 Pods，這樣滾動升級就不會破壞親和性。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: application-server
...
spec:
  template:
    spec:
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - database
            topologyKey: topology.kubernetes.io/zone
            # Only Pods from a given rollout are taken into consideration when calculating pod affinity.
            # If you update the Deployment, the replacement Pods follow their own affinity rules
            # (if there are any defined in the new Pod template)
            matchLabelKeys:
            - pod-template-hash

mismatchLabelKeys

Kubernetes 包含一個可選的 `mismatchLabelKeys` 欄位，用於 Pod 親和性或反親和性。該欄位指定當滿足 Pod（反）親和性時，不應與傳入 Pod 標籤匹配的標籤鍵。

一個示例用例是確保 Pods 部署到僅排程同一租戶或團隊的 Pods 的拓撲域（節點、區域等）。換句話說，你希望避免在同一拓撲域中同時執行來自兩個不同租戶的 Pods。

apiVersion: v1
kind: Pod
metadata:
  labels:
    # Assume that all relevant Pods have a "tenant" label set
    tenant: tenant-a
...
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      # ensure that Pods associated with this tenant land on the correct node pool
      - matchLabelKeys:
          - tenant
        topologyKey: node-pool
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      # ensure that Pods associated with this tenant can't schedule to nodes used for another tenant
      - mismatchLabelKeys:
        - tenant # whatever the value of the "tenant" label for this Pod, prevent
                 # scheduling to nodes in any pool where any Pod from a different
                 # tenant is running.
        labelSelector:
          # We have to have the labelSelector which selects only Pods with the tenant label,
          # otherwise this Pod would have anti-affinity against Pods from daemonsets as well, for example,
          # which aren't supposed to have the tenant label.
          matchExpressions:
          - key: tenant
            operator: Exists
        topologyKey: node-pool

更實際的用例

當與更高級別的集合（如 ReplicaSet、StatefulSet、Deployment 等）一起使用時，Pod 間親和性與反親和性會更有用。這些規則允許你配置一組工作負載應共同位於同一已定義拓撲中；例如，傾向於將兩個相關的 Pod 放置在同一個節點上。

例如：想象一個三節點叢集。你使用該叢集執行一個 Web 應用程式和一個記憶體快取（例如 Redis）。在此示例中，還假設 Web 應用程式和記憶體快取之間的延遲應儘可能低。你可以使用 Pod 間親和性和反親和性儘可能地將 Web 伺服器與快取共同放置。

在以下 Redis 快取的 Deployment 示例中，副本獲得標籤 `app=store`。`podAntiAffinity` 規則告訴排程器避免將多個帶有 `app=store` 標籤的副本放置在單個節點上。這會在每個獨立節點中建立一個快取。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis-cache
spec:
  selector:
    matchLabels:
      app: store
  replicas: 3
  template:
    metadata:
      labels:
        app: store
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - store
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: redis-server
        image: redis:3.2-alpine

以下 Web 伺服器的 Deployment 示例建立帶有 `app=web-store` 標籤的副本。Pod 親和性規則告訴排程器將每個副本放置在具有帶有 `app=store` 標籤的 Pod 的節點上。Pod 反親和性規則告訴排程器永遠不要將多個 `app=web-store` 伺服器放置在單個節點上。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
spec:
  selector:
    matchLabels:
      app: web-store
  replicas: 3
  template:
    metadata:
      labels:
        app: web-store
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - web-store
            topologyKey: "kubernetes.io/hostname"
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - store
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: web-app
        image: nginx:1.16-alpine

建立以上兩個 Deployment 將導致以下叢集佈局，其中每個 Web 伺服器與一個快取共同位於三個不同的節點上。

總體效果是，每個快取例項很可能由執行在同一節點上的單個客戶端訪問。這種方法旨在最大限度地減少偏差（負載不均衡）和延遲。

你可能還有其他使用 Pod 反親和性的原因。請參閱 ZooKeeper 教程，瞭解使用與此示例相同的技術配置反親和性以實現高可用性的 StatefulSet 示例。

nodeName

`nodeName` 是一種比親和性或 `nodeSelector` 更直接的節點選擇形式。`nodeName` 是 Pod 規約中的一個欄位。如果 `nodeName` 欄位不為空，排程器將忽略該 Pod，並且指定節點上的 kubelet 會嘗試將該 Pod 放置在該節點上。使用 `nodeName` 會覆蓋使用 `nodeSelector` 或親和性與反親和性規則。

使用 `nodeName` 選擇節點的一些限制是：

• 如果指定的節點不存在，Pod 將不會執行，並且在某些情況下可能會自動刪除。
• 如果指定的節點沒有足夠的資源來容納 Pod，Pod 將失敗，並且其原因會指出原因，例如 OutOfmemory 或 OutOfcpu。
• 雲環境中的節點名稱並非總是可預測或穩定的。

以下是使用 `nodeName` 欄位的 Pod 規範示例：

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
  nodeName: kube-01

上述 Pod 只會在節點 `kube-01` 上執行。

nominatedNodeName

`nominatedNodeName` 可用於外部元件為掛起中的 Pod 提名節點。這種提名是盡力而為的：如果排程器確定 Pod 無法部署到被提名節點，則可能會忽略它。

此外，該欄位可以由排程器（覆蓋）寫入：

• 如果排程器透過搶佔找到一個提名節點。
• 如果排程器決定 Pod 的去向，並將其移至繫結週期。
  • 請注意，在這種情況下，只有當 Pod 必須透過 `WaitOnPermit` 或 `PreBind` 擴充套件點時，才會設定 `nominatedNodeName`。

以下是使用 `nominatedNodeName` 欄位的 Pod 狀態示例：

apiVersion: v1
kind: Pod
metadata:
  name: nginx
...
status:
  nominatedNodeName: kube-01

Pod 拓撲分散約束

你可以使用**拓撲分散約束**來控制 Pod 在叢集中如何分散到不同的故障域（如區域、可用區、節點）或任何你定義的其他拓撲域中。這樣做可以提高效能、預期可用性或整體利用率。

閱讀Pod 拓撲分散約束以瞭解這些約束的工作原理。

運算子

以下是你可以用於上述 `nodeAffinity` 和 `podAffinity` 的 `operator` 欄位的所有邏輯運算子。

以下運算子只能與 `nodeAffinity` 一起使用。

下一步

• 閱讀更多關於汙點和容忍的資訊。
• 閱讀節點親和性和Pod 間親和性/反親和性的設計文件。
• 瞭解拓撲管理器如何參與節點級資源分配決策。
• 瞭解如何使用 nodeSelector。
• 瞭解如何使用親和性和反親和性。