下面用“节点排斥 / Pod 选择 / Pod 靠近 / Pod 分散”这个角度来理解 Kubernetes 中的 Taints 污点、Tolerations 容忍、Affinity 亲和、Anti-Affinity 反亲和。

一、一句话总览

可以打个比方：

• Taint 污点：节点门口挂牌，“此节点只允许持通行证的人进入”。
• Toleration 容忍：Pod 身上的通行证。
• NodeAffinity 节点亲和：Pod 想住某类小区，比如“必须住 SSD 小区”或“尽量住 SSD 小区”。
• PodAffinity Pod 亲和：Pod 想住得离某些服务近一点，比如“尽量和 Redis 在同一个可用区”。
• PodAntiAffinity Pod 反亲和：Pod 不想和同类住太近，比如“3 个 Redis 副本不要在同一台节点上”。

二、Taints 污点

1. 概念

Taint 是设置在 Node 上的属性。

它的意思是：

这个节点上带有某种“污点”，默认情况下，某些 Pod 不允许调度到该节点。

Taint 写在 Node 的 spec.taints 中：

apiVersion: v1
kind: Node
metadata:
  name: node-1
spec:
  taints:
  - key: "app"
    value: "redis"
    effect: "NoSchedule"

通常我们用 kubectl 操作：

kubectl taint nodes node-1 app=redis:NoSchedule

语法：

key=value:Effect

如果没有 value：

key:Effect

例如：

kubectl taint nodes node-1 gpu:NoSchedule

2. Taint 的 Effect 类型

Taint 有三种 effect：

1）NoSchedule

最常见的类型。

例子：

kubectl taint nodes node-1 redis=true:NoSchedule

效果：

• 普通 Pod 不会调度到 node-1。
• 已经运行在 node-1 上的 Pod 不会被驱逐。
• 只有带有对应 Toleration 的 Pod 才能调度上去。

适合场景：

• 专用节点。
• GPU 节点。
• 高性能存储节点。
• 数据库节点。
• 某些团队专属节点。

2）PreferNoSchedule

软性排斥。

例子：

kubectl taint nodes node-1 large-memory:PreferNoSchedule

效果：

• 调度器会尽量不把普通 Pod 调度到该节点。
• 但如果集群中没有其他可用节点，仍然可以调度上去。

适合场景：

• 希望某些节点优先留给特殊负载，但不想强制独占。
• 资源紧张时允许弹性使用。

3）NoExecute

最强类型。

不仅新 Pod 不能调度，已有 Pod 也会被驱逐，除非它们容忍了这个污点。

常见于节点故障：

node.kubernetes.io/not-ready:NoExecute
node.kubernetes.io/unreachable:NotReady
node.kubernetes.io/disk-pressure:NoExecute
node.kubernetes.io/memory-pressure:NoExecute

例子：

kubectl taint nodes node-1 bad-node:NoExecute

效果：

• 新 Pod 不能调度到 node-1。
• node-1 上已有 Pod 如果没有 Toleration，会被驱逐。

适合场景：

• 节点故障。
• 节点不可达。
• 节点资源压力过大。
• 需要强制清理节点上的业务。

3. Kubernetes 默认常见 Taints

一些系统会自带或自动添加 Taints。

1）节点被 cordon

kubectl cordon node-1

等价于给节点加上：

node.kubernetes.io/unschedulable:NoSchedule

效果：

• 新 Pod 不再调度到该节点。
• 已有 Pod 继续运行。

2）节点 NotReady

节点异常时可能出现：

node.kubernetes.io/not-ready:NoExecute

效果：

• 新 Pod 不调度。
• 已有 Pod 可能被驱逐。

3）节点 Unreachable

node.kubernetes.io/unreachable:NoExecute

4）节点资源压力

例如：

node.kubernetes.io/disk-pressure:NoExecute
node.kubernetes.io/memory-pressure:NoExecute
node.kubernetes.io/pid-pressure:NoExecute

5）控制面节点

