在Kubernetes集群中，默认调度器会把Pod尽量分散到所有可用节点上，这对于同构节点没有问题。但实际生产环境常常会出现异构节点池，比如一部分节点带有GPU、一部分节点使用高性能SSD、还有一部分节点专门留给系统组件。如果不对这些节点做隔离，一个普通的Web服务可能被调度到昂贵的GPU节点上，既浪费资源又影响需要GPU的任务。解决这个问题的第一步是给节点打标签，但仅仅依靠标签和nodeSelector是不够的，因为nodeSelector是硬性要求，并不能阻止其他Pod调度过来。真正能实现专用节点池的是污点（Taint）和容忍度（Toleration）。
污点的作用类似于给节点贴上一张排斥标签，默认情况下所有Pod都不愿意调度到带有污点的节点上，除非Pod明确声明了对应的容忍度。这种机制比标签更严格，可以有效防止误调度。接下来我们会从污点的语法结构开始，逐步演示如何配置一个只允许特定工作负载运行的GPU专用节点池。
污点与容忍度的基本概念
污点由三个部分组成：key、value和effect。key和value是自定义的键值对，用来描述污点的含义，例如dedicated=gpu表示该节点专门用于GPU工作负载。effect字段决定了污点的排斥强度，Kubernetes提供了三种取值：NoSchedule、PreferNoSchedule和NoExecute。NoSchedule表示不允许新的Pod调度到该节点，但已经在该节点上运行的Pod不受影响；PreferNoSchedule是软性限制，调度器会尽量避免但不保证一定不调度；NoExecute最严格，不仅阻止新Pod调度，还会驱逐节点上已经存在但没有相应容忍度的Pod。
容忍度定义在Pod的spec中，用来告诉调度器该Pod可以接受带有哪些污点的节点。容忍度通过key、operator、value和effect来匹配节点上的污点。operator可以是Equal或Exists。当operator为Equal时，key、value和effect都必须与污点完全匹配；当operator为Exists时，只需要key和effect匹配，value可以为空，这种写法常用于匹配同一key下不同value的污点。例如一个Pod想容忍所有dedicated开头的污点，可以写成key: dedicated、operator: Exists、effect: NoSchedule。
给节点添加污点使用kubectl taint命令，基本格式为kubectl taint nodes <node-name> key=value:effect。移除污点则在命令末尾加上减号，例如kubectl taint nodes node1 dedicated=gpu:NoSchedule-。污点一旦添加，没有对应容忍度的Pod就无法调度到该节点，这为构建专用节点池提供了基础。
配置专用节点池的完整步骤
假设集群中有三个节点：node1、node2、node3，其中node1和node2带有GPU，我们希望它们只运行需要GPU的任务。首先给节点打标签，方便后续使用nodeSelector或affinity进行进一步限制：
kubectl label nodes node1 node-role.kubernetes.io/gpu=true kubectl label nodes node2 node-role.kubernetes.io/gpu=true
然后给这两个节点添加污点，使用NoSchedule效果阻止普通Pod调度上来：
kubectl taint nodes node1 dedicated=gpu:NoSchedule kubectl taint nodes node2 dedicated=gpu:NoSchedule
添加污点后，所有没有对应容忍度的Pod将无法调度到node1和node2。接下来，为需要GPU的Pod添加容忍度，例如一个训练任务的Deployment：
apiVersion: apps/v1
kind: Deployment
metadata:
name: gpu-training
spec:
replicas: 2
selector:
matchLabels:
app: gpu-training
template:
metadata:
labels:
app: gpu-training
spec:
tolerations:
- key: dedicated
operator: Equal
value: gpu
effect: NoSchedule
nodeSelector:
node-role.kubernetes.io/gpu: "true"
containers:
- name: training
image: nvidia/cuda:11.8.0-base-ubuntu20.04
resources:
limits:
nvidia.com/gpu: 1
这里同时使用了容忍度和nodeSelector。容忍度允许Pod被调度到有污点的GPU节点，而nodeSelector进一步限制Pod只能运行在带有GPU标签的节点上，两者配合避免Pod被调度到其他没有GPU但也没有污点的节点上。如果只有容忍度而没有nodeSelector，Pod仍然可能被调度到普通节点；如果只有nodeSelector而没有容忍度，Pod会因为普通节点没有GPU标签而无法匹配，而GPU节点因为污点又被排斥，最终导致Pod无法调度。
在实际操作中，可以通过kubectl describe pod查看调度事件。如果Pod长时间处于Pending状态，事件中通常会显示类似0/3 nodes are available: 2 node(s) had untolerated taint {dedicated: gpu}, 1 node(s) didn't match node selector的提示，根据提示可以快速定位是容忍度缺失还是标签选择器写错。
NoSchedule、PreferNoSchedule与NoExecute的区别
三种effect的差别直接影响到专用节点池的严格程度。NoSchedule是最常用的选择，它只阻挡新Pod的调度，不会影响已经运行的Pod，适合在创建节点池初期就配置好。但它的缺点是如果节点在加入集群时已经有一些Pod运行，后来添加NoSchedule污点，这些已有的Pod不会被自动驱逐，需要手动处理。PreferNoSchedule则是软限制，调度器会尽量避开带有该污点的节点，但如果集群资源紧张，Pod仍然可能被调度上去。这种效果适用于希望优先使用某些节点，但不强制排他的场景。
NoExecute是三种中最严格的，它不仅阻止新Pod调度，还会立刻驱逐节点上所有没有对应容忍度的Pod。如果希望给Pod一个缓冲时间，可以在容忍度中设置tolerationSeconds，节点会在该时间后才驱逐Pod。下面看一个NoExecute的容忍度示例：
tolerations: - key: dedicated operator: Equal value: gpu effect: NoExecute tolerationSeconds: 3600
这段配置表示Pod可以容忍GPU专用节点的NoExecute污点，但如果该节点因为其他原因被打上其他污点，Pod最多还能继续运行3600秒。注意tolerationSeconds只对NoExecute生效，对NoSchedule没有意义。
生产环境中常用NoExecute来维护节点。例如需要下线一台节点进行维护时，可以先添加一个NoExecute污点，给Pod一定的时间优雅退出，然后再执行drain操作。这样比直接kubectl drain更平滑，因为可以自定义时间窗口，而且不会一次性驱逐所有Pod造成服务波动。
生产实践中的避坑指南
第一个常见问题是忘记给系统组件添加容忍度。如果给节点打上了NoSchedule污点，但集群中的一些DaemonSet（比如日志采集、监控代理、CNI插件）没有配置对应的容忍度，这些组件将无法在专用节点上运行。解决方法是给这些DaemonSet的Pod模板添加容忍度，或者使用更宽泛的容忍规则，例如：
tolerations: - operator: Exists
这个配置表示Pod可以容忍所有污点，适用于需要在每个节点上运行的集群级组件。但在普通业务Pod中不要滥用，否则会破坏专用节点池的隔离效果，导致Pod随意调度到任何节点。
第二个问题是污点的key和value需要与容忍度完全匹配。如果节点上已经有污点dedicated=gpu:NoSchedule，而Pod容忍度写成了dedicated=gpu:NoExecute，效果不匹配，Pod依然无法调度。建议在配置变更后使用kubectl describe pod查看事件，确认是否因为污点导致调度失败。常见的报错信息中会明确列出未容忍的污点，根据报错修正容忍度配置即可。
第三个问题涉及集群自动伸缩。在托管的Kubernetes服务中，节点池的污点配置通常需要在节点池创建时就指定，不能只靠手动打污点，因为自动扩容出来的新节点可能没有污点。把节点池的污点和标签配置在基础设施层，才能保证所有节点行为一致。另外在缩容时，如果节点池中的节点带有污点，需要确认Pod是否具备容忍度，否则可能导致Pod无法调度到新扩容的节点上。
Kubernetes专用节点池污点容忍修改时间：2026-09-23 08:43:45