将 Pod 分配到节点

您可以约束一个 Pod，以便它受限于在特定节点(s) 上运行，或者偏好在特定节点上运行。有几种方法可以做到这一点，推荐的方法都使用 标签选择器 来简化选择。通常，您不需要设置任何此类约束；调度程序 将自动进行合理的放置（例如，将 Pod 分散到各个节点上，以便不将 Pod 放置在没有足够可用资源的节点上）。但是，在某些情况下，您可能希望控制 Pod 部署到的节点，例如，确保 Pod 最终位于连接了 SSD 的节点上，或者将来自两个不同服务（它们之间进行大量通信）的 Pod 共同定位到同一个可用区中。

您可以使用以下任何方法来选择 Kubernetes 在哪里调度特定的 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 调度到最终分数最高的节点上。

每个调度配置文件的节点亲和性

功能状态: Kubernetes v1.20 [beta]

在配置多个 调度配置文件 时，您可以将配置文件与节点亲和性关联起来，这在配置文件仅适用于特定节点集时非常有用。为此，请将 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 将应用于所有将 .spec.schedulerName 设置为 foo-scheduler 的 Pod，此外还应用于 PodSpec 中指定的 NodeAffinity。也就是说，为了匹配 Pod，节点需要满足 addedAffinity 和 Pod 的 .spec.NodeAffinity。

由于 addedAffinity 对最终用户不可见，因此其行为可能对他们来说是不可预期的。请使用与调度程序配置文件名称有明确关联的节点标签。

Pod 间亲和性和反亲和性

Pod 间亲和性和反亲和性允许您根据节点上已运行的 **Pod** 的标签（而不是节点标签）来约束 Pod 可以被调度到的节点。

Pod 间亲和性和反亲和性规则的形式为“此 Pod 应该（或在反亲和性的情况下不应）运行在一个 X 中，如果该 X 已经在运行一个或多个满足规则 Y 的 Pod”，其中 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:2.0

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

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

反亲和性规则指定如果该节点属于特定的 区域，其中其他 Pod 已被标记为 security=S2，则调度程序应尽量避免将 Pod 调度到该节点上。例如，如果我们有一个带有指定区域的集群，我们称之为“区域 R”，该区域由标记为 topology.kubernetes.io/zone=R 的节点组成，则调度程序应避免将 Pod 分配给区域 R 中的任何节点，只要区域 R 中至少有一个 Pod 已被标记为 security=S2。相反，如果区域 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 的命名空间。

命名空间选择器

功能状态： Kubernetes v1.24 [稳定]

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

matchLabelKeys

功能状态： Kubernetes v1.31 [beta]

Kubernetes 包含一个可选的 matchLabelKeys 字段，用于 Pod 亲和性或反亲和性。该字段指定标签的键，这些标签应该与传入 Pod 的标签匹配，以满足 Pod（反）亲和性。

这些键用于从 pod 标签中查找值；这些键值标签与使用 labelSelector 字段定义的匹配限制相结合（使用 AND）。组合过滤选择将被纳入 Pod（反）亲和性计算的现有 pod 集。

一个常见的用例是将 matchLabelKeys 与 pod-template-hash（在作为部署的一部分管理的 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 v1.31 [beta]

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 缓存的以下示例部署中，副本获得了标签 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 服务器创建了具有标签 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

创建前两个部署会导致以下集群布局，其中每个 Web 服务器都与一个缓存共同放置在三个不同的节点上。

节点-1节点-2节点-3
webserver-1webserver-2webserver-3
cache-1cache-2cache-3

总体效果是每个缓存实例都可能被运行在同一节点上的单个客户端访问。这种方法旨在最大限度地减少偏差（负载不平衡）和延迟。

您可能还有其他原因使用 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 拓扑传播约束

您可以使用拓扑分布约束来控制 Pods 在集群中的故障域（例如区域、区域、节点或您定义的任何其他拓扑域）中的分布方式。您可能这样做是为了提高性能、预期可用性或总体利用率。

阅读 Pod 拓扑分布约束 以详细了解其工作原理。

操作符

以下是您可以在上面提到的 nodeAffinity 和 podAffinity 的 operator 字段中使用的所有逻辑运算符。

操作符行为
In标签值存在于提供的字符串集中
NotIn标签值未包含在提供的字符串集中
Exists对象上存在带有此键的标签
DoesNotExist对象上不存在带有此键的标签

以下运算符只能与 nodeAffinity 一起使用。

操作符行为
Gt字段值将被解析为整数，并且该整数小于解析此选择器命名的标签的值的结果的整数
Lt字段值将被解析为整数，并且该整数大于解析此选择器命名的标签的值的结果的整数

下一步

最后修改时间：2024 年 7 月 26 日，太平洋标准时间上午 5:03：graduate MatchLabelKeysInPodAffinity to beta (#45181) (108e2a9f0f)