现代 Kubernetes 控制面节点通常有类似污点：

node-role.kubernetes.io/control-plane:NoSchedule

旧版本可能是：

node-role.kubernetes.io/master:NoSchedule

目的：

• 防止普通业务 Pod 跑到 Master / Control Plane 节点上。
• 只有系统组件通过 Toleration 才能运行在控制面节点。

三、Tolerations 容忍

1. 概念

Toleration 是写在 Pod 上的属性。

它的意思是：

这个 Pod 可以容忍节点上的某些 Taint，因此可以调度到带这些 Taint 的节点。

Toleration 写在 Pod 的 spec.tolerations 中：

通常我们不会手写 Node 对象，而是在 Deployment、StatefulSet、Pod 模板里写 Toleration：

2. Toleration 字段

字段含义：

3. 匹配规则

生产环境建议显式写清楚：

常见匹配方式：

1）精确匹配

Taint：

app=redis:NoSchedule

Toleration：

含义：

只容忍 app=redis:NoSchedule 这个污点。

2）忽略 value 匹配

Taint：

app=redis:NoSchedule

也可以是：

app=other:NoSchedule

Toleration：

- key: "app"
  operator

含义：

只要 key 是 app，effect 是 NoSchedule，不管 value 是什么，都容忍。

3）容忍某类 effect 的所有污点

Toleration：

- operator: "Exists"
  effect: "NoSchedule"

含义：

容忍所有 effect 为 NoSchedule 的 Taint。

这个比较宽泛，一般用于特殊系统组件，不建议普通业务随意使用。

4）容忍所有污点

Toleration：

- operator: "Exists"

含义：

容忍所有 Taint。

非常危险，一般只用于极少数系统级组件，普通业务不要这样写。

4. 一个节点有多个 Taints 时怎么办？

如果一个节点有多个会影响调度的 Taints，Pod 必须能容忍所有这些 Taints，否则不能调度上去。

例如节点有：

dedicated=redis:NoSchedule
disktype=ssd:NoSchedule

Pod 需要：

否则调度器会认为该 Pod 不能调度到这些节点。

5. TolerationSeconds：针对 NoExecute

tolerationSeconds 主要对 NoExecute 有效。

场景：

节点 NotReady 后，Kubernetes 会给节点加上：

node.kubernetes.io/not-ready:NoExecute

如果 Pod 不想立即被驱逐，可以写：

含义：

节点 NotReady 或 Unreachable 后，这个 Pod 最多还能在节点上运行 300 秒，之后才被驱逐。

适合场景：

• 有状态服务短暂故障容忍。
• 本地盘数据服务，避免节点短暂抖动就迁移。
• 需要给运维留出处理时间。

四、Taint + Toleration 的具体例子

场景 1：Redis 专用节点

你希望 Redis 只运行在指定节点上，其他普通 Pod 不要跑到这些节点。

1）给节点打标签

2）给节点加污点

kubectl taint nodes node-1 node-2 redis-dedicated=true:NoSchedule

3）普通 Pod

普通 Pod 没有 Toleration，所以不能调度到 node-1、node-2。

4）Redis Pod

解释：

• tolerations：允许这个 Pod 调度到带 redis-dedicated=true:NoSchedule 的节点。
• nodeAffinity：要求这个 Pod 必须调度到 redis=true 且 disktype=ssd 的节点。
• 其他普通 Pod 因为没有容忍 污点，所以不会调度到这些节点。

这就是典型组合：

Taint 负责“排除别人”，NodeAffinity 负责“选择自己该去的节点”。

场景 2：GPU 专用节点

GPU 节点比较贵，通常不希望普通 Pod 占用。

1）节点准备

2）GPU Pod

效果：

• 普通 Pod 不能跑到 gpu-node-1。
• GPU 推理 Pod 可以调度到 gpu-node-1。
• 同时要求节点确实有 GPU。

场景 3：节点故障延迟驱逐

某个关键 Pod 希望节点短暂 NotReady 时不要立即迁移。

