1. 为什么Kubernetes调度器需要"污点与容忍度"这套机制
先从一个生产环境里最常见的诉求说起：我有三台机器，其中一台是SSD盘的大内存机型，我想让数据库Pod只跑在这台机器上，其他业务Pod一概不许碰它。用Kubernetes默认的nodeSelector或者节点亲和性，能做到吗？能，但也只能做到一半——nodeSelector是"正向选择"，它告诉调度器"这个Pod只愿意去带某个标签的节点"，可它拦不住其他Pod也往这台机器上挤。换句话说，你可以给Pod挑节点，但没法给节点"赶人"。
污点（Taint）和容忍度（Toleration）解决的就是这个"赶人"问题。它俩的配合关系和亲和性调度刚好相反：亲和性是Pod主动挑节点，污点和容忍度是节点主动拒Pod。节点一旦被打上污点，除非Pod声明了对应的容忍度，否则调度器根本不会把这个Pod放到这个节点上。这就是Kubernetes调度的"反向过滤"机制。
我在刚开始搞K8s的时候一度很迷惑，总觉得有nodeSelector就够用了，直到遇到一个真实场景才明白这套机制不可替代：那次是给线上集群加了一台GPU机器，专门跑推理服务。没有污点之前，普通的Web Pod和定时任务Pod全被调度到了GPU节点上，好好的GPU资源被一堆CPU任务占着，推理服务反而因为资源争抢变慢。后来给GPU节点打了专用污点，只在推理服务的Deployment里声明了容忍度，问题瞬间解决。这就是污点存在的价值——资源隔离和专属节点管理，光靠正向选择是做不到的。
这套机制适合谁学？只要你的集群里超过三台节点、开始考虑"哪类Pod该跑在哪类机器上"的问题，就需要把污点和容忍度彻底搞明白。它还牵扯到节点维护、集群排障、Pod驱逐等一系列场景，属于K8s调度的进阶必修课。
2. 污点的三个Effect：从NoSchedule到NoExecute的选择逻辑
2.1 污点的结构：一个污点就是key=value:effect
先看污点到底长什么样。执行kubectl describe node的时候，你会在输出里看到类似这样的字段：
Taints: node-role.kubernetes.io/control-plane:NoSchedule一个污点由三部分组成：key、value和effect。key和value是键值对，value可以留空，effect是污点的行为类型。上面这个例子中，key是node-role.kubernetes.io/control-plane，没有value，effect是NoSchedule。
kubernetes内置的污点通常用node.kubernetes.io/或node-role.kubernetes.io/这类带命名空间前缀的key，目的是避免和用户自定义的key冲突。你自己打污点时，也建议用类似的app=redis、dedicated=storage这样的语义化key，方便一眼看出这个污点想表达什么。
2.2 三种effect分别管什么
污点的核心就是effect这个字段，它决定了节点对不容忍的Pod做到什么程度：
| Effect | 行为 | 典型场景 |
|---|---|---|
NoSchedule | 新的不容忍Pod不允许调度到该节点，已存在的Pod不受影响 | 给专用节点、GPU节点打标 |
PreferNoSchedule | 软性约束，调度器尽量不把Pod调度上去，但没有硬性禁止 | 节点即将维护、弹性收缩前的"软提醒" |
NoExecute | 不容忍的Pod会被立即驱逐；容忍但没设tolerationSeconds的Pod会一直留着，设了的会在指定时间后被驱逐 | 节点故障隔离、节点下线维护 |
这里需要特别注意NoExecute和另外两个的差别：NoSchedule只管新来的，NoExecute连已经在节点上跑着的Pod也会被清走。这意味着NoExecute是一个非常强力的操作，用的时候一定要想清楚后果。
2.3 为什么默认集群里master节点不需要你去操心
用过kubeadm部署集群的朋友都应该见过，初始化完成之后master节点上天然带有一个污点：
node-role.kubernetes.io/master:NoSchedule # 或者新版本中的 node-role.kubernetes.io/control-plane:NoSchedule这就是为什么刚搭好的集群里，普通业务Pod不会跑到master节点上的原因——不是调度器有什么特殊的魔法，而是这行污点在起作用。你如果想往master节点上调度特定Pod（比如监控组件、网络插件），在Pod模板里加上对应的容忍度就行。很多初学者第一次遇到"Pod一直Pending"的问题，查了半天发现是master节点污点没容忍，其实就是没理解这个机制。
3. 污点实操：打上、查看、移除的完整命令与背后逻辑
3.1 kubectl taint的三种常用操作
污点的增删查操作非常简洁，全是kubectl taint这一个命令：
# 给节点node1打上一个污点，key为dedicated，value为storage，effect为NoSchedule kubectl taint nodes node1 dedicated=storage:NoSchedule # 查看节点上的污点 kubectl describe node node1 | grep -A2 Taints # 或更简洁的方式 kubectl get node node1 -o jsonpath='{.spec.taints}' # 移除污点（在key后面加一个减号） kubectl taint nodes node1 dedicated=storage:NoSchedule-这里多说一句移除的写法：减号必须在effect后面。写错位置会导致命令失败，比如写成dedicated-:NoSchedule就不对。正确格式是把整个key=value:effect作为一个完整单位，在末尾加上减号，表示"删除这个污点"。
3.2 只打value不留value的写法
污点的value不是必须的，如果只是想做简单的分类，可以直接省略：
# 只打key和effect kubectl taint nodes node1 key1:NoSchedule # 对应的容忍度写法在Pod yaml里是： tolerations: - key: "key1" operator: "Exists" effect: "NoSchedule"省略value的污点，在容忍度里必须用operator: Exists来匹配，不能写Equal。这个细节后面讲容忍度配置时会详细展开，先记着有这么回事。
3.3 节点维护时最常用的"软驱逐"套路
生产环境里经常要滚动维护节点，比如升级内核、替换硬件。这种场景我推荐用NoExecute配合tolerationSeconds来优雅迁移Pod，而不是直接把节点kubectl drain掉。思路是这样的：
- 先给节点打上
NoExecute污点，调度器会立即把不容忍的Pod全部驱逐。 - 对于你希望"再跑一会儿、等任务自然结束"的Pod，在容忍度里设置
tolerationSeconds: 60，表示"我还能容忍这个污点60秒，60秒后自动走人"。
这比直接drain更可控。drain是"立刻终止+重新调度"，而tolerationSeconds给了Pod一个宽限期，适合那些需要优雅退出的长任务。
4. 容忍度配置详解：从最简单的yaml到operator匹配规则
4.1 一个最基础的容忍度长什么样
容忍度写在Pod模板的spec.tolerations字段下，最常见的写法是：
apiVersion: apps/v1 kind: Deployment metadata: name: redis-on-storage spec: replicas: 1 selector: matchLabels: app: redis template: metadata: labels: app: redis spec: containers: - name: redis image: redis:7 tolerations: - key: "dedicated" operator: "Equal" value: "storage" effect: "NoSchedule"这个容忍度的意思是："我能够容忍dedicated=storage:NoSchedule这个污点"。调度器看到节点上有这个污点，又发现Pod声明了匹配的容忍度，就不会因为污点而拒绝它。
4.2 operator字段：Equal和Exists的区别
operator是容忍度配置里最容易搞混的字段，只有两个取值：
Equal：要求key、value、effect三个都要匹配。如果Pod里声明的value是storage，而节点污点是dedicated=ssd，就匹配不上。Exists：只要key匹配就行，不管value是什么。如果节点污点是dedicated=ssd:NoSchedule，而Pod容忍度写了key: dedicated, operator: Exists, effect: NoSchedule，就能匹配上。
什么时候用Exists？我个人的经验是：当你只关心"这个节点的某个污点类目我能不能容忍"，不关心具体值的时候，用Exists。比如容忍所有和GPU相关的污点，就直接写key: gpu, operator: Exists，这样无论value是nvidia还是amd都能过。
4.3 空effect的容忍度：匹配所有effect
还有一个比较反直觉的写法：容忍度里的effect字段是可以省略的。一旦省略，这个容忍度会匹配该key下的所有effect类型。
tolerations: - key: "dedicated" operator: "Exists"这个写法会同时容忍dedicated:NoSchedule、dedicated:PreferNoSchedule和dedicated:NoExecute。看起来很方便，但副作用也很明显：如果节点上打了NoExecute污点，你的Pod也会因为容忍而不被驱逐。所以生产环境里，我建议还是老老实实写明effect，不要偷懒省略。
4.4 容忍所有污点的"万能容忍"
有一种场景需要Pod能调度到任意节点，包括打了各种污点的节点。这时可以用一个非常激进的写法：
tolerations: - operator: "Exists"注意，这里连key都没写。这个容忍度表示"我啥污点都能容忍"。一般只有系统级组件才这么干，比如kube-proxy、calico这类网络插件，它们在集群里每个节点都要跑，不能因为污点被落下。普通业务Pod如果用这种写法，你会失去污点带来的资源隔离意义，建议谨慎。
5. 实战案例：用污点和容忍度把"专属节点"和"混合部署"玩明白
5.1 案例一：给数据库单独圈出一台机器
场景：我有三台节点node1、node2、node3，node1是SSD存储型机器，只想跑数据库。
第一步，给node1打污点：
kubectl taint nodes node1 dedicated=storage:NoSchedule第二步，给数据库Pod的Deployment加上容忍度：
tolerations: - key: "dedicated" operator: "Equal" value: "storage" effect: "NoSchedule"这两步做完，其他没有容忍度的业务Pod就会被调度器自动避开node1，数据库Pod又能正常调度上去。如果再加上节点亲和性把数据库Pod也"钉死"在node1上，就形成了完整的"专属节点"方案：
affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: dedicated operator: In values: - storage注意，污点负责拒人，亲和性负责拉人，两者是配合关系而不是替代关系。只有亲和性的话，其他Pod还是能跑来抢资源；只有污点的话，数据库Pod也是"有资格"但没"意愿"往这台机器上跑。两个一起用，才是生产级做法。
5.2 案例二：带宽限期的容忍，让Pod优雅腾退
再来看维护场景。我要对node2做一次内核升级，希望上面所有Pod在120秒内自动迁移走，但允许它们优雅退出。
kubectl taint nodes node2 maintenance=true:NoExecute所有不容忍的Pod会被立即驱逐。如果部分Pod想优雅退出，在Pod模板里加：
tolerations: - key: "maintenance" operator: "Equal" value: "true" effect: "NoExecute" tolerationSeconds: 120加了tolerationSeconds: 120的Pod，会在污点打上后继续运行120秒，然后被驱逐。这120秒内如果Pod正常结束，就不会被强制杀掉，实现平滑腾挪。这个技巧在做节点滚动升级时非常实用，比直接kubectl drain更温和可控。
5.3 案例三：利用内置污点容忍让监控Paas组件跑全节点
集群里有些组件必须每个节点都有一份，比如日志采集的DaemonSet。但你的集群里可能有不同类型的节点：GPU节点、存储节点、master节点都打了不同的污点。要让DaemonSet全部覆盖，直接在Pod模板里声明万能容忍：
tolerations: - operator: "Exists"DaemonSet对污点的处理方式有个好消息：如果你不给DaemonSet写容忍度，它只会调度到没有污点的节点。网络插件、日志采集这类组件如果漏了容忍度，表现就是"某些节点的Pod一直没创建"，因为DaemonSet控制器默认不会绕过污点。这个坑我踩过，排查了半天才发现是容忍度写漏了。
6. 常见坑与排查路径：Pod一直Pending怎么办
6.1 排查链路：从describe node开始
遇到Pod一直Pending，最典型的排查路径分三步：
第一步，看Pod事件：
kubectl describe pod <pod-name>如果看到类似0/3 nodes are available: 3 node(s) had taint {dedicated: NoSchedule}，问题定位就很明确了，这就是污点导致的调度失败。
第二步，看节点污点：
kubectl get node <node-name> -o jsonpath='{.spec.taints}'第三步，对照Pod的容忍度配置。把Pod yaml里的tolerations字段和节点污点逐个比对，注意三个匹配条件：key是否一样、value是否一样（或operator是否为Exists）、effect是否一样。
6.2 坑一：effect写少了或写错了
最常见的低级错误是只写了key和value，忘了写effect：
tolerations: - key: "dedicated" operator: "Equal" value: "storage"这种写法实际匹配的effect是"所有effect"，所以理论上能容忍NoSchedule。但反过来说，如果节点上同时有dedicated=storage:NoExecute污点，这个Pod也不会被驱逐。很多人以为"我明明写了容忍度，为什么还是被驱逐"，往往就是effect没写全。
6.3 坑二：容忍度匹配了，但Pod还是不上节点
还有一种情况：容忍度看着没问题，Pod却仍然调度不到目标节点。这时候要检查是不是还有别的限制，比如nodeSelector、节点亲和性、资源请求量不够、节点本身Ready状态异常。污点和容忍度只是调度的一部分约束，不是全部。我见过有人给节点打了污点、给Pod写了容忍度，结果忘了给Pod设置足够的CPU和内存request，调度器依然因为资源不足而把Pod搁在Pending状态。
6.4 坑三：NoExecute驱逐风暴
在早期版本的Kubernetes里，NoExecute污点一旦打上，所有不容忍的Pod会被立即驱逐，如果节点上有大量Pod，就会在短时间内触发大量Pod重建，对集群控制面和底层存储造成不小压力。现在的版本虽然引入了tolerationSeconds和Pod级优雅终止机制来缓解，但你在批量操作前还是要确认好影响面。稳妥做法是先用PreferNoSchedule观察一段时间，确认没有异常后再切换成NoExecute。
6.5 一个小技巧：用标签和污点组合做"灰度下线"
给要下线的节点同时打上标签和污点，可以做出"先把新Pod引走，再慢慢清旧Pod"的效果：
kubectl label nodes node3 state=offline kubectl taint nodes node3 state=offline:PreferNoSchedulePreferNoSchedule是软性约束，新的Pod会尽量被调度到其他地方，但实在没位置也可能被放上来。过一两天观察节点负载降下来了，再把污点升级为NoExecute强制清空，整个过程对业务影响最小。
最后再聊一点自己的体会
污点和容忍度这套机制，刚接触时会觉得是"多了几个字段"而已，真正在集群里跑上业务才会意识到它的价值。它和亲和性调度就像一正一反两套规则，配合起来才能实现精细的调度控制。我最后一次强调那个容易踩的组合逻辑：亲和性决定Pod"愿意去哪儿"，污点决定节点"允许谁来"，容忍度则是Pod的"入场券"。三者配合，资源隔离、专属节点、优雅腾退这些场景才能做得干净利落。
另外建议你把污点的打法和去法抄在一张便签上，因为命令格式实在容易记混——打污点写kubectl taint nodes node1 key=value:NoSchedule，去污点在末尾加减号kubectl taint nodes node1 key=value:NoSchedule-。检查节点污点用describe node最直观，能同时看到Taints和Allocated resources等信息，一次排掉大部分调度问题。
