将 Pod 分配给节点

你可以约束一个 Pod 只能在特定的 节点 上运行，或者优先运行在特定的节点上。 有几种方法可以实现这点，推荐的方法都是用 标签选择算符来进行选择。 通常这样的约束不是必须的，因为调度器将自动进行合理的放置（比如，将 Pod 分散到节点上， 而不是将 Pod 放置在可用资源不足的节点上等等）。但在某些情况下，你可能需要进一步控制 Pod 停靠的节点，例如，确保 Pod 最终落在连接了 SSD 的机器上，或者将来自两个不同的服务 且有大量通信的 Pods 被放置在同一个可用区。

nodeSelector

nodeSelector 是节点选择约束的最简单推荐形式。nodeSelector 是 PodSpec 的一个字段。 它包含键值对的映射。为了使 pod 可以在某个节点上运行，该节点的标签中 必须包含这里的每个键值对（它也可以具有其他标签）。 最常见的用法的是一对键值对。

让我们来看一个使用 nodeSelector 的例子。

步骤零：先决条件

本示例假设你已基本了解 Kubernetes 的 Pod 并且已经建立一个 Kubernetes 集群。

步骤一：添加标签到节点

执行 kubectl get nodes 命令获取集群的节点名称。 选择一个你要增加标签的节点，然后执行 kubectl label nodes <node-name> <label-key>=<label-value> 命令将标签添加到你所选择的节点上。 例如，如果你的节点名称为 ‘kubernetes-foo-node-1.c.a-robinson.internal’ 并且想要的标签是 ‘disktype=ssd’，则可以执行 kubectl label nodes kubernetes-foo-node-1.c.a-robinson.internal disktype=ssd 命令。

你可以通过重新运行 kubectl get nodes --show-labels， 查看节点当前具有了所指定的标签来验证它是否有效。 你也可以使用 kubectl describe node "nodename" 命令查看指定节点的标签完整列表。

步骤二：添加 nodeSelector 字段到 Pod 配置中

选择任何一个你想运行的 Pod 的配置文件，并且在其中添加一个 nodeSelector 部分。 例如，如果下面是我的 pod 配置：

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4.   name: nginx
  5.   labels:
  6.     env: test
  7. spec:
  8.   containers:
  9.   - name: nginx
  10.     image: nginx

然后像下面这样添加 nodeSelector：

pods/pod-nginx.yaml 将 Pod 分配给节点 - 图1

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4.   name: nginx
  5.   labels:
  6.     env: test
  7. spec:
  8.   containers:
  9.   - name: nginx
  10.     image: nginx
  11.     imagePullPolicy: IfNotPresent
  12.   nodeSelector:
  13.     disktype: ssd

当你之后运行 kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml 命令， Pod 将会调度到将标签添加到的节点上。 你可以通过运行 kubectl get pods -o wide 并查看分配给 pod 的 “NODE” 来验证其是否有效。

插曲：内置的节点标签

除了你添加的标签外，节点还预先填充了一组标准标签。 这些标签有：

说明：

这些标签的值是特定于云供应商的，因此不能保证可靠。 例如，kubernetes.io/hostname 的值在某些环境中可能与节点名称相同， 但在其他环境中可能是一个不同的值。

节点隔离/限制

向 Node 对象添加标签可以将 pod 定位到特定的节点或节点组。 这可以用来确保指定的 Pod 只能运行在具有一定隔离性，安全性或监管属性的节点上。 当为此目的使用标签时，强烈建议选择节点上的 kubelet 进程无法修改的标签键。 这可以防止受感染的节点使用其 kubelet 凭据在自己的 Node 对象上设置这些标签， 并影响调度器将工作负载调度到受感染的节点。

NodeRestriction 准入插件防止 kubelet 使用 node-restriction.kubernetes.io/ 前缀设置或修改标签。要使用该标签前缀进行节点隔离：

  1. 检查是否在使用 Kubernetes v1.11+，以便 NodeRestriction 功能可用。
  2. 确保你在使用节点授权并且已经_启用_ NodeRestriction 准入插件。
  3. 将 node-restriction.kubernetes.io/ 前缀下的标签添加到 Node 对象， 然后在节点选择器中使用这些标签。 例如，example.com.node-restriction.kubernetes.io/fips=true 或 example.com.node-restriction.kubernetes.io/pci-dss=true。

亲和性与反亲和性