含义：

• 节点 NotReady / Unreachable 后，最多再等 300 秒。
• 如果节点恢复，Pod 可以继续运行。
• 如果 300 秒后还没恢复，Pod 会被驱逐。

五、Affinity 亲和

Affinity 分为两大类：

1. NodeAffinity 节点亲和
2. PodAffinity Pod 亲和

它们都支持：

• required：硬性要求，必须满足，否则不调度。
• preferred：软性偏好，尽量满足，但满足不了也可以调度。

字段名字虽然很长，但含义很固定：

requiredDuringSchedulingIgnoredDuringExecution
preferredDuringSchedulingIgnoredDuringExecution

可以拆解理解：

六、NodeAffinity 节点亲和

1. 概念

NodeAffinity 是根据 节点标签 来选择节点。

你可以把它理解成高级版 nodeSelector。

nodeSelector 只支持简单精确匹配：

nodeSelector:
  disktype: ssd

而 NodeAffinity 支持：

• In
• NotIn
• Exists
• DoesNotExist
• Gt

2. 硬性 NodeAffinity

含义：

Pod 必须调度到满足条件的节点，否则 Pending。

例子：

要求 Pod 必须调度到 disktype=ssd 的节点。

含义：

• 只能调度到 disktype=ssd 的节点。
• 如果没有这样的节点，Pod 会 Pending。

3. 多个节点条件

同一个 nodeSelectorTerms 下的多个 matchExpressions 是 AND 关系。

例子：

要求：

• os=linux
• disktype=ssd
• zone=us-east-1a

含义：

必须同时满足这三个条件。

4. 多个 nodeSelectorTerms 是 OR 关系

nodeSelectorTerms 数组里多个 term 是 OR 关系。

例子：

满足下面任一条件即可：

• disktype=ssd
• disktype=nvme

含义：

SSD 节点可以，NVMe 节点也可以。

5. 软性 NodeAffinity

含义：

调度器会尽量满足，但如果没有满足条件的节点，也可以调度到其他节点。

例子：

希望优先调度到 SSD 节点，但如果没有 SSD 节点，也可以调度到 HDD 节点。

含义：

• 优先选择 disktype=ssd 的节点，权重 100。
• 其次优先选择 us-east-1a 可用区，权重 50。
• 如果都不满足，也可以调度到其他节点。

weight 范围是 1 到 100，越大优先级越高。

七、PodAffinity Pod 亲和

1. 概念

PodAffinity 是根据 已经调度出去的 Pod 的标签 来决定新 Pod 调度到哪里。

它经常和 topologyKey 一起使用。

意思是：

如果某个拓扑域内已经有我喜欢的 Pod，那么我也尽量去那个拓扑域。

拓扑域可以理解为：

• 同一台节点
• 同一个机架
• 同一个可用区
• 同一个 Region
• 同一个机房
• 自定义拓扑，例如 rack、datacenter

2. topologyKey 是什么？

topologyKey 是一个节点标签 key。

常见值：

例如：

topologyKey: kubernetes.io/hostname

表示：

以节点 hostname 作为拓扑边界。

如果两个节点 hostname 相同，它们属于同一个拓扑域。实际上一台节点通常 hostname 唯一，所以这通常等价于“同一台节点”。

例如：

topologyKey: topology.kubernetes.io/zone

表示：

以可用区作为拓扑边界。

同一个可用区内的不同节点属于同一个拓扑域。

3. 硬性 PodAffinity

例子：

你有一个 cache 服务，现在要部署 api 服务。

你希望 api 必须和某个 cache Pod 在同一个可用区，以减少网络延迟。

含义：

• 调度器会查找已经有 app=cache Pod 的可用区。
• api 必须调度到这些可用区中的某一个。
• 如果所有 cache Pod 所在可用区都不可调度，api 会 Pending。

4. 软性 PodAffinity

例子：

希望 api 尽量和 cache 在同一个可用区，但如果不行也可以调度到其他可用区。

含义：

