Kubernetes污点与容忍：从调度原理解析到企业级实战排错

搞 Kubernetes 时间长了你会发现大多数 Pod 卡在 Pending 的原因根本不是资源不够而是节点上挂了“牌子”上面写着不要来来了也白来。这块牌子就是污点Taint而绕开牌子的通行证就是容忍Toleration。这两个东西几乎是每个 K8s 运维都必须吃透的调度机制。我见过不少团队集群一出调度问题第一反应就是去看资源水位查完发现 CPU 内存都空得很最后折腾半天才发现是某个节点被打了NoSchedule污点业务 Pod 又没配容忍结果全部堆在别的节点上负载不均得一塌糊涂。这篇就把污点和容忍从概念到实操、从单节点配置到企业级场景完整过一遍适合刚接触调度机制的初学者也适合那些已经写了几年 yaml 但一直没仔细研究过污点匹配逻辑的资深玩家。1. 污点和容忍到底解决什么问题1.1 一个真实的生产故障先讲个我实际踩过的坑。有次线上集群要上线一批新业务 Pod负责的同事把 Deployment 提交上去之后Pods 一直处于 Pending。kubectl get events里反复刷着0/8 nodes are available: 1 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }, 3 node(s) had untolerated taint {dedicatedgpu: NoSchedule}.大概扫一眼就能猜到问题出在污点上了。查下来发现这批节点是给 AI 训练任务单独准备的 GPU 节点当初为了确保普通业务不会把 GPU 节点占满就给这些节点打了dedicatedgpu:NoSchedule的污点。而新上线的同事不知道这个约定Pod 模板里没写对应的容忍调度器直接把这些新 Pod 全部拦在门外。整个排查过程不到两分钟但暴露的问题很典型很多团队把污点和容忍当成“写一次就不用管”的配置实际上它需要跟业务发布流程严格绑定。1.2 污点和容忍的定位与 nodeSelector 的对比很多刚接触的人会问Kubernetes 不是已经有nodeSelector和节点亲和性nodeAffinity了吗为什么还要折腾污点和容忍核心区别在于亲和性是一种“要求”表达的是“我希望调度到某个节点”而污点是一种“拒绝”表达的是“这个节点不欢迎某些 Pod”。用生活场景来类比亲和性就是你在选餐厅时优先挑有靠窗座位的污点则是餐厅门口挂一块“衣冠不整者勿入”的牌子你没有达到要求连门都进不去。这个“拒绝”的语义非常有用它天然支持了节点维度的资源隔离和故障保护。比如内存压力期间节点自己给自己打上memory-pressure污点不会等管理员手动介入就知道拒绝新的非关键 Pod 再调度上来。这是亲和性做不到的。所以当你在设计集群调度策略的时候不要把污点和亲和性看作互斥方案正确姿势是配合着用用污点划清边界用亲和控制位置用拓扑分布约束控制打散范围。这个思路后面第五节的企业实战里会展开讲。2. 污点操作全解析2.1 几个核心概念先理清在动手之前一定要把污点的结构拆开看。一个污点由三部分组成key污点的键比如dedicated、gpu。value污点的值比如nvidia、true可省略。effect污点的效应是NoSchedule、PreferNoSchedule还是NoExecute。这三个效应之间的区别是整个调度体系里最关键的理解点NoSchedule不调度到该节点。如果节点已经有这个污点新的 Pod 不上去但已经在节点上跑的 Pod 不受影响。PreferNoSchedule尽量不调度到该节点。相当于一个“软限制”调度器会尽可能避开但资源紧张时也可能放上去。NoExecute最狠的一种。不仅新 Pod 不上去已经在节点上跑的、没有对应容忍的 Pod还会被立即驱逐。NoExecute 本身就带了一个“容忍宽限期”的逻辑配合tolerationSeconds用能实现“给 Pod 一点时间优雅退出”的效果。这个我们后面在 3.3 小节详细说。2.2 添加、查看与去除污点污点的增删查全部通过kubectl taint一行命令完成这是所有操作里最常用的。比如给节点node01打一个dedicatedgpu:NoSchedule的污点kubectl taint nodes node01 dedicatedgpu:NoSchedule查看节点上的污点信息kubectl describe node node01 | grep -A 5 Taints或者用 JSONPath 直接过滤出来方便脚本处理kubectl get nodes -o jsonpath{.items[*].spec.taints} | jq想去掉污点使用-后缀kubectl taint nodes node01 dedicatedgpu:NoSchedule-这个-很容易漏掉我见过不只一次有人在生产环境想去污点结果命令敲错又给节点加了一遍污点。所以建议养成习惯操作完立刻 describe 确认一下。另外提一句给控制面节点加污点和去污点在比较新的 K8s 版本里默认是control-plane这个 key 存在所以单节点集群跑业务 Pod 时你会看到 Pod 一直 Pending因为 control-plane 节点默认带node-role.kubernetes.io/control-plane:NoSchedule污点。要么给 Pod 加容忍要么去掉这个污点二选一。2.3 系统内置污点节点故障时的自动保护除了管理员手动打的污点Kubernetes 自身会根据节点状态自动打上一些内置污点。这些污点很少被认真梳理过但它们决定了集群遇到故障时的自愈表现。节选几个重要的内置污点 key触发条件effect作用node.kubernetes.io/not-ready节点未就绪NoExecute节点 NotReady 后驱逐 Podnode.kubernetes.io/unreachable节点不可达NoExecute节点网络失联后驱逐 Podnode.kubernetes.io/memory-pressure内存压力NoSchedule内存紧张时阻止新 Podnode.kubernetes.io/disk-pressure磁盘压力NoSchedule磁盘紧张时阻止新 Podnode.kubernetes.io/network-unavailable网络不可用NoSchedule网络插件异常时阻止新 Podnode.kubernetes.io/pid-pressurePID 耗尽NoSchedulePID 耗尽时阻止新 Pod特别提一下not-ready和unreachable这两个它们的 effect 是NoExecute意味着节点故障之后没有加容忍的 Pod 会被自动驱逐这个机制配着 Deployment 的副本调度能实现故障转移。但如果你担心误判导致大面积驱逐可以在 Pod 模板里加宽限期容忍。系统默认会给 Pod 注入unreachable和not-ready各 300 秒的容忍这样节点抖动时 Pod 不会立刻被驱逐能扛一阵子。这个细节很多优化过调度的人都不会留意但实际对稳定性影响非常大。3. 容忍配置详解3.1 容忍字段全解析容忍写在 Pod 模板的spec.tolerations下面核心字段如下tolerations: - key: dedicated operator: Equal value: gpu effect: NoSchedule每个字段的含义key要匹配的污点键。operator匹配方式Equal或者Exists。value当 operator 为 Equal 时必须跟污点的 value 一致。effect要匹配的污点效应可选NoSchedule、PreferNoSchedule、NoExecute。tolerationSeconds仅当 effect 为 NoExecute 时有效表示容忍的时间上限。如果只写 key 和 effect那个容忍就是匹配该 key 下所有 value 的污点。如果只写 operator 为 Exists 而不写 key那就表示容忍所有污点属于比较粗暴的写法不推荐在正常业务里乱用。3.2 两种匹配方式Exists 与 Equal很多人在写容忍时搞不清Exists和Equal到底什么区别。简单说Equal要求 key、value、effect 三者完全匹配语义严格。Exists只要 key 存在就算匹配不看 value如果 key 也省略那就匹配所有污点。给个直观例子。假设节点污点是dedicatedgpu:NoSchedule用 Equal 写tolerations: - key: dedicated operator: Equal value: gpu effect: NoSchedule这个能匹配上。用 Exists 写tolerations: - key: dedicated operator: Exists effect: NoSchedule也能匹配上因为 Exists 不看 value。但如果你想匹配所有带dedicated键的污点不管它是NoSchedule还是NoExecute就得分开写两个 effect 的容忍或者干脆省略 effecttolerations: - key: dedicated operator: Exists省略 effect 后这个容忍会匹配任何 effect 的污点。这种写法在实际中比较省心因为你在写配置的时候往往不确定未来节点上的污点会用什么 effect用这种“宽匹配”能少改几轮 yaml。3.3 tolerationSeconds给临时故障一点时间tolerationSeconds是 NoExecute 容忍里最实用的字段它的语义是即使 Pod 已经在节点上运行当节点被打了 NoExecute 污点之后Pod 也不会立即被驱逐而是继续运行指定的秒数再被清理。举个例子。节点由于网络波动失联K8s 会给它打上node.kubernetes.io/unreachable:NoExecute污点。如果没有配置容忍宽限Pod 会立刻被标记为删除并重新调度如果配置了tolerationSeconds: 60Pod 会坚持 60 秒期间节点恢复的话污点被自动移除Pod 原地复活完全感知不到异常。这个机制对无状态服务和高可用设计都有价值。像我们线上给核心服务统一加了一段tolerations: - key: node.kubernetes.io/not-ready operator: Exists effect: NoExecute tolerationSeconds: 300 - key: node.kubernetes.io/unreachable operator: Exists effect: NoExecute tolerationSeconds: 300等于给 Pod 5 分钟的容错窗口节点抖动时不会被调度系统“误杀”。这个窗口不能设太小否则起不到保护作用也不能设太大不然节点真挂了故障转移会拖很久。300 秒是我们测试下来比较均衡的值你可以根据业务启动耗时、健康检查周期来调。4. 企业级实战场景4.1 场景一专用 GPU/高性能节点隔离这个场景最经典也是大多数团队第一次接触污点的入口。公司买了一台带 GPU 的高性能服务器你不能让所有业务 Pod 都往上堆——普通业务上去之后显存被占满AI 训练任务反而进不去。标准方案是给 GPU 节点打污点再让 AI 任务声明确切的调度意图。第一步给 GPU 节点染色kubectl taint nodes gpu-node-01 dedicatedgpu:NoSchedule第二步AI 训练任务的 Pod 模板里加容忍tolerations: - key: dedicated operator: Equal value: gpu effect: NoSchedule第三步再加节点亲和性确保 Pod 只会调度到 GPU 节点affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: nvidia.com/gpu operator: Exists这样组合下来普通业务 Pod 因为不具备 GPU 节点亲和性天然不会往那台机器上调度同时因为 GPU 节点有污点就算调度器“误判”想把普通 Pod 放上去也会被污点拦截。这就是前面说的“污点划边界、亲和性定位置”的完整落地。顺带提一句如果你的环境用了 device plugin 来管理 GPU 设备污点配合nvidia.com/gpu资源声明是标准搭档。设备插件本身负责把 GPU 资源上报给 kubelet而污点保证只有真正声明了 GPU 资源的 Pod 才有资格被调度到这台机器上。两者缺一GPU 资源管理都会乱套。4.2 场景二节点维护与排空节点要换内核、换硬件、升级 kubelet你就得先把业务 Pod 从节点上挪走。这一步最怕的是刚排空完又有新 Pod 被调度上去导致业务频繁被驱逐。标准操作顺序是给节点打NoSchedule污点阻止新 Pod 上来kubectl taint nodes node02 maintenancetrue:NoSchedule执行kubectl drain node02 --ignore-daemonsets --delete-emptydir-data把存量 Pod 迁走。维护完成后去掉污点kubectl taint nodes node02 maintenancetrue:NoSchedule-再执行kubectl uncordon node02让节点重新恢复调度。这里有个细节如果你只是想暂停调度而不驱逐存量 Pod只用第一步就够了。有些团队直接把 node 设置 cordon 状态也能实现类似效果但 cordon 只能拦调度不能保留污点信息到集群 API 里管理起来不够直白。用污点排空的方式维护原因、维护时间段都写进了污点的 key/value 里后续回溯非常方便。4.3 场景三故障节点自动隔离企业集群里节点故障是常态内存泄露、磁盘写满、内核死锁各种情况都有。K8s 虽然内置了not-ready和unreachable的污点自动运维机制但默认配置下有时候驱逐不及时也会拖垮业务。针对这个问题我的建议是结合 PodDisruptionBudgetPDB来用。PDB 限制的是自愿驱逐而 NoExecute 污点引发的驱逐属于节点故障触发PDB 不干预。但配合优雅终止宽限期和合适的tolerationSeconds可以显著降低故障对业务的影响面。比如给无状态业务设置的容忍是 30 秒加上 terminationGracePeriodSeconds 设为 30 秒那么节点故障后 Pod 有 30 秒时间完成优雅退出如果节点能在这段时间内恢复Pod 甚至可以不用重新创建直接留在原地继续跑对调用方完全是透明的。5. 常见问题与排查技巧5.1 Pod 一直 Pending怎么判断是不是污点问题这是所有调度问题里最高频的一个。看到 Pod Pending第一件事不是去看资源而是看事件。kubectl describe pod pod-name | tail -20如果事件里出现untainted或者untolerated taint字样基本就是污点问题。最常见的输出长这样Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 12s default-scheduler 0/8 nodes are available: 1 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }, 5 node(s) didnt match node selector.看到之后接着查节点污点kubectl get nodes -o custom-columnsNAME:.metadata.name,TAINTS:.spec.taints这个命令能一次性把所有节点的污点列出来比一个个 describe 高效得多。5.2 明明加了容忍为什么还是被驱逐这个坑迷惑性最强。问题通常出在 effect 不匹配上。比如节点是NoExecute污点你只写了 NoSchedule 的容忍那等于没写。或者节点污点是dedicatedgpu:NoSchedule你容忍里只写了 key 和 effect 没写 value而 operator 用的又是 Equal那匹配不上。以我的经验最稳妥的排查方式是先把节点污点完整打出来kubectl get node node-name -o jsonpath{.spec.taints} | jq再跟 Pod 里的 tolerations 一个个对。如果是系统内置污点引发的驱逐别忘了检查 Pod 的 tolerations 里有没有node.kubernetes.io/not-ready和node.kubernetes.io/unreachable对应的 NoExecute 容忍没有的话默认只有 300 秒宽限期节点故障超过 5 分钟照样被驱逐。5.3 容易踩但不容易意识到的坑这里整理几个我在生产环境里踩过或者帮别人排查过的典型问题。kubelet 重启导致节点短暂 NotReady这种情况很常见。kubelet 升级、重启、挂起节点都会短暂变成 NotReady触发 unreachable 污点。如果你的 Pod 没配 NoExecute 容忍300 秒宽限期一过就会被驱逐。在线业务建议显式加长这两个容忍能有效避免“一升级就抖动”的问题。DaemonSet 与污点的关系DaemonSet 默认会对not-ready和unreachable做容忍所以它不会因为节点 NotReady 而“消失”。但是如果你给某个节点打了自定义NoSchedule污点DaemonSet 的 Pod 同样上不去除非你在 DaemonSet 模板里显式写容忍。很多网络插件比如 CNI是 DaemonSet 方式部署的给它所在节点打污点之前务必先把 DaemonSet 的容忍配上不然节点上的 Pod 网络会全部挂掉。误删污点导致调度混乱有人调试完节点去污点的时候把 key 名打错相当于给节点加了一个新污点。这个错误比没去污点更隐蔽因为 describe 节点的时候一眼看过去确实有一条污点但名字不对结果业务 Pod 照样被拦截。所以去污点前后用kubectl describe node核对一下污点全名非常有必要。多个 NoExecute 容忍同时命中当多个容忍都匹配同一个污点时以最短的 tolerationSeconds 为准。比如一个容忍配了 300 秒另一个配了 60 秒节点故障后 Pod 只会撑 60 秒。这个逻辑容易让人误解以为会累加或者取最长实际不是。5.4 问题速查表现象可能原因排查方式解决方案Pod Pending 且事件显示 untolerated taint节点污点未匹配容忍kubectl get nodes -o custom-columnsNAME:.metadata.name,TAINTS:.spec.taints添加精确匹配的容忍Pod Pending 且事件显示 didnt match node selector节点亲和性不满足检查节点 labels调整 nodeSelector / nodeAffinityPod 运行中突然被驱逐NoExecute 污点被触发查看节点事件与污点配置 tolerationSeconds 与 NoExecute 容忍自定义污点下 DaemonSet Pod 起不来DaemonSet 模板缺少容忍kubectl get ds -n namespace查看模板给 DaemonSet 添加容忍节点维护后新旧 Pod 调度混乱污点未清理或误加新污点describe 节点核对污点 key使用精确命令去污点5.5 从调度层面聊聊集群治理污点这个东西在单集群里用得越多越需要一套规则来治理。我们团队沉淀下来的经验是所有污点的 key 必须是“全局词汇表”里登记过的谁要新增一个 key先写文档说明用途避免不同业务组之间自定义 key 互相冲突。比如 A 组用dedicatedgpu表示 GPU 专用节点B 组不知道也拿dedicated当键名给别的节点打污点两个 key 完全一样但 value 不同那 A 组的容忍配置就可能误匹配到 B 组的节点上调度结果完全不可控。给 Pod 加容忍也要有审批约束。我给团队定的最低标准是如果容忍里出现了operator: Exists且没有 key必须走 review因为这意味着 Pod 会无视所有污点。这种 Pod 一旦上线节点故障自愈机制对它就完全失效了属于整个集群里最危险的一种配置。最后再分享一个小技巧。很多人在调试完污点之后会忘记清理现场生产环境的节点上一堆历史污点每条都带着过期的维护记录。我建议每季度做一次全节点污点巡检把没有对应文档、没有业务容忍引用的污点清掉。这个巡检动作虽然操作量不大但对集群调度健康度很有帮助能避免很多“模拟两可的脏状态”在关键时刻跳出来恶心你。