nodeSelector 提供了一种非常简单的方法来将 Pod 约束到具有特定标签的节点上。 亲和性/反亲和性功能极大地扩展了你可以表达约束的类型。关键的增强点包括：

  1. 语言更具表现力（不仅仅是“对完全匹配规则的 AND”）
  2. 你可以发现规则是“软需求”/“偏好”，而不是硬性要求，因此， 如果调度器无法满足该要求，仍然调度该 Pod
  3. 你可以使用节点上（或其他拓扑域中）的 Pod 的标签来约束，而不是使用 节点本身的标签，来允许哪些 pod 可以或者不可以被放置在一起。

亲和性功能包含两种类型的亲和性，即“节点亲和性”和“Pod 间亲和性/反亲和性”。 节点亲和性就像现有的 nodeSelector（但具有上面列出的前两个好处），然而 Pod 间亲和性/反亲和性约束 Pod 标签而不是节点标签（在上面列出的第三项中描述， 除了具有上面列出的第一和第二属性）。

节点亲和性

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

目前有两种类型的节点亲和性，分别为 requiredDuringSchedulingIgnoredDuringExecution 和 preferredDuringSchedulingIgnoredDuringExecution。 你可以视它们为“硬需求”和“软需求”，意思是，前者指定了将 Pod 调度到一个节点上 必须满足的规则（就像 nodeSelector 但使用更具表现力的语法）， 后者指定调度器将尝试执行但不能保证的偏好。 名称的“IgnoredDuringExecution”部分意味着，类似于 nodeSelector 的工作原理， 如果节点的标签在运行时发生变更，从而不再满足 Pod 上的亲和性规则，那么 Pod 将仍然继续在该节点上运行。 将来我们计划提供 requiredDuringSchedulingRequiredDuringExecution， 它将类似于 requiredDuringSchedulingIgnoredDuringExecution， 除了它会将 pod 从不再满足 pod 的节点亲和性要求的节点上驱逐。

因此，requiredDuringSchedulingIgnoredDuringExecution 的示例将是 “仅将 Pod 运行在具有 Intel CPU 的节点上”，而 preferredDuringSchedulingIgnoredDuringExecution 的示例为 “尝试将这组 Pod 运行在 XYZ 故障区域，如果这不可能的话，则允许一些 Pod 在其他地方运行”。

节点亲和性通过 PodSpec 的 affinity 字段下的 nodeAffinity 字段进行指定。

下面是一个使用节点亲和性的 Pod 的实例：

pods/pod-with-node-affinity.yaml 将 Pod 分配给节点 - 图2

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4.   name: with-node-affinity
  5. spec:
  6.   affinity:
  7.     nodeAffinity:
  8.       requiredDuringSchedulingIgnoredDuringExecution:
  9.         nodeSelectorTerms:
  10.         - matchExpressions:
  11.           - key: kubernetes.io/e2e-az-name
  12.             operator: In
  13.             values:
  14.             - e2e-az1
  15.             - e2e-az2
  16.       preferredDuringSchedulingIgnoredDuringExecution:
  17.       - weight: 1
  18.         preference:
  19.           matchExpressions:
  20.           - key: another-node-label-key
  21.             operator: In
  22.             values:
  23.             - another-node-label-value
  24.   containers:
  25.   - name: with-node-affinity
  26.     image: k8s.gcr.io/pause:2.0

此节点亲和性规则表示，Pod 只能放置在具有标签键 kubernetes.io/e2e-az-name 且标签值为 e2e-az1 或 e2e-az2 的节点上。 另外，在满足这些标准的节点中，具有标签键为 another-node-label-key 且标签值为 another-node-label-value 的节点应该优先使用。

你可以在上面的例子中看到 In 操作符的使用。新的节点亲和性语法支持下面的操作符： In，NotIn，Exists，DoesNotExist，Gt，Lt。 你可以使用 NotIn 和 DoesNotExist 来实现节点反亲和性行为，或者使用 节点污点 将 Pod 从特定节点中驱逐。

如果你同时指定了 nodeSelector 和 nodeAffinity，两者必须都要满足， 才能将 Pod 调度到候选节点上。

如果你指定了多个与 nodeAffinity 类型关联的 nodeSelectorTerms，则 如果其中一个 nodeSelectorTerms 满足的话，pod将可以调度到节点上。

如果你指定了多个与 nodeSelectorTerms 关联的 matchExpressions，则 只有当所有 matchExpressions 满足的话，Pod 才会可以调度到节点上。

如果你修改或删除了 pod 所调度到的节点的标签，Pod 不会被删除。 换句话说，亲和性选择只在 Pod 调度期间有效。