• 调度器会优先把 api 调度到已经有 cache 的可用区。
• 如果没有合适可用区，也可以调度到别的地方。

5. PodAffinity 应用场景

1）业务和缓存同可用区

例如：

• order-service
• redis-cache

如果跨可用区访问，延迟可能更高。

可以写：

效果：

order-service 尽量和 Redis 在同一个可用区。

2）大数据任务靠近存储节点

例如：

• Spark executor 希望靠近 HDFS 数据节点。
• 批处理任务希望靠近数据所在机架，减少跨机架 IO。

3）同机房低延迟通信

例如：

• 交易系统希望订单服务和支付服务在同一个机房。
• 游戏服务端希望和匹配服务在同一个低延迟区域。

八、PodAntiAffinity Pod 反亲和

1. 概念

PodAntiAffinity 是 PodAffinity 的反面。

PodAffinity：

我想和某些 Pod 靠近。

PodAntiAffinity：

我不想和某些 Pod 太靠近。

通常用于：

• 多副本分散部署。
• 高可用。
• 避免单点故障。
• 避免同一节点/同一可用区故障导致所有副本不可用。

2. 硬性 PodAntiAffinity

例子：

你部署 3 个 Redis 副本，希望它们不要在同一台节点上。

含义：

• app=redis 的 Pod 不能调度到已经有 app=redis Pod 的节点。
• 因为 topologyKey: kubernetes.io/hostname 表示以节点 hostname 为边界。
• 所以 3 个 Redis 副本必须分布在 3 台不同节点。

如果集群只有 2 台可用节点，那么第 3 个 Redis Pod 会 Pending。

3. 软性 PodAntiAffinity

如果你希望“尽量分散，但不要强制”，可以使用 preferred。

含义：

• 调度器会尽量把 Redis 副本放到不同节点。
• 但如果节点不够，也不会导致 Pod 永远 Pending。

生产环境更推荐这种软性反亲和，除非你明确要保证强分散。

4. 按可用区反亲和

你希望 Redis 副本不要都落在同一个可用区。

含义：

尽量让 Redis 副本分散到不同可用区。

如果集群只有 2 个可用区，但你有 3 个副本，那么至少有一个可用区会有 2 个副本。

5. 组合使用：节点分散 + 可用区分散

更稳的做法：

• 尽量不同节点。
• 也尽量不同可用区。

含义：

• 最优先：不同节点。
• 次优先：不同可用区。

如果资源充足，效果是：

每个 Redis 副本都尽量在不同节点、不同可用区。

九、一个综合例子

场景

你有两台节点：

node-1
node-2

希望：

1. Redis 只能运行在这两台节点。
2. 其他普通 Pod 不能占用这两台节点。
3. 两台节点都是 SSD。
4. Redis 两个副本要分散到不同节点。

1）给节点打标签

2）给节点加污点

kubectl taint nodes node-1 node-2 redis-dedicated=true:NoSchedule

3）部署 Redis

4）解释

Toleration

让 Redis Pod 可以调度到带有 redis-dedicated=true:NoSchedule 的节点。

其他普通 Pod 如果没有这个 Toleration，就不能调度到 node-1、node-2。

NodeAffinity

让 Redis Pod 只调度到：

redis=true
disktype=ssd

的节点。

PodAntiAffinity

让两个 Redis 副本不能在同一台节点。

因为 replicas: 2，所以最终会分别调度到 node-1 和 node-2。

十、Taint/Toleration 和 Affinity 的区别

1. Taint 是“排斥”，Affinity 是“选择”

Taint：

这个节点不希望某些 Pod 来。

Affinity：

这个 Pod 希望去某些地方，或者靠近某些 Pod。

例如：

• 你只想让某个 Pod 选择 SSD 节点，不需要排斥别人。
  • 用 nodeSelector 或 NodeAffinity。
• 你想让某类节点只给 Redis 用，别人不要来。
  • 用 Taint + Redis Pod 的 Toleration。
• 你想让 Redis 必须去 SSD 节点。
  • 用 。

