Kubernetes高级调度02
目录
一：Taint(污点)和Toleration(容忍)
1:污点和容忍的基本概念
2:污点的使用
3:容忍的定义
4:示例
(1)设置污点
(2)创建测试模板
(3)运行
(4)在两个 Node 上都设置了污点后，此时 Pod 将无法创建成功
(5)修改测试模板
(6)运行新的 pod
(7)在设置了容忍之后，Pod 创建成功
5:容忍的基本用法
(1)容忍污点的条件
(2)另外还有如下两个特例:
(3)一些特殊的使用场景
6:多污点与多容忍配置
二：警戒(cordon)和 转移(drain)
1:设置警戒
2:kubectl uncordon 将 Node 标记为可调度的状态s(取消警戒)
3:驱逐(转移)pod
三:K8s亲和性和非亲和性
1:亲和性调度可以分成软策略和硬策略两种方式
2:亲和性的配置规则
3:节点硬亲和性
(1)设置节点标签
(2)查看节点标签
(3)设置 pod 亲和性为 type=node1
(4)部署 pod 并查看其信息
(5)设置 pod 亲和性为 type=node02
(6)部署 pod 并查看其信息
4:节点软亲和性
(1)为 pod 设置软亲和性
(2)部署 pod 并查看其信息
5:Pod 硬亲和度
(1)部署第一个基础 Pod，名字为 pod04，使其节点硬亲和到 node01
(2)部署并查看其信息
(3)部署第二个基础 Pod，名字为 pod05，使其节点硬亲和到 node02
(4)部署并查看其信息
(5)用pod 硬亲和创建一个亲和 pod05 的 pod
(6)部署此 pod
7:Pod 软亲和度
(1)编辑pod07 的 pod
(2)编辑pod08 的 pod
8:pod 反亲和
一：Taint(污点)和Toleration(容忍)
在生产环境中，经常会有这样的需求:
| 需求场景 | 实现方法 | 示例 YAML 片段 |
|---|---|---|
| 1. Master 节点仅部署系统组件（如 Calico、Dashboard） | 为 Master 节点添加污点，仅允许带有特定容忍的系统 Pod 调度。 | yaml<br># Master 节点污点<br>kubectl taint nodes master node-role.kubernetes.io/master=:NoSchedule<br><br># 系统 Pod 的容忍<br>tolerations:<br>- key: "node-role.kubernetes.io/master"<br> operator: "Exists"<br> effect: "NoSchedule"<br> |
| 2. 新节点需测试后才能部署业务容器 | 新节点添加临时污点（如 pre-deploy-check=:NoSchedule），测试通过后移除污点或为业务 Pod 添加容忍。 | yaml<br># 新节点污点<br>kubectl taint nodes new-node pre-deploy-check=:NoSchedule<br><br># 测试通过后移除污点<br>kubectl taint nodes new-node pre-deploy-check-<br> |
| 3. 节点维护时驱逐 Pod | 添加 NoExecute 污点，触发 Pod 自动漂移，维护完成后移除污点。 | yaml<br># 维护时添加污点<br>kubectl taint nodes node-1 maintenance=:NoExecute<br><br># 维护完成后移除<br>kubectl taint nodes node-1 maintenance-<br> |
| 4. GPU/专用节点仅允许特定 Pod | 为专用节点添加污点（如 gpu=true:NoSchedule），仅允许声明对应容忍的 Pod 调度。 | yaml<br># GPU 节点污点<br>kubectl taint nodes gpu-node gpu=true:NoSchedule<br><br># GPU Pod 的容忍<br>tolerations:<br>- key: "gpu"<br> operator: "Equal"<br> value: "true"<br> effect: "NoSchedule"<br> |
面对这样的需求，Kubernetes 抽象了污点(Taint)和容忍(Toleration)的概念，可以非常方便的实现这些需求。
1:污点和容忍的基本概念
Taint(污点)作用在节点上，能够使节点排斥一类特定的 Pod。
Toleration(容忍)作用在 Pod 上，也就是可以兼容某类污点
比如有一批 GPU 服务器只能部署要使用 GPU的 Pod。每个节点上都可以应用一个或多个 Taint，这表示对于那些不能容忍这些 Taint 的 Pod 是不能部署在该服务器上的。如果 Pod 配置了 Toleration，则表示这些 Pod 可以被调度到设置了 Taint 的节点上，当然没有设置 Taint 的节点也是可以部署的。
Taint(污点)和 Toleration(容忍)可以作用于 node 和 pod 上，其目的是优化 pod 在集群间的调度，这跟节点亲和性类似，只不过它们作用的方式相反，具有 taint 的 node 和 pod 是互斥关系，而具有节点亲和性关系的 node 和 pod 是相吸的。另外还有可以给 node 节点设置 1abel，通过给 pod 设置nodeselector 将 pod 调度到具有匹配标签的节点上。
Taint 和 Toleration 相互配合，可以用来避免 Pod 被分配到不合适的节点上。每个节点上都可以应用一个或多个 taint ，这表示对于那些不能容忍这些 taint 的 Pod，是不会被该节点接受的。如果将 toleration 应用于 Pod 上，则表示这些 Pod 可以(但不一定)被调度到具有匹配 taint 的节点6
2:污点的使用
如果一个节点被标记为有污点,那么意味着不允许 pod 调度到该节点,，除非 pod 也被标记为可以容忍污点节点。
在使用 kubeadm 部署的 k8s 集群的时候应该会发现,通常情况下,应用是不会调度到 master 节点的。因为 kubeadm 部署的 k8s 集群默认给 master 节点加了 Taints(污点)。
给节点 node01增加一个污点，它的键名是 key1，键值是 value1，效果是 NoSchedule。 这表示只有拥有和这个污点相匹配的容忍度的 Pod 才能够被分配到 node1 这个节点。
查看节点是否为污点:
若要移除上述命令所添加的污点，在后面加一个横杠即可，可以执行:
每个污点有一个 key 和 value 作为污点的标签，其中 value 可以为空，effect 描述污点的作用效果，语法为 key=value:effect
当前 taint effect 支持如下三个选项:
| 效果（Effect） | 调度行为 | 对已有 Pod 的影响 | 典型应用场景 | 示例命令 |
|---|---|---|---|---|
NoSchedule | 新 Pod 无法调度到该节点（除非声明容忍）。 | 不驱逐已有 Pod。 | - Master 节点隔离 - 专用节点（如 GPU）保留给特定 Pod | kubectl taint nodes node1 key=value:NoSchedule |
PreferNoSchedule | 新 Pod 尽量避免调度到该节点（无合适节点时仍可能调度）。 | 不驱逐已有 Pod。 | - 灰度发布时临时限制调度 - 低优先级工作负载的柔性隔离 | kubectl taint nodes node1 key=value:PreferNoSchedule |
NoExecute | 新 Pod 无法调度到该节点，且 驱逐 已有 Pod（除非声明容忍）。 | 驱逐无容忍的 Pod（Deployment/StatefulSet 会重建）。 | - 节点维护时强制迁移 Pod - 节点故障时快速恢复业务 | kubectl taint nodes node1 key=value:NoExecute |
备注:
NoExecute 这个 Taint 效果对节点上正在运行的 pod 有以下影响:
(1)没有设置 Toleration 的Pod 会被立刻驱逐
(2)配置了对应 Toleration 的 pod，如果没有为 tolerationseconds 赋值，则会一直留在这一节点中
(3)配置了对应 Toleration 的 pod 且指定了 tolerationseconds 值，则会在指定时间后驱逐
tolerationseconds 用于描述当 Pod 需要被驱逐时可以在 Node 上继续保留运行的时间，即 60秒后该 pod 会被驱逐掉，默认的是一天。
3:容忍的定义
设置了污点的 Node 将根据 taint 的 effect: Noschedule、PreferNoschedule、NoExecute 和 Pod之间产生互斥的关系，Pod 将在一定程度上不会被调度到 Node 上。 但我们可以在 Pod 上设置容忍(Toleration)，意思是设置了容忍的 Pod 将可以容忍污点的存在，可以被调度到存在污点的 Node 上。
4:示例
(1)设置污点
(2)创建测试模板
(3)运行
(4)在两个 Node 上都设置了污点后，此时 Pod 将无法创建成功
(5)修改测试模板
在 pod1.yaml 的基础上增加容忍度参数
备注:
tolerationseconds 用于描述当 Pod 需要被驱逐时可以在 Node 上继续保留运行的时间,即 68 秒后该 pod 会被驱逐掉，默认的是一天。其中的 key、vaule、effect 都要与 Node 上设置的 taint 保持一致。
(6)运行新的 pod
(7)在设置了容忍之后，Pod 创建成功
注意:
完成此实验后，将污点取消
5:容忍的基本用法
(1)容忍污点的条件
operator 的值为 Exists 将会忽略 value 值，即存在即可，为 Equal 时需要指定污点的 value。pod 的 Toleration 声明中的 key 和 effect 需要与 Taint 的设置保持一致,并且满足以下条件之-:
| operator 类型 | 匹配条件 | 是否需要 value | 示例 YAML | 适用场景 |
|---|---|---|---|---|
Exists | 只要节点污点的 key 存在即可匹配（忽略 value）。 | 不需要 | yaml<br>tolerations:<br>- key: "check"<br> operator: "Exists"<br> effect: "NoExecute"<br> | 容忍所有含 check 键的污点（无论值是什么）。 |
Equal | 节点污点的 key 和 value 必须完全匹配。 | 必须指定 | yaml<br>tolerations:<br>- key: "check"<br> operator: "Equal"<br> value: "mycheck"<br> effect: "NoExecute"<br> | 仅容忍 check=mycheck 的污点（精确匹配）。 |
| 未指定 | 默认行为等同于 Equal（需完全匹配 key 和 value）。 | 必须指定 | yaml<br>tolerations:<br>- key: "check"<br> value: "mycheck"<br> effect: "NoExecute"<br> | 简化写法，效果与 Equal 相同。 |
(2)另外还有如下两个特例:
| 特例配置 | 匹配条件 | 等效逻辑 | 示例 YAML | 适用场景 |
|---|---|---|---|---|
空 key + operator: Exists（容忍所有污点） | 匹配任何污点（无论 key、value 或 effect 是什么）。 | kubectl taint nodes <node> <any_key>=<any_value>:<any_effect> 均被容忍。 | yaml<br>tolerations:<br>- operator: "Exists"<br> | 极端场景： - 确保 Pod 一定能调度（如全局守护进程）。 - 慎用：可能破坏隔离性！ |
空 effect + operator: Exists（匹配指定 key 的所有效果） | 匹配指定 key 的任何污点（无论 effect 是 NoSchedule、PreferNoSchedule 或 NoExecute）。 | kubectl taint nodes <node> <key>=<any_value>:<any_effect> 均被容忍。 | yaml<br>tolerations:<br>- key: "check"<br> operator: "Exists"<br> | 容忍特定键的所有污点效果（如临时维护标签 check）。 |
(3)一些特殊的使用场景
| 场景 | 污点类型 | 操作命令 | 效果 | 后续清理 | 注意事项 |
|---|---|---|---|---|---|
| 多 Master 节点资源利用 （允许 Pod 临时调度到 Master） | PreferNoSchedule | kubectl taint node k8s-master node-role.kubernetes.io/master=:PreferNoSchedule | Pod 尽量不调度到 Master，但资源不足时仍可能调度。 | 无需立即清理，长期保留此污点。 | 确保 Master 节点资源充足，避免关键系统组件（如 etcd）受影响。 |
| 节点维护（如系统升级） （强制驱逐 Pod 并禁止调度） | NoExecute | kubectl taint node k8s-node01 check=mycheck:NoExecute | 立即驱逐该节点上无容忍的 Pod，并禁止新 Pod 调度。 | 维护完成后移除污点：kubectl taint node k8s-node01 check=mycheck:NoExecute- | 确保集群剩余节点资源足够承接被驱逐的 Pod。 |
| 资源不足时临时启用 Master （允许 Pod 调度到 Master 缓解资源压力） | PreferNoSchedule | kubectl taint node k8s-master node-role.kubernetes.io/master=:PreferNoSchedule | 允许 Pod 在资源不足时调度到 Master。 | 资源恢复后移除污点：kubectl taint node k8s-master node-role.kubernetes.io/master- | 仅作为临时方案，需监控 Master 节点负载。 |
| 维护完成后恢复节点 （重新允许调度） | 移除污点 | kubectl taint node k8s-node01 check=mycheck- | 节点重新接受调度，新建 Pod 可分配到此节点。 | — | 确认节点状态正常（kubectl get node k8s-node01）后再移除污点。 |
6:多污点与多容忍配置
系统允许在同一个 node 上设置多个 taint，也可以在 pod 上设置多个 Toleration
Kubernetes 调度器处理多个 Taint 和 Toleration 能够匹配的部分，剩下的没有忽略掉的Taint 就是对 Pod 的效果了。下面是几种特殊情况：
| 场景 | 污点剩余效果 | 调度器行为 | Pod 状态影响 | 示例命令 |
|---|---|---|---|---|
剩余污点中存在 NoSchedule | 至少一个 effect: NoSchedule | 禁止调度：Pod 不会被调度到该节点（即使容忍其他污点）。 | 已存在的 Pod 不受影响（若未设置 NoExecute）。 | kubectl taint node k8s-node01 key1=value1:NoSchedule |
剩余污点中仅有 PreferNoSchedule | 无 NoSchedule，有 PreferNoSchedule | 尽量避免调度：当集群资源充足时，不调度到该节点；资源不足时仍可能调度。 | 已存在的 Pod 不受影响。 | kubectl taint node k8s-node01 key2=value2:PreferNoSchedule |
剩余污点中存在 NoExecute | 至少一个 effect: NoExecute | 驱逐 Pod： - 已运行的 Pod 若无容忍会被立即驱逐。 - 新 Pod 不会被调度到该节点。 | 若 Pod 有容忍且未设置 tolerationSeconds，则保留；否则被驱逐。 | kubectl taint node k8s-node01 key3=value3:NoExecute |
| Pod 容忍所有污点 | 无剩余污点 | 允许调度：Pod 可正常调度到该节点。 | 已存在的 Pod 保留。 | yaml<br>tolerations:<br>- key: "key1"<br> operator: "Exists"<br> |
-
添加多个污点：
kubectl taint node k8s-node01 key1=value1:NoSchedule kubectl taint node k8s-node01 key2=value2:NoExecute移除污点：kubectl taint node k8s-node01 key1=value1:NoSchedule- kubectl taint node k8s-node01 key2=value2:NoExecute-
二：警戒(cordon)和 转移(drain)
1:设置警戒
警戒是指将 Node 标记为不可调度的状态
这样就不会让新创建的 Pod 在此 Node 上运行，命令如下
该 node 将会变为 SchedulingDisabled 状态
2:kubectl uncordon 将 Node 标记为可调度的状态s(取消警戒)
3:驱逐(转移)pod
kubectl drain 可以让 Node 节点开始释放所有 pod，并且不接收新的 pod 进程。drain 本意排水，意思是将出问题的 Node 下的 Pod 转移到其它 Node 下运行。
执行 drain 命令，会自动做了两件事情:
设定此 node 为不可调度状态(cordon)
evict(驱逐)了 Pod
备注:
-ignore-daemonsets:无视 Daemonset 管理下的 Pod
-delete-local-data:如果有 mount local volume 的 pod，会强制杀掉该 pod
-force:强制释放不是控制器管理的 Pod，例如 kube-proxy
注意:
实验完成后，将节点设置为可调度
kubectl uncordon k8s-node01
三:K8s亲和性和非亲和性
关于 K8S 对 Pod 的调度，通常情况下 Pod 被分配到哪些 Node 是不需要我们操心的，这个过程会由
scheduler 自动实现。但有时，我们需要让 Pod 按照我们的预想运行在 Node 上(例如某些应用“必须/或者尽量”跑在具有 SSD 存储的节点上，有些彼此相关的 Pod 应用应该跑在同一个节点上)。为此，k8s为我们提供了这样的策略，我们可以通过使用“亲和性/非亲和性”制定一些规则来实现我们的需求。
1:亲和性调度可以分成软策略和硬策略两种方式
| 特性 | 硬策略（必须满足） | 软策略（尽量满足） |
|---|---|---|
| 配置字段 | requiredDuringSchedulingIgnoredDuringExecution | preferredDuringSchedulingIgnoredDuringExecution |
| 调度行为 | 节点必须满足条件，否则 Pod 保持 Pending 状态。 | 节点尽量满足条件，不满足时仍会调度到其他节点。 |
| 优先级 | 高优先级，强制约束。 | 低优先级，柔性建议。 |
| 适用场景 | - 强制运行在特定硬件（如 GPU 节点） - 严格避免与某些 Pod 共存（如高可用）。 | - 优先但不强制选择高配置节点 - 建议但不强制分散 Pod（如优化资源分布）。 |
| YAML 示例 | yaml<br>affinity:<br> nodeAffinity:<br> requiredDuringScheduling...<br> nodeSelectorTerms:<br> - matchExpressions:<br> - key: "disktype"<br> operator: "In"<br> values: ["ssd"]<br> | yaml<br>affinity:<br> nodeAffinity:<br> preferredDuringScheduling...<br> - weight: 100<br> preference:<br> matchExpressions:<br> - key: "env"<br> operator: "In"<br> values: ["prod"]<br> |
| 失败处理 | Pod 持续 Pending，直到条件满足。 | Pod 正常调度，记录调度器跳过原因（通过 kubectl describe pod 查看事件）。 |
| 权重（Weight） | 不适用（必须满足，无权重概念）。 | 支持（如 weight: 100，数值越高优先级越高）。 |
2:亲和性的配置规则
| 类型 | 配置字段 | 作用 | 关键参数 | 示例场景 | YAML 片段示例 |
|---|---|---|---|---|---|
| Node 亲和性 | nodeAffinity | 控制 Pod 应调度到哪些节点（或避免哪些节点）。 | requiredDuringScheduling（硬策略）preferredDuringScheduling（软策略）matchExpressions（标签匹配） | 强制 Pod 运行在 SSD 节点：disktype=ssd | yaml<br>affinity:<br> nodeAffinity:<br> requiredDuringSchedulingIgnoredDuringExecution:<br> nodeSelectorTerms:<br> - matchExpressions:<br> - key: "disktype"<br> operator: "In"<br> values: ["ssd"]<br> |
| Pod 亲和性 | podAffinity | 让 Pod 倾向于与某些 Pod 部署在同一拓扑域（如节点、可用区）。 | labelSelector（匹配 Pod 标签）topologyKey（拓扑域，如 hostname） | 微服务 A 与缓存服务 B 同节点部署，减少延迟。 | yaml<br>affinity:<br> podAffinity:<br> requiredDuringSchedulingIgnoredDuringExecution:<br> - labelSelector:<br> matchExpressions:<br> - key: "app"<br> operator: "In"<br> values: ["cache"]<br> topologyKey: "kubernetes.io/hostname"<br> |
| Pod 反亲和性 | podAntiAffinity | 让 Pod 避免与某些 Pod 部署在同一拓扑域。 | 同 podAffinity，逻辑相反。 | 高可用部署：同一服务的 Pod 分散在不同节点。 | yaml<br>affinity:<br> podAntiAffinity:<br> requiredDuringSchedulingIgnoredDuringExecution:<br> - labelSelector:<br> matchExpressions:<br> - key: "app"<br> operator: "In"<br> values: ["web"]<br> topologyKey: "kubernetes.io/hostname"<br> |
| 共用参数 | operator | 标签匹配逻辑：In、NotIn、Exists、DoesNotExist、Gt、Lt。 | - | - | yaml<br>operator: "NotIn"<br>values: ["test"] |
| 软策略权重 | weight（仅软策略） | 优先级权重（1-100），数值越高优先级越高。 | 仅用于 preferredDuringScheduling。 | 优先但不强制调度到生产环境节点（env=prod）。 | yaml<br>preferredDuringSchedulingIgnoredDuringExecution:<br>- weight: 80<br> preference:<br> matchExpressions:<br> - key: "env"<br> operator: "In"<br> values: ["prod"]<br> |
3:节点硬亲和性
节点的亲和性可以通过 pod.spec.affinity.nodeAffinity 字段定义，nodeAffinity 字段中支持使用 matchExpressions 属性构建更为复杂的标签选择器。
(1)设置节点标签
首先对两个 node 加标签，设置两个 node 标签分别为 node1 和 node2 。加标签的语法如下。kubectl label nodes <node-name><label-key>=<label-value>
备注:
如果需要重命名 node 标签，可以使用如下命令:
[root@k8s-master ~]# kubectl label nodes k8s-node01 type=node1 --overwrite
如果要删除 node 标签(标签名为“type”)，可以使用如下命令:
[root@k8s-master ~]# kubectl label node k8s-node01 type-
(2)查看节点标签
(3)设置 pod 亲和性为 type=node1
备注:
values:["node01"1 node1 为节点的标签，该 pod 要调度到标签为 node1 的节点，即 k8s-node01。
(4)部署 pod 并查看其信息
(5)设置 pod 亲和性为 type=node02
备注:
values: ["node02"] node02 为节点的标签，该 pod 要调度到标签为 node02 的节点，即 k8s-node02.
(6)部署 pod 并查看其信息
4:节点软亲和性
节点软亲和性为节点选择提供了一种柔性的控制器逻辑，当条件不满足时，也能够接受被编排在其他不符合条件的节点之上。同时他还为每种倾向性提供了 weight 属性以便用于自定义优先级,范围是 1-100,越大越优先。
(1)为 pod 设置软亲和性
(2)部署 pod 并查看其信息
可以看到，由于 Pod 对 node01 的亲和性，被部署到了 node1 上。
注意:
node 软亲和中的权重值不影响 pod 的调度，谁在前面，就亲和谁。
pod 软亲和中的权重值是会影响调度到的节点的，pod 软亲和中谁的权重高就调度到谁那里。
5:Pod 硬亲和度
出于某些需求，将一些 Pod 对象组织在相近的位置(同一节点、机架、区域等)，此时这些 pod 对象间的关系为 pod 亲和性。
Pod 的亲和性调度也存在硬亲和性和软亲和性的区别，他们表示的约束意义同节点亲和性相似。
Pod 硬亲和性调度也使用 requiredDuringSchedulingIgnoreDuringExecution 属性进行定义。
首先创建两个基础 Pod，并对它打标签，分别部署到node01 和 node02 上。
(1)部署第一个基础 Pod，名字为 pod04，使其节点硬亲和到 node01
注意:
pod04 的标签是 pod04，所在的节点标签是 node01
(2)部署并查看其信息
(3)部署第二个基础 Pod，名字为 pod05，使其节点硬亲和到 node02
注意:
pod05 的标签是 pod05，所在的节点标签是 node02
(4)部署并查看其信息
可以看到，一个位于 node01，一个位于 node02。
(5)用pod 硬亲和创建一个亲和 pod05 的 pod
注意:
matchExpressions 的 values 值为 pod 的标签。是哪个 pod 的标签，就亲和到哪个 pod 所在的 node 节
点
pod05 的标签是 pod05，所在的节点标签是 node02pod06 亲和了 pod05，于是也被调度到 node02
(6)部署此 pod
此时，pod05 和 pod06 两个 pod 位于同一个 node 节点。
7:Pod 软亲和度
Pod 软亲和调度使用方法与 Node 软亲和调度方法类似。
(1)编辑pod07 的 pod
注释:
values:[“pod05"]是 pod05 的 pod 的标签
values:["pod04"]是 pod04 的 pod 的标签
正则匹配了 pod 的标签“pod05”，带有 pod85 标签的 pod 是 pod05，该 pod 在 node02 上，于是 pod07的 pod 也调度到了 node02 上。
注意:
node 软亲和中的权重值不影响 pod 的调度，谁在前面，就亲和谁。
pod 软亲和中的权重值是会影响调度到的节点的，pod 软亲和中谁的权重高就调度到谁那里。
pod04 的标签是 pod04，所在的节点标签是 node01
pod05 的标签是 pod05，所在的节点标签是 node02
pod07 软亲和了 pod05，所以也在 node02 上
(2)编辑pod08 的 pod
修改 yaml文件中的权重，使其与 pod04 亲和性更高，因为 pod04在 node01 上，pod08 也会被部署到 node01 上。
备注:
匹配了“pod04”标签的亲和度对应的权重值更高，按照此权重，pod08会被调度到标签为“pod04”的 pod 所在的 node 节点，即 node01
8:pod 反亲和
査看 pod09所在的节点,因为设置的反亲和 pod85,所以,pod05在 node02的话,pod09就会在 node01
污点是阻止 Pod 调度的硬性条件,而亲和性是影响调度决策的软性指导。在 Kubernetes 调度过程中,污点的约束始终优先于亲和性的指导。
污点优先级高于亲和性:如果一个节点上有污点，而 Pod 没有相应的容忍度，那么无论亲和性规则如何，Pod 都不能被调度到该节点上。
亲和性不影响污点的约束:即使 Pod 的亲和性规则允许它被调度到某个节点，如果该节点上有污
点而 Pod 没有容忍度，Pod 仍然不能被调度上去。