preferredDuringSchedulingIgnoredDuringExecution 中的 weight 字段值的 范围是 1-100。 对于每个符合所有调度要求（资源请求、RequiredDuringScheduling 亲和性表达式等） 的节点，调度器将遍历该字段的元素来计算总和，并且如果节点匹配对应的 MatchExpressions，则添加“权重”到总和。 然后将这个评分与该节点的其他优先级函数的评分进行组合。 总分最高的节点是最优选的。

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

FEATURE STATE: Kubernetes v1.20 [beta]

在配置多个调度方案时， 你可以将某个方案与节点亲和性关联起来，如果某个调度方案仅适用于某组 特殊的节点时，这样做是很有用的。 要实现这点，可以在调度器配置中为 NodeAffinity 插件 添加 addedAffinity 参数。 例如：

  1. apiVersion: kubescheduler.config.k8s.io/v1beta1
  2. kind: KubeSchedulerConfiguration
  4. profiles:
  5.   - schedulerName: default-scheduler
  6.   - schedulerName: foo-scheduler
  7.     pluginConfig:
  8.       - name: NodeAffinity
  9.         args:
  10.           addedAffinity:
  11.             requiredDuringSchedulingIgnoredDuringExecution:
  12.               nodeSelectorTerms:
  13.               - matchExpressions:
  14.                 - key: scheduler-profile
  15.                   operator: In
  16.                   values:
  17.                   - foo

这里的 addedAffinity 除遵从 Pod 规约中设置的节点亲和性之外，还 适用于将 .spec.schedulerName 设置为 foo-scheduler。

说明： DaemonSet 控制器为 DaemonSet 创建 Pods， 但该控制器不理会调度方案。因此，建议你保留一个调度方案，例如 default-scheduler，不要在其中设置 addedAffinity。 这样，DaemonSet 的 Pod 模板将会使用此调度器名称。 否则，DaemonSet 控制器所创建的某些 Pods 可能持续处于不可调度状态。

pod 间亲和性与反亲和性

Pod 间亲和性与反亲和性使你可以 基于已经在节点上运行的 Pod 的标签 来约束 Pod 可以调度到的节点，而不是基于节点上的标签。 规则的格式为“如果 X 节点上已经运行了一个或多个 满足规则 Y 的 Pod， 则这个 Pod 应该（或者在反亲和性的情况下不应该）运行在 X 节点”。 Y 表示一个具有可选的关联命令空间列表的 LabelSelector； 与节点不同，因为 Pod 是命名空间限定的（因此 Pod 上的标签也是命名空间限定的）， 因此作用于 Pod 标签的标签选择算符必须指定选择算符应用在哪个命名空间。 从概念上讲，X 是一个拓扑域，如节点、机架、云供应商可用区、云供应商地理区域等。 你可以使用 topologyKey 来表示它，topologyKey 是节点标签的键以便系统 用来表示这样的拓扑域。 请参阅上面插曲：内置的节点标签部分中列出的标签键。

说明：

Pod 间亲和性与反亲和性需要大量的处理，这可能会显著减慢大规模集群中的调度。 我们不建议在超过数百个节点的集群中使用它们。

说明：

Pod 反亲和性需要对节点进行一致的标记，即集群中的每个节点必须具有适当的标签能够匹配 topologyKey。如果某些或所有节点缺少指定的 topologyKey 标签，可能会导致意外行为。

与节点亲和性一样，当前有两种类型的 Pod 亲和性与反亲和性，即 requiredDuringSchedulingIgnoredDuringExecution 和 preferredDuringSchedulingIgnoredDuringExecution，分别表示“硬性”与“软性”要求。 请参阅前面节点亲和性部分中的描述。 requiredDuringSchedulingIgnoredDuringExecution 亲和性的一个示例是 “将服务 A 和服务 B 的 Pod 放置在同一区域，因为它们之间进行大量交流”，而 preferredDuringSchedulingIgnoredDuringExecution 反亲和性的示例将是 “将此服务的 pod 跨区域分布”（硬性要求是说不通的，因为你可能拥有的 Pod 数多于区域数）。

Pod 间亲和性通过 PodSpec 中 affinity 字段下的 podAffinity 字段进行指定。 而 Pod 间反亲和性通过 PodSpec 中 affinity 字段下的 podAntiAffinity 字段进行指定。

Pod 使用 pod 亲和性 的示例：