2. 不要把 Taint 当成 NodeSelector 用

错误示范：

kubectl taint nodes node-1 disktype=ssd:NoSchedule

然后希望某些 Pod 调度到 SSD 节点。

这不对。

Taint 的含义是：

排斥没有 Toleration 的 Pod。

不是：

选择某个标签的节点。

正确做法：

kubectl label nodes node-1 disktype=ssd

Pod 里用：

或者简单场景：

nodeSelector:
  disktype: ssd

如果还要独占节点，再加 Taint：

kubectl taint nodes node-1 ssd-dedicated=true:NoSchedule

3. Taint 是节点视角，Affinity 是 Pod 视角

Taint：

节点说：我不欢迎某类 Pod。

Toleration：

Pod 说：我容忍你这个污点。

NodeAffinity：

Pod 说：我想去有某个标签的节点。

PodAffinity：

Pod 说：我想去某个 Pod 所在的拓扑域。

PodAntiAffinity：

Pod 说：我不想去某个 Pod 所在的拓扑域。

十一、硬性约束和软性约束

1. 硬性约束

例如：

requiredDuringSchedulingIgnoredDuringExecution

或 Taint 的：

NoSchedule
NoExecute

特点：

• 必须满足。
• 不满足则 Pod Pending，或者已有 Pod 被驱逐。

适合：

• 安全隔离。
• 强依赖硬件。
• 强高可用要求。
• 专用节点。

风险：

• 如果集群资源不满足，Pod 无法调度。

2. 软性约束

例如：

preferredDuringSchedulingIgnoredDuringExecution

或 Taint 的：

PreferNoSchedule

特点：

• 尽量满足。
• 不满足也可以调度。

适合：

• 性能优化。
• 网络延迟优化。
• 尽量分散但不强制。

风险：

• 效果不是绝对保证。

十二、调度器大致判断过程

调度器选择节点时，大致会经历：

1. 过滤可行节点

会考虑：

• Pod 资源请求是否满足。
• nodeSelector 是否匹配。
• Taints 是否被 Toleration 容忍。
• NodeAffinity required 是否满足。
• PodAffinity required 是否满足。
• PodAntiAffinity required 是否满足。
• 端口冲突。
• PVC 拓扑约束。
• 其他调度约束。

2. 对可行节点打分

会考虑：

• NodeAffinity preferred。
• PodAffinity preferred。
• PodAntiAffinity preferred。
• PreferNoSchedule Taint。
• 资源均衡。
• 镜像本地性。
• 其他打分插件。

3. 选择得分最高的节点

如果没有任何可行节点，Pod 会进入：

Pending

kubectl describe pod 通常会看到类似事件：

0/3 nodes are available: 1 node(s) had taint {app=redis:NoSchedule}, that the pod didn't tolerate.

或者：

0/3 nodes are available: 3 node(s) didn't match Pod's node affinity.

或者：

0/3 nodes are available: 1 node(s) had one pod that anti-affinity doesn't allow.

十三、常见应用场景总结

场景 1：GPU 节点独占

目标：

• GPU 节点只给 AI 推理任务使用。
• 普通业务不要占用 GPU 节点。

方案：

Pod：

场景 2：数据库专用节点

目标：

• 数据库只运行在指定节点。
• 普通 Pod 不抢占数据库节点。

方案：

Pod：

场景 3：有状态服务副本高可用

目标：

• 3 个 Redis 副本不要在同一节点。
• 最好也不要都在同一个可用区。

方案：

场景 4：业务和缓存同可用区

目标：

• 订单服务访问 Redis 尽量低延迟。
• 希望订单服务和 Redis 在同一个可用区。

订单服务 Pod：

效果：

订单服务尽量调度到已有 Redis 的可用区。

场景 5：节点维护

目标：

• 临时不让新 Pod 调度到某个节点。
• 已有 Pod 继续运行。

方案：

kubectl cordon node-1

等价于加：

node.kubernetes.io/unschedulable:NoSchedule

