将 Pod 分配给 Node

你可以限制一个 Pod，使其被约束运行在特定的 节点上，或者优先运行在特定的节点上。有几种方法可以实现这一点，推荐的方法都使用 标签选择器 来促进选择。通常，你不需要设置任何此类约束；调度器 会自动进行合理的安置（例如，将你的 Pod 分散到各个节点上，以便不会将 Pod 放置在资源不足的节点上）。然而，在某些情况下，你可能想要控制 Pod 部署到哪个节点，例如，确保 Pod 最终落在附加了 SSD 的节点上，或者将大量通信的两个不同服务的 Pod 共同安置在同一个可用区内。

你可以使用以下任何一种方法来选择 Kubernetes 调度特定 Pod 的位置

• 通过 nodeSelector 字段与 节点标签 匹配
• 亲和性与反亲和性
• nodeName 字段
• Pod 拓扑分布约束

节点标签

与许多其他 Kubernetes 对象一样，节点也有标签。你可以手动添加标签。Kubernetes 还会为集群中的所有节点填充一组标准标签。

节点隔离/限制

为节点添加标签允许你将 Pod 定向调度到特定的节点或节点组。你可以使用此功能来确保特定的 Pod 仅运行在具有某些隔离、安全或合规性属性的节点上。

如果你使用标签进行节点隔离，请选择 kubelet 无法修改的标签键。这可以防止受损的节点自行设置这些标签，从而避免调度器将工作负载调度到受损节点上。

NodeRestriction 准入插件 可以防止 kubelet 设置或修改带有 node-restriction.kubernetes.io/ 前缀的标签。

要利用该标签前缀进行节点隔离

1. 确保你正在使用节点鉴权器（Node authorizer） 并已启用 NodeRestriction 准入插件。
2. 为你的节点添加带有 node-restriction.kubernetes.io/ 前缀的标签，并在你的 节点选择器（node selectors） 中使用这些标签。例如，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 只选择具有所有指定标签的节点。亲和性/反亲和性让你对选择逻辑有更多的控制权。
• 你可以指明规则是软性（soft） 或偏好（preferred） 的，以便即使调度器找不到匹配的节点，仍然可以调度 Pod。
• 你可以使用运行在节点（或其他拓扑域）上的其他 Pod 的标签来约束 Pod，而不仅仅是使用节点标签，这允许你定义哪些 Pod 可以被共同安置在同一个节点上的规则。

亲和性特性包含两种类型的亲和性：

• 节点亲和性（Node affinity） 功能类似于 nodeSelector 字段，但更具表现力，允许你指定软性规则。
• Pod 间亲和性/反亲和性（Inter-pod affinity/anti-affinity） 允许你根据运行在节点上的其他 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 允许你定义节点反亲和行为。或者，你可以使用节点污点（node taints）来排斥 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: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

除了 PodSpec 中指定的 NodeAffinity 外，addedAffinity 也应用于所有将 .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)，它是系统用来表示该域的节点标签的键。有关示例，请参阅已知标签、注解和污点。

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:3.8

此示例定义了一个 Pod 亲和性规则和一个 Pod 反亲和性规则。Pod 亲和性规则使用“硬性（hard）”的 requiredDuringSchedulingIgnoredDuringExecution，而反亲和性规则使用“软性（soft）”的 preferredDuringSchedulingIgnoredDuringExecution。

亲和性规则指定，只有当节点属于特定的区域（zone），并且该区域中有其他 Pod 已被标记为 security=S1 时，调度器才被允许将示例 Pod 放置在该节点上。例如，如果我们的集群有一个指定的区域，我们称之为“V 区”，该区域由带有 topology.kubernetes.io/zone=V 标签的节点组成，只要 V 区内至少有一个 Pod 已被标记为 security=S1，调度器就可以将 Pod 分配到 V 区内的任何节点。反之，如果 V 区内没有带有 security=S1 标签的 Pod，调度器就不会将示例 Pod 分配到该区域的任何节点上。

反亲和性规则指定，如果节点属于特定的区域（zone），并且该区域中有其他 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 和 topologyKey 同级的 namespaces 字段中指定 labelSelector 应该匹配的命名空间列表。如果省略或为空，namespaces 默认为定义亲和性/反亲和性的 Pod 所在的命名空间。

命名空间选择器

你还可以使用 namespaceSelector 选择匹配的命名空间，它是对命名空间集合的标签查询。亲和性术语应用于由 namespaceSelector 和 namespaces 字段同时选择的命名空间。请注意，空的 namespaceSelector ({}) 匹配所有命名空间，而 null 或空的 namespaces 列表以及 null 的 namespaceSelector 匹配规则定义所在的 Pod 的命名空间。

matchLabelKeys

Kubernetes 包含一个可选的 matchLabelKeys 字段用于 Pod 亲和性或反亲和性。此字段指定在满足 Pod (反)亲和性时，应与传入 Pod 的标签匹配的标签键。

这些键用于从 Pod 标签中查找值；这些键值标签与使用 labelSelector 字段定义的匹配限制相结合（使用 AND 逻辑）。组合过滤会选择一组现有的 Pod，这些 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 have 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 间亲和性与反亲和性与 ReplicaSets、StatefulSets、Deployments 等更高级别的集合一起使用时，它们会更加有用。这些规则允许你配置一组工作负载应该被共同安置在同一个定义的拓扑中；例如，偏好将两个相关的 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 上运行。

Pod 拓扑分布约束

你可以使用 拓扑分布约束（topology spread constraints） 来控制 Pods 如何跨集群分布在故障域中，例如地域、区域、节点或任何你定义的其他拓扑域。你这样做可能是为了提升性能、预期可用性或整体利用率。

阅读 Pod 拓扑分布约束 来了解更多关于它们如何工作的信息。

操作符

以下是你在上述 nodeAffinity 和 podAffinity 的 operator 字段中可以使用的所有逻辑操作符。

以下操作符只能与 nodeAffinity 一起使用。

接下来

• 阅读更多关于 污点和容忍度 的信息。
• 阅读 节点亲和性 和 Pod 间亲和性/反亲和性 的设计文档。
• 了解 拓扑管理器 如何参与节点级别资源分配决策。
• 学习如何使用 nodeSelector。
• 学习如何使用 亲和性与反亲和性。