將 Pods 指派給節點

您可以約束 Pod，使其限制在特定的節點上執行，或者偏好在特定的節點上執行。 有幾種方法可以做到這一點，推薦的方法都使用標籤選擇器來促進選擇。 通常，您不需要設定任何此類約束；排程器 將自動進行合理的放置（例如，將您的 Pod 分散在多個節點上，以便不會將 Pod 放置在資源不足的節點上）。 但是，在某些情況下，您可能希望控制 Pod 部署到哪個節點，例如，確保 Pod 最終部署到連接了 SSD 的節點上，或者將來自兩個不同服務且大量通訊的 Pod 共置於相同的可用性區域中。

您可以使用以下任何方法來選擇 Kubernetes 排程特定 Pod 的位置

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

節點標籤

與許多其他 Kubernetes 物件一樣，節點具有標籤。 您可以手動附加標籤。 Kubernetes 也會在叢集中的所有節點上填充標準的標籤集。

節點隔離/限制

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

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

NodeRestriction 准入外掛程式可防止 kubelet 設定或修改具有 node-restriction.kubernetes.io/ 前綴的標籤。

若要使用該標籤前綴進行節點隔離

1. 請確保您正在使用節點授權器，並且已啟用 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 是最簡單且建議使用的節點選擇約束形式。 您可以將 nodeSelector 欄位新增到您的 Pod 規格中，並指定您希望目標節點擁有的節點標籤。 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:2.0

在此範例中，適用以下規則

• 節點必須具有一個標籤，其鍵為 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 允許您定義節點反親緣性行為。或者，您可以使用節點污點來排斥 Pod 離開特定節點。

有關更多資訊，請參閱使用節點親緣性將 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:2.0

如果兩個可能的節點都符合 preferredDuringSchedulingIgnoredDuringExecution 規則，一個節點具有 label-1:key-1 標籤，另一個節點具有 label-2:key-2 標籤，則排程器會考量每個節點的 weight，並將權重加到該節點的其他分數中，然後將 Pod 排程到最終得分最高的節點上。

每個排程設定檔的節點親緣性

當設定多個排程設定檔時，您可以將設定檔與節點親緣性相關聯，如果設定檔僅適用於一組特定的節點，則此功能非常有用。若要執行此操作，請將 addedAffinity 新增到NodeAffinity 外掛程式的 args 欄位中，位於排程器設定中。例如

apiVersion: kubescheduler.config.k8s.io/v1beta3
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 除了 PodSpec 中指定的 NodeAffinity 之外，還會套用到所有將 .spec.schedulerName 設定為 foo-scheduler 的 Pod。也就是說，為了符合 Pod 的條件，節點需要同時滿足 addedAffinity 和 Pod 的 .spec.NodeAffinity。

由於 addedAffinity 對終端使用者不可見，因此其行為對他們來說可能是出乎意料的。請使用與排程器設定檔名稱具有明確關聯的節點標籤。

Pod 間親緣性和反親緣性

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

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

您將這些規則 (Y) 表示為標籤選擇器，並帶有一個可選的相關命名空間列表。Pod 是 Kubernetes 中的命名空間物件，因此 Pod 標籤也隱含地具有命名空間。Pod 標籤的任何標籤選擇器都應指定 Kubernetes 應在其中尋找這些標籤的命名空間。

您可以使用 topologyKey 來表示拓撲網域 (X)，topologyKey 是系統用來表示網域的節點標籤的鍵。有關範例，請參閱眾所周知的標籤、註解和污點。

Pod 間親緣性和反親緣性的類型

類似於節點親緣性，Pod 親緣性和反親緣性也有兩種類型，如下所示

• requiredDuringSchedulingIgnoredDuringExecution
• preferredDuringSchedulingIgnoredDuringExecution

例如，您可以使用 requiredDuringSchedulingIgnoredDuringExecution 親緣性來告訴排程器將兩個服務的 Pod 共置於同一個雲端供應商區域中，因為它們彼此之間有大量的通訊。同樣地，您可以使用 preferredDuringSchedulingIgnoredDuringExecution 反親緣性將來自某個服務的 Pod 分散到多個雲端供應商區域。

若要使用 Pod 間親緣性，請使用 Pod 規格中的 affinity.podAffinity 欄位。對於 Pod 間反親緣性，請使用 Pod 規格中的 affinity.podAntiAffinity 欄位。