pods/pod-with-pod-affinity.yaml 将 Pod 分配给节点 - 图3

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4.   name: with-pod-affinity
  5. spec:
  6.   affinity:
  7.     podAffinity:
  8.       requiredDuringSchedulingIgnoredDuringExecution:
  9.       - labelSelector:
  10.           matchExpressions:
  11.           - key: security
  12.             operator: In
  13.             values:
  14.             - S1
  15.         topologyKey: topology.kubernetes.io/zone
  16.     podAntiAffinity:
  17.       preferredDuringSchedulingIgnoredDuringExecution:
  18.       - weight: 100
  19.         podAffinityTerm:
  20.           labelSelector:
  21.             matchExpressions:
  22.             - key: security
  23.               operator: In
  24.               values:
  25.               - S2
  26.           topologyKey: topology.kubernetes.io/zone
  27.   containers:
  28.   - name: with-pod-affinity
  29.     image: k8s.gcr.io/pause:2.0

在这个 Pod 的亲和性配置定义了一条 Pod 亲和性规则和一条 Pod 反亲和性规则。 在此示例中，podAffinity 配置为 requiredDuringSchedulingIgnoredDuringExecution， 然而 podAntiAffinity 配置为 preferredDuringSchedulingIgnoredDuringExecution。 Pod 亲和性规则表示，仅当节点和至少一个已运行且有键为“security”且值为“S1”的标签 的 Pod 处于同一区域时，才可以将该 Pod 调度到节点上。 （更确切的说，如果节点 N 具有带有键 topology.kubernetes.io/zone 和某个值 V 的标签， 则 Pod 有资格在节点 N 上运行，以便集群中至少有一个节点具有键 topology.kubernetes.io/zone 和值为 V 的节点正在运行具有键“security”和值 “S1”的标签的 pod。） Pod 反亲和性规则表示，如果节点处于 Pod 所在的同一可用区且具有键“security”和值“S2”的标签， 则该 pod 不应将其调度到该节点上。 （如果 topologyKey 为 topology.kubernetes.io/zone，则意味着当节点和具有键 “security”和值“S2”的标签的 Pod 处于相同的区域，Pod 不能被调度到该节点上。） 查阅设计文档 以获取 Pod 亲和性与反亲和性的更多样例，包括 requiredDuringSchedulingIgnoredDuringExecution 和 preferredDuringSchedulingIgnoredDuringExecution 两种配置。

Pod 亲和性与反亲和性的合法操作符有 In，NotIn，Exists，DoesNotExist。

原则上，topologyKey 可以是任何合法的标签键。 然而，出于性能和安全原因，topologyKey 受到一些限制：

  1. 对于亲和性与 requiredDuringSchedulingIgnoredDuringExecution 要求的 Pod 反亲和性，topologyKey 不允许为空。
  2. 对于 requiredDuringSchedulingIgnoredDuringExecution 要求的 Pod 反亲和性， 准入控制器 LimitPodHardAntiAffinityTopology 被引入来限制 topologyKey 不为 kubernetes.io/hostname。 如果你想使它可用于自定义拓扑结构，你必须修改准入控制器或者禁用它。
  3. 对于 preferredDuringSchedulingIgnoredDuringExecution 要求的 Pod 反亲和性， 空的 topologyKey 被解释为“所有拓扑结构”（这里的“所有拓扑结构”限制为 kubernetes.io/hostname，topology.kubernetes.io/zone 和 topology.kubernetes.io/region 的组合）。
  4. 除上述情况外，topologyKey 可以是任何合法的标签键。

除了 labelSelector 和 topologyKey，你也可以指定表示命名空间的 namespaces 队列，labelSelector 也应该匹配它 （这个与 labelSelector 和 topologyKey 的定义位于相同的级别）。 如果忽略或者为空，则默认为 Pod 亲和性/反亲和性的定义所在的命名空间。

所有与 requiredDuringSchedulingIgnoredDuringExecution 亲和性与反亲和性 关联的 matchExpressions 必须满足，才能将 pod 调度到节点上。

更实际的用例

Pod 间亲和性与反亲和性在与更高级别的集合（例如 ReplicaSets、StatefulSets、 Deployments 等）一起使用时，它们可能更加有用。 可以轻松配置一组应位于相同定义拓扑（例如，节点）中的工作负载。

始终放置在相同节点上

在三节点集群中，一个 web 应用程序具有内存缓存，例如 redis。 我们希望 web 服务器尽可能与缓存放置在同一位置。

下面是一个简单 redis Deployment 的 YAML 代码段，它有三个副本和选择器标签 app=store。 Deployment 配置了 PodAntiAffinity，用来确保调度器不会将副本调度到单个节点上。

  1. apiVersion: apps/v1
  2. kind: Deployment
  3. metadata:
  4.   name: redis-cache
  5. spec:
  6.   selector:
  7.     matchLabels:
  8.       app: store
  9.   replicas: 3
  10.   template:
  11.     metadata:
  12.       labels:
  13.         app: store
  14.     spec:
  15.       affinity:
  16.         podAntiAffinity:
  17.           requiredDuringSchedulingIgnoredDuringExecution:
  18.           - labelSelector:
  19.               matchExpressions:
  20.               - key: app
  21.                 operator: In
  22.                 values:
  23.                 - store
  24.             topologyKey: "kubernetes.io/hostname"
  25.       containers:
  26.       - name: redis-server
  27.         image: redis:3.2-alpine

