将 Pod 指派给节点

你可以约束一个 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/ 前缀的标签添加到 Node 对象，然后在节点选择算符中使用这些标签。例如，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 可以被放置在一起。

亲和性功能由两种类型的亲和性组成：

• 节点亲和性功能类似于 nodeSelector 字段，但它的表达能力更强，并且允许你指定软规则。
• Pod 间亲和性/反亲和性允许你根据其他 Pod 的标签来约束 Pod。

节点亲和性

节点亲和性概念上类似于 nodeSelector，它使你可以根据节点上的标签来约束 Pod 可以调度到哪些节点上。节点亲和性有两种：

• requiredDuringSchedulingIgnoredDuringExecution：调度器只有在规则被满足的时候才能执行调度。此功能类似于 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 之一作为操作符。

阅读操作符了解有关这些操作的更多信息。

Pod 拓扑标签

如果 Pod 所属的节点存在拓扑标签（topology.kubernetes.io/zone 和 topology.kubernetes.io/region），则 Pod 会继承这些标签。然后，Pod 可以通过 Downward API 使用这些标签，使工作负载能够感知节点拓扑结构。

以下是一个 Pod 使用 Downward API 获取其 zone 和 region 的示例：

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-topology-labels
spec:
  containers:
    - name: app
      image: alpine
      command: ["sh", "-c", "env"]
      env:
        - name: MY_ZONE
          valueFrom:
            fieldRef:
              fieldPath: metadata.labels['topology.kubernetes.io/zone']
        - name: MY_REGION
          valueFrom:
            fieldRef:
              fieldPath: metadata.labels['topology.kubernetes.io/region']

NotIn 和 DoesNotExist 可用来实现节点反亲和性行为。你也可以使用节点污点 将 Pod 从特定节点上驱逐。

参阅使用节点亲和性来为 Pod 指派节点，以了解进一步的信息。

节点亲和性权重

你可以为 preferredDuringSchedulingIgnoredDuringExecution 亲和性类型的每个实例设置weight 字段，其取值范围是 1 到 100。当调度器找到能够满足 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 取值，并将该权重值添加到节点的其他得分值之上，

逐个调度方案中设置节点亲和性

在配置多个调度方案时，你可以将某个方案与节点亲和性关联起来，如果某个调度方案仅适用于某组特殊的节点时，这样做是很有用的。要实现这点，可以在调度器配置中为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 除遵从 Pod 规约中设置的节点亲和性之外，还适用于将 .spec.schedulerName 设置为 foo-scheduler。换言之，为了匹配 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 亲和性来告诉调度器，将两个服务的 Pod 放到同一个云提供商可用区内，因为它们彼此之间通信非常频繁。类似地，你可以使用 preferredDuringSchedulingIgnoredDuringExecution 反亲和性来将同一服务的多个 Pod 分布到多个云提供商可用区中。

要使用 Pod 间亲和性，可以使用 Pod 规约中的 .affinity.podAffinity 字段。对于 Pod 间反亲和性，可以使用 Pod 规约中的 .affinity.podAntiAffinity 字段。

调度行为

在调度新 Pod 时，Kubernetes 调度器会根据当前集群状态评估 Pod 的亲和性/反亲和性规则：

1. 硬约束（节点过滤）：
   • podAffinity.requiredDuringSchedulingIgnoredDuringExecution 和podAntiAffinity.requiredDuringSchedulingIgnoredDuringExecution：
     • 调度器基于现有 Pod，确保新 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:2.0

本示例定义了一条 Pod 亲和性规则和一条 Pod 反亲和性规则。Pod 亲和性规则配置为requiredDuringSchedulingIgnoredDuringExecution，而 Pod 反亲和性配置为preferredDuringSchedulingIgnoredDuringExecution。

亲和性规则规定，只有节点属于特定的区域 且该区域中的其他 Pod 已打上 security=S1 标签时，调度器才可以将示例 Pod 调度到此节点上。例如，如果我们有一个具有指定区域（称之为 "Zone V"）的集群，此区域由带有 topology.kubernetes.io/zone=V 标签的节点组成，那么只要 Zone V 内已经至少有一个 Pod 打了 security=S1 标签，调度器就可以将此 Pod 调度到 Zone V 内的任何节点。相反，如果 Zone V 中没有带有 security=S1 标签的 Pod，则调度器不会将示例 Pod 调度给该区域中的任何节点。

反亲和性规则规定，如果节点属于特定的区域 且该区域中的其他 Pod 已打上 security=S2 标签，则调度器应尝试避免将 Pod 调度到此节点上。例如，如果我们有一个具有指定区域（我们称之为 "Zone R"）的集群，此区域由带有 topology.kubernetes.io/zone=R 标签的节点组成，只要 Zone R 内已经至少有一个 Pod 打了 security=S2 标签，调度器应避免将 Pod 分配给 Zone R 内的任何节点。相反，如果 Zone R 中没有带有 security=S2 标签的 Pod，则反亲和性规则不会影响将 Pod 调度到 Zone R。