使用 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:2.0

此範例定義了一個 Pod 親緣性規則和一個 Pod 反親緣性規則。Pod 親緣性規則使用「硬性」的 requiredDuringSchedulingIgnoredDuringExecution，而反親緣性規則使用「軟性」的 preferredDuringSchedulingIgnoredDuringExecution。

親緣性規則指定，只有當節點屬於特定區域，且該區域中的其他 Pod 已標記 security=S1 標籤時，排程器才允許將範例 Pod 放置在該節點上。例如，如果我們有一個叢集，其中有一個指定的區域，我們稱之為「區域 V」，由標記為 topology.kubernetes.io/zone=V 的節點組成，則只要區域 V 中至少有一個 Pod 已標記 security=S1 標籤，排程器就可以將 Pod 指派給區域 V 中的任何節點。相反地，如果區域 V 中沒有具有 security=S1 標籤的 Pod，則排程器將不會將範例 Pod 指派給該區域中的任何節點。

反親緣性規則指定，如果節點屬於特定區域，且該區域中的其他 Pod 已標記 security=S2 標籤，則排程器應盡量避免將 Pod 排程到該節點上。例如，如果我們有一個叢集，其中有一個指定的區域，我們稱之為「區域 R」，由標記為 topology.kubernetes.io/zone=R 的節點組成，則只要區域 R 中至少有一個 Pod 已標記 security=S2 標籤，排程器就應避免將 Pod 指派給區域 R 中的任何節點。相反地，如果區域 R 中沒有具有 security=S2 標籤的 Pod，則反親緣性規則不會影響排程到區域 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 是對命名空間集合的標籤查詢。親緣性術語適用於由 namespaceSelector 和 namespaces 欄位選取的命名空間。請注意，空的 namespaceSelector ({}) 會比對所有命名空間，而 null 或空的 namespaces 列表和 null namespaceSelector 則會比對規則定義所在的 Pod 的命名空間。

matchLabelKeys

Kubernetes 包含一個可選的 matchLabelKeys 欄位，用於 Pod 親緣性或反親緣性。該欄位指定了在滿足 Pod（反）親緣性時，應與傳入 Pod 的標籤比對的標籤鍵。

這些鍵用於從 Pod 標籤中查找值；這些鍵值標籤與使用 labelSelector 欄位定義的比對限制結合（使用 AND）。組合篩選會選取將納入 Pod（反）親緣性計算的現有 Pod 集合。

常見的用例是將 matchLabelKeys 與 pod-template-hash 一起使用（在作為 Deployment 一部分管理的 Pod 上設定，其中每個修訂版本的值都是唯一的）。在 matchLabelKeys 中使用 pod-template-hash 允許您鎖定與傳入 Pod 屬於相同修訂版本的 Pod，以便滾動升級不會破壞親緣性。

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 標籤匹配的標籤鍵。

一個範例用例是確保 Pod 進入拓撲網域（節點、區域等），其中僅排程來自相同租戶或團隊的 Pod。換句話說，您希望避免在同一個拓撲網域中同時執行來自兩個不同租戶的 Pod。

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 hate Pods from daemonsets as well, for example,
          # which aren't supposed to have the tenant label.
          matchExpressions:
          - key: tenant
            operator: Exists
        topologyKey: node-pool

更多實際的用例

當 Pod 間親和性和反親和性與更高層級的集合（例如 ReplicaSet、StatefulSet、Deployment 等）一起使用時，可能會更加有用。這些規則可讓您配置一組工作負載應共置在相同的定義拓撲中；例如，偏好將兩個相關的 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

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

使用 nodeName 選取節點的一些限制包括：

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

以下是使用 nodeName 欄位的 Pod 規格範例

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

上述 Pod 將僅在節點 kube-01 上執行。

Pod 拓撲分散約束

您可以使用拓撲分散約束來控制 Pod 如何分散在您的叢集中，分佈於故障網域（例如區域、可用區域、節點）或您定義的任何其他拓撲網域之間。您可以這樣做以提高效能、預期的可用性或整體利用率。

請閱讀 Pod 拓撲分散約束以瞭解更多關於這些約束如何運作的資訊。

運算子

以下是您可以在上述 nodeAffinity 和 podAffinity 的 operator 欄位中使用的所有邏輯運算子。

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

下一步

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