维护完成后：

kubectl uncordon node-1

如果还要驱逐已有 Pod：

kubectl drain node-1 --ignore-daemonsets --delete-emptydir-data

场景 6：节点故障延迟迁移

目标：

• 节点短暂异常时，关键 Pod 不要马上被驱逐。

Pod：

十四、常见坑

1. 用 Taint 来选择节点

错误：

kubectl taint nodes node-1 disktype=ssd:NoSchedule

然后期望某个 Pod 调度到 SSD 节点。

正确：

选择节点用：

nodeSelector

或：

nodeAffinity

Taint 用于排斥，不用于选择。

2. Taint 加了，但 Pod 没加 Toleration

现象：

Pod Pending。

事件：

0/3 nodes are available: 1 node(s) had taint {app=redis:NoSchedule}, that the pod didn't tolerate.

原因：

节点有：

app=redis:NoSchedule

但 Pod 没有对应：

3. 硬反亲和导致无法调度

例如：

如果只有 1 个可用节点，但有 3 个 Redis 副本，那么后续副本会 Pending。

解决：

• 增加节点。
• 改成 preferredDuringSchedulingIgnoredDuringExecution。
• 降低拓扑要求，例如从节点级改成可用区级。

4. topologyKey 标签不存在

例如你写了：

topologyKey: topology.kubernetes.io/zone

但节点没有这个标签。

可能导致：

• 软性亲和无效。
• 硬性亲和/反亲和导致无法调度。

检查：

kubectl get nodes --show-labels

5. 一个节点多个 Taints 只容忍了一个

节点有：

dedicated=redis:NoSchedule
disktype=ssd:NoSchedule

Pod 只容忍：

可能仍然不能调度，因为还有 disktype=ssd:NoSchedule 没被容忍。

需要把所有影响调度的 Taint 都容忍掉。

6. 把 Toleration 写太宽

例如：

tolerations:
- operator: "Exists"

这会容忍所有 Taint。

风险：

• Pod 可能跑到故障节点、专用节点、GPU 节点、控制面节点等不该去的地方。

普通业务建议精确匹配：

十五、选择建议

1. 只想让 Pod 选某类节点

用：

nodeSelector

或：

nodeAffinity

例如：

nodeSelector:
  disktype: ssd

复杂一点用 NodeAffinity。

2. 想独占节点

用：

Taint + Toleration

例如：

kubectl taint nodes node-1 redis-dedicated=true:NoSchedule

Pod：

3. 想让 Pod 靠近某些服务

用：

podAffinity

例如：

4. 想让副本分散

用：

podAntiAffinity

例如：

5. 节点故障处理

用：

NoExecute

配合：

tolerationSeconds

十六、一张图理解

调度判断：

1. 这个节点有没有 redis-dedicated=true:NoSchedule？
   • 有。
2. Pod 有没有容忍这个 Taint？
   • 有。
3. 节点是否满足 NodeAffinity required？
   • disktype=ssd 满足。
4. 是否满足 PodAntiAffinity？
   • 如果该节点已有 app=redis Pod，则不满足软性反亲和，会降低分数。
5. 如果可行节点有多个，选择打分最高的节点。

十七、最终记忆口诀

可以这样记：

Taint 是节点说“不欢迎”。
Toleration 是 Pod 说“我无所谓，我可以上去”。
NodeAffinity 是 Pod 说“我想去某类节点”。
PodAffinity 是 Pod 说“我想和某个 Pod 住同一个拓扑域”。
PodAntiAffinity 是 Pod 说“我不想和某个 Pod 住同一个拓扑域”。

再简化：

污点：排斥。
容忍：豁免。
节点亲和：选节点。
Pod 亲和：靠近 Pod。
Pod 反亲和：远离 Pod。

生产中最常见组合：

专用节点：Taint + Toleration + NodeAffinity
高可用副本：PodAntiAffinity
低延迟服务：PodAffinity
节点故障：NoExecute + tolerationSeconds