查阅设计文档 以进一步熟悉 Pod 亲和性与反亲和性的示例。

你可以针对 Pod 间亲和性与反亲和性为其 operator 字段使用 In、NotIn、Exists、DoesNotExist 等值。

阅读操作符了解有关这些操作的更多信息。

原则上，topologyKey 可以是任何合法的标签键。出于性能和安全原因，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 在 Pod 亲和性或反亲和性中包含一个可选的 matchLabelKeys 字段。此字段指定了应与传入 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
            # 只有在计算 Pod 亲和性时，才考虑指定上线的 Pod。
            # 如果你更新 Deployment，替代的 Pod 将遵循它们自己的亲和性规则
            # （如果在新的 Pod 模板中定义了任何规则）。
            matchLabelKeys:
            - pod-template-hash

mismatchLabelKeys

Kubernetes 为 Pod 亲和性或反亲和性提供了一个可选的 mismatchLabelKeys 字段。此字段指定了在满足 Pod（反）亲和性时，不应与传入 Pod 的标签匹配的键。

一个示例用例是确保 Pod 进入指定的拓扑域（节点、区域等），在此拓扑域中只调度来自同一租户或团队的 Pod。换句话说，你想要避免在同一拓扑域中同时运行来自两个不同租户的 Pod。

apiVersion: v1
kind: Pod
metadata:
  labels:
    # 假设所有相关的 Pod 都设置了 “tenant” 标签
    tenant: tenant-a
...
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      # 确保与此租户关联的 Pod 落在正确的节点池上
      - matchLabelKeys:
          - tenant
        labelSelector: {}
        topologyKey: node-pool
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      # 确保与此租户关联的 Pod 不能调度到用于其他租户的节点上
      - mismatchLabelKeys:
        - tenant # 无论此 Pod 的 “tenant” 标签的值是什么，
                 # 如果节点池中有来自别的租户的任何 Pod 在运行，
                 # 都会阻碍此 Pod 被调度到这些节点池中的节点上
        labelSelector:
          # 我们必须有一个 labelSelector，只选择具有 “tenant” 标签的 Pod，
          # 否则此 Pod 也会与来自 DaemonSet 的 Pod 产生反亲和性，
          # 例如，这些 Pod 不应该具有 “tenant” 标签
          matchExpressions:
          - key: tenant
            operator: Exists
        topologyKey: node-pool

更实际的用例

Pod 间亲和性与反亲和性在与更高级别的集合（例如 ReplicaSet、StatefulSet、Deployment等）一起使用时，它们可能更加有用。这些规则使得你可以配置一组工作负载，使其位于所定义的同一拓扑中；例如优先将两个相关的 Pod 置于相同的节点上。

以一个三节点的集群为例。你使用该集群运行一个带有内存缓存（例如 Redis）的 Web 应用程序。在此例中，还假设 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

下例的 Deployment 为 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

创建前面两个 Deployment 会产生如下的集群布局，每个 Web 服务器与一个缓存实例并置，并分别运行在三个独立的节点上。

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

你可能还有使用 Pod 反亲和性的一些其他原因。参阅 ZooKeeper 教程 了解一个 StatefulSet 的示例，该 StatefulSet 配置了反亲和性以实现高可用，所使用的是与此例相同的技术。

nodeName

nodeName 是比亲和性或者 nodeSelector 更为直接的形式。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 之上。

nominatedNodeName

外部组件可以使用 nominatedNodeName 为待处理的 Pod 提名节点。这种提名是尽力而为的：如果调度器确定 Pod 不能进入被提名的节点，那么这个提名可能会被忽略。

此外，此字段可以由调度器（重新）写入：

• 如果调度器通过抢占找到一个可提名的节点。
• 如果调度器决定了 Pod 的去向，并将其移至绑定阶段。
  • 注意，在这种情况下，仅当 Pod 必须经过 WaitOnPermit 或PreBind 扩展点时，才会设置 nominatedNodeName。

以下是使用 nominatedNodeName 字段的 Pod 状态示例：

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

Pod 拓扑分布约束

你可以使用 拓扑分布约束（Topology Spread Constraints） 来控制Pod 在集群内故障域之间的分布，故障域的示例有区域（Region）、可用区（Zone）、节点和其他用户自定义的拓扑域。这样做有助于提升性能、实现高可用或提升资源利用率。

阅读 Pod 拓扑分布约束 以进一步了解这些约束的工作方式。

操作符

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

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

接下来

• 进一步阅读污点与容忍度文档。
• 阅读节点亲和性和Pod 间亲和性与反亲和性的设计文档。
• 了解拓扑管理器如何参与节点层面资源分配决定。
• 了解如何使用 nodeSelector。
• 了解如何使用亲和性和反亲和性。