下面 webserver Deployment 的 YAML 代码段中配置了 podAntiAffinity 和 podAffinity。 这将通知调度器将它的所有副本与具有 app=store 选择器标签的 Pod 放置在一起。 这还确保每个 web 服务器副本不会调度到单个节点上。

  1. apiVersion: apps/v1
  2. kind: Deployment
  3. metadata:
  4.   name: web-server
  5. spec:
  6.   selector:
  7.     matchLabels:
  8.       app: web-store
  9.   replicas: 3
  10.   template:
  11.     metadata:
  12.       labels:
  13.         app: web-store
  14.     spec:
  15.       affinity:
  16.         podAntiAffinity:
  17.           requiredDuringSchedulingIgnoredDuringExecution:
  18.           - labelSelector:
  19.               matchExpressions:
  20.               - key: app
  21.                 operator: In
  22.                 values:
  23.                 - web-store
  24.             topologyKey: "kubernetes.io/hostname"
  25.         podAffinity:
  26.           requiredDuringSchedulingIgnoredDuringExecution:
  27.           - labelSelector:
  28.               matchExpressions:
  29.               - key: app
  30.                 operator: In
  31.                 values:
  32.                 - store
  33.             topologyKey: "kubernetes.io/hostname"
  34.       containers:
  35.       - name: web-app
  36.         image: nginx:1.16-alpine

如果我们创建了上面的两个 Deployment，我们的三节点集群将如下表所示。

node-1node-2node-3
webserver-1webserver-2webserver-3
cache-1cache-2cache-3

如你所见，web-server 的三个副本都按照预期那样自动放置在同一位置。

  1. kubectl get pods -o wide

输出类似于如下内容：

  1. NAME                           READY     STATUS    RESTARTS   AGE       IP           NODE
  2. redis-cache-1450370735-6dzlj   1/1       Running   0          8m        10.192.4.2   kube-node-3
  3. redis-cache-1450370735-j2j96   1/1       Running   0          8m        10.192.2.2   kube-node-1
  4. redis-cache-1450370735-z73mh   1/1       Running   0          8m        10.192.3.1   kube-node-2
  5. web-server-1287567482-5d4dz    1/1       Running   0          7m        10.192.2.3   kube-node-1
  6. web-server-1287567482-6f7v5    1/1       Running   0          7m        10.192.4.3   kube-node-3
  7. web-server-1287567482-s330j    1/1       Running   0          7m        10.192.3.2   kube-node-2
永远不放置在相同节点

上面的例子使用 PodAntiAffinity 规则和 topologyKey: "kubernetes.io/hostname" 来部署 redis 集群以便在同一主机上没有两个实例。 参阅 ZooKeeper 教程， 以获取配置反亲和性来达到高可用性的 StatefulSet 的样例（使用了相同的技巧）。

nodeName

nodeName 是节点选择约束的最简单方法，但是由于其自身限制，通常不使用它。 nodeName 是 PodSpec 的一个字段。 如果它不为空，调度器将忽略 Pod，并且给定节点上运行的 kubelet 进程尝试执行该 Pod。 因此，如果 nodeName 在 PodSpec 中指定了，则它优先于上面的节点选择方法。

使用 nodeName 来选择节点的一些限制：

  • 如果指定的节点不存在，
  • 如果指定的节点没有资源来容纳 Pod，Pod 将会调度失败并且其原因将显示为， 比如 OutOfmemory 或 OutOfcpu。
  • 云环境中的节点名称并非总是可预测或稳定的。

下面的是使用 nodeName 字段的 Pod 配置文件的例子：

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4.   name: nginx
  5. spec:
  6.   containers:
  7.   - name: nginx
  8.     image: nginx
  9.   nodeName: kube-01

上面的 pod 将运行在 kube-01 节点上。

接下来

污点 允许节点排斥一组 Pod。

节点亲和性与 pod 间亲和性/反亲和性 的设计文档包含这些功能的其他背景信息。

一旦 Pod 分配给 节点，kubelet 应用将运行该 pod 并且分配节点本地资源。 拓扑管理器 可以参与到节点级别的资源分配决定中。