4. Taints 与 Tolerations：污点与容忍机制
在 Kubernetes 集群中，Taints（污点） 与 Tolerations（容忍） 是一对协同工作的调度控制机制。它们允许节点主动“排斥”某些 Pod，只有显式声明了对应容忍的 Pod 才能被调度到该节点上。这一机制是节点隔离、专用节点池、故障域隔离和资源预留的核心手段。
4.1 核心概念与工作原理
- Taint（污点）：附加在节点上的键值对属性，包含一个
Effect（效果）。节点一旦被打上污点，默认所有 Pod 都无法调度到该节点，除非 Pod 声明了匹配的 Toleration。 - Toleration（容忍）：附加在 Pod 上的声明，表示该 Pod 能够“容忍”节点上的某个污点。容忍不保证调度到该节点，只是允许调度。
- Effect（效果）：定义污点的实际行为，共有三种：
NoSchedule、PreferNoSchedule、NoExecute。
关键原则： 节点标记污点 → 排斥所有无容忍 Pod → 有匹配容忍的 Pod 可被调度 → 容忍不保证调度，仅解除排斥。
4.2 三种 Effect 对比
| Effect | 行为描述 | 调度影响 | 对已有 Pod 的影响 |
|---|---|---|---|
NoSchedule |
拒绝新 Pod 调度到该节点 | 硬限制，不调度 | 不影响已在运行的 Pod |
PreferNoSchedule |
尽量不调度，但不强制 | 软限制，调度器尽量避免 | 不影响已在运行的 Pod |
NoExecute |
拒绝新 Pod，并驱逐已有无容忍 Pod | 硬限制，立即驱逐 | 立即驱逐不匹配的已有 Pod |
生产建议： 使用
NoExecute 时要格外谨慎，因为它会立即驱逐节点上所有不匹配的 Pod，可能导致服务中断。通常先使用 NoSchedule 验证，再升级为 NoExecute。
4.3 节点排斥策略与应用场景
污点与容忍机制在以下场景中发挥关键作用：
- 专用节点池：为 GPU、FPGA 或高内存节点打上污点，只允许特定工作负载调度。
- 故障域隔离：将故障节点或维护中节点标记污点，阻止新 Pod 调度。
- 节点预留：为系统组件（如 kube-system）预留节点，打污点并设置容忍。
- 混合工作负载隔离：将生产与测试工作负载物理隔离到不同节点组。
4.3.1 节点排斥策略清单
| 策略名称 | 污点示例 | 适用场景 |
|---|---|---|
| 专用硬件隔离 | gpu=true:NoSchedule |
GPU 节点只运行 AI 训练 Pod |
| 节点维护 | maintenance=true:NoExecute |
节点下线前驱逐所有非关键 Pod |
| 系统组件预留 | node-role.kubernetes.io/master:NoSchedule |
Master 节点只运行系统 Pod |
| 故障节点隔离 | node.kubernetes.io/unreachable:NoExecute |
节点失联后自动驱逐 Pod |
4.4 污点与容忍的配置语法
4.4.1 为节点添加污点
# 添加污点：键=值:Effect
kubectl taint nodes node1 dedicated=gpu:NoSchedule
# 查看节点污点
kubectl describe node node1 | grep Taints
# 删除污点
kubectl taint nodes node1 dedicated=gpu:NoSchedule-
4.4.2 Pod 声明容忍
apiVersion: v1
kind: Pod
metadata:
name: gpu-pod
spec:
tolerations:
- key: "dedicated"
operator: "Equal"
value: "gpu"
effect: "NoSchedule"
containers:
- name: gpu-container
image: nvidia/cuda:11.0
注意：
operator 支持 Equal 和 Exists 两种。使用 Exists 时不需要指定 value，表示容忍所有包含该 key 的污点。过度使用 Exists 可能削弱隔离效果。
4.5 污点与容忍的调度流程
下图展示了调度器在处理污点与容忍时的完整决策路径：
4.6 高级应用：Taint 与 Toleration 在 GitOps 同步窗口中的安全实践
在 GitOps 工作流中，同步窗口期间可能需要对特定节点进行临时隔离，防止非关键工作负载干扰同步操作。污点与容忍机制可以在此场景中实现精细化的安全控制：
- 同步窗口节点标记：在同步窗口开启前，为参与同步的节点添加临时污点
sync-window=true:NoSchedule。 - 同步组件容忍：GitOps 同步组件（如 ArgoCD 的 Application Controller）声明对应容忍，确保只有同步组件可以调度到这些节点。
- 窗口关闭清理：同步窗口结束后，自动移除临时污点，恢复节点正常调度。
安全收益： 通过污点隔离，同步窗口期间其他工作负载不会意外调度到敏感节点，降低了配置冲突和资源争抢的风险。结合 RBAC 控制污点的添加/删除权限，可防止未授权的节点隔离操作。
4.7 常见问题与避坑指南
| 问题 | 原因 | 解决方案 |
|---|---|---|
| Pod 一直 Pending | 节点污点未匹配容忍 | 检查节点污点列表，为 Pod 添加对应容忍 |
| Pod 被意外驱逐 | 节点添加了 NoExecute 污点 | 为关键 Pod 添加 tolerationSeconds 延迟驱逐 |
| 容忍过度宽松 | 使用 Exists 操作符且未指定 effect |
尽量使用 Equal 操作符并明确指定 value 和 effect |
| 污点未生效 | 节点污点被后续操作覆盖 | 使用 kubectl taint 验证，避免自动化脚本冲突 |
4.8 最佳实践总结
- 最小权限原则：只给必要的 Pod 添加容忍，避免全局容忍。
- 分层隔离：结合节点亲和性（NodeAffinity）与污点容忍，实现更精细的调度控制。
- 监控与告警：对 Pending 状态的 Pod 设置告警，及时发现调度异常。
- 自动化管理：使用 Operator 或自动化脚本管理临时污点的添加与移除，减少人工操作。
- 文档化：在集群说明文档中记录所有自定义污点的含义与使用场景，方便团队协作。