K8s调度排障：亲和性、污点与容忍的七步决策链-育师

1. 这不是“配个yaml就完事”的调度问题：K8s集群调度的本质是资源与意图的精密对齐

你有没有遇到过这样的场景：一个关键业务Pod死活调度不到指定节点，describe看状态永远卡在Pending；或者明明给节点打了label，亲和性配置也写了，结果Pod还是随机飘到其他机器上；又或者刚给节点加了污点，想把非核心服务赶走，结果发现连监控Agent都跟着一起消失了？这些都不是配置写错了那么简单——它们暴露的是对K8s调度器底层逻辑理解的断层。k8s集群调度，亲和性，污点，容忍，排障这五个词串在一起，本质上不是功能罗列，而是一条完整的“意图表达—资源约束—冲突识别—问题定位”闭环链路。亲和性（Affinity）是你向调度器发出的“我希望去哪”的积极请求；污点（Taint）是节点主动声明的“我不欢迎谁”的硬性门槛；容忍（Toleration）则是Pod携带的“我有通行证”的准入凭证；而排障，就是当这条链路某处卡住时，如何像拆解一台精密仪器一样，逐层剥离调度决策过程，找到那个被忽略的、微小却致命的逻辑缝隙。我带过的几个团队里，90%的调度类故障，根源不在yaml语法错误，而在于没搞清“调度器到底看了哪些信息、按什么顺序做判断、在哪一步被拦下了”。比如，你写的nodeAffinity可能根本没被触发，因为Pod先被taint拒之门外；或者toleration写对了，但key-value匹配精度没对上，一个空格、一个大小写、一个effect类型不一致，就足以让整个调度流程在预选阶段直接返回false。这不是玄学，是可验证、可追踪、可复现的工程逻辑。这篇文章不讲概念定义，只讲我在真实生产环境里，如何用kubectl describe、scheduler日志、甚至手动模拟调度器预选/优选流程，把一个Pending Pod从“黑盒状态”还原成“白盒决策路径”。适合正在被调度问题困扰的SRE、平台工程师，也适合刚从单机部署转向集群管理的开发者——你不需要背熟所有API字段，但必须知道调度器在你提交Pod后，究竟做了哪七步判断，以及每一步失败时，它会在哪里留下最真实的线索。

2. 调度器不是魔法盒：从预选到优选，拆解调度决策的七层过滤网

K8s调度器的工作绝非“随机挑一个空闲节点”，它是一套严格分阶段执行的过滤流水线。理解这个流程，是所有排障的起点。我把整个过程拆解为七个不可跳过的环节，每个环节都对应着亲和性、污点、容忍等机制的实际生效位置。你提交一个Pod后，调度器会依次执行：

2.1 预选阶段（Predicates）：硬性门槛，一票否决

这是调度的第一道关卡，所有节点必须通过全部检查，否则直接淘汰。这里没有“差不多”，只有“是”或“否”。亲和性中的requiredDuringSchedulingIgnoredDuringExecution（硬亲和）和污点/容忍机制，就在此阶段起效。

NodeName检查：如果Pod.spec.nodeName已指定，直接锁定该节点，跳过后续所有预选。这是最暴力的调度方式，但完全绕过调度器智能，仅用于极特殊场景（如调试）。
TaintToleration检查：这是污点机制的核心战场。调度器遍历节点上所有taint，逐一比对Pod的tolerations。匹配规则极其严格：taint.key == toleration.key && (taint.value == toleration.value || toleration.operator == "Exists") && taint.effect == toleration.effect。注意，toleration.effect必须精确匹配taint.effect（NoSchedule/PreferNoSchedule/NoExecute），哪怕你写了NoSchedule，节点taint是NoExecute，也会被拒绝。我见过太多人在这里栽跟头，以为toleration.effect写成""就能通吃，其实空字符串只匹配effect为空的taint，而默认taint effect就是NoSchedule，不是空。
NodeSelector与NodeAffinity.required检查：这两者本质是同一类硬约束。NodeSelector是简单label键值对匹配；NodeAffinity.required则支持更复杂的逻辑（如In、NotIn、Exists）。但关键点在于：它们只检查节点label，不检查taint。也就是说，一个节点label完全匹配，但带着NoExecute污点且Pod无对应toleration，它依然会在TaintToleration检查中被淘汰，根本轮不到NodeAffinity生效。
CheckVolumeBinding：如果Pod声明了PVC，此检查确保节点能访问到对应的PV（如本地存储路径存在、网络存储插件已安装）。这常被忽略，但却是导致Pending的隐形杀手。

提示：kubectl get nodes -o wide只显示节点基础信息，要查taint，必须用kubectl describe node <node-name>，在输出的Taints字段下找；要查label，用kubectl get node <node-name> -o jsonpath='{.metadata.labels}'，避免describe输出里混杂大量无关信息。

2.2 优选阶段（Priorities）：软性打分，择优录取

通过预选的节点进入此阶段，调度器为每个节点计算一个分数（0-10分），分数最高者胜出。亲和性中的preferredDuringSchedulingIgnoredDuringExecution（软亲和）在此阶段起效。它不决定“能不能去”，而决定“更想去哪”。

NodeAffinity.preferred权重计算：每一条preferred rule有一个weight（1-100）。调度器计算该rule匹配的节点label数量，乘以weight，累加得到总分。例如，rule要求zone=beijing，weight=50，节点label有zone=beijing且region=cn-north，则匹配成功，+50分；若节点只有region=cn-north，zone无匹配，则+0分。重点来了：soft affinity的分数是叠加的，但不会超过100分上限。这意味着，即使你写了10条weight=10的rule，最终得分也最多100。所以，与其堆砌大量低权重rule，不如聚焦2-3个最关键的维度（如硬件型号、网络延迟、安全等级）并赋予高权重。
其他优选策略：LeastRequestedPriority（优先选择资源空闲率高的节点）、BalancedResourceAllocation（平衡CPU/MEM使用率）、ImageLocalityPriority（优先选择已缓存所需镜像的节点）等。这些是调度器内置策略，通常无需修改，但理解它们有助于解释“为什么Pod去了A节点而不是B节点”，尤其当软亲和分数相同时。

2.3 绑定阶段（Binding）：落槌定音

调度器选定最优节点后，向API Server发送一个Binding对象，将Pod.spec.nodeName设置为该节点名。这一步是原子操作，成功即完成调度。如果此时节点因网络问题无法响应，或API Server压力过大，Binding可能失败，Pod会回到Pending状态，等待下一轮调度周期（默认10秒）。

2.4 污点/容忍的三重Effect：NoSchedule、PreferNoSchedule、NoExecute

很多人以为污点只有“禁止调度”一种效果，其实它有三种精细控制级别，直接影响排障思路：

NoSchedule：最常用。新Pod若无对应toleration，绝不允许调度到此节点。已存在的Pod不受影响。这是“防新增”的门槛。
PreferNoSchedule：软性建议。调度器会尽量避免将新Pod调度至此，但如果实在没有其他合适节点，仍会强行调度。这相当于一个“低优先级警告”，在资源紧张时会被忽略。排障时，如果看到Pod调度到了带PreferNoSchedule污点的节点，不要慌，先检查集群整体资源是否真的耗尽。
NoExecute：最严厉。不仅阻止新Pod调度，还会驱逐（Evict）当前已在该节点上运行、且没有对应toleration的Pod。这是“清场令”。一旦配置，务必确认所有关键工作负载都已添加了正确的toleration，否则可能引发雪崩式驱逐。我曾在一个集群升级中误将NoExecute应用到master节点污点，结果etcd、kube-apiserver等核心组件因toleration缺失被逐出，整个集群瞬间失联。

注意：kubectl taint nodes <node-name> key=value:NoExecute这条命令，如果没有指定tolerationSeconds，NoExecute污点会立即驱逐现有Pod。安全做法是加上tolerationSeconds=3600（1小时），给运维留出应急窗口。

2.5 亲和性的双重维度：Node与Pod，解决不同场景

亲和性分为NodeAffinity和PodAffinity/PodAntiAffinity，它们解决的是完全不同的问题，混淆是排障大忌。

NodeAffinity：解决“Pod和节点的关系”。目标是让Pod落在具备特定硬件、软件或安全属性的节点上。例如，GPU任务必须调度到装有NVIDIA驱动的节点；金融类应用必须落在通过等保三级认证的物理服务器上。它的配置在Pod.spec.affinity.nodeAffinity下。
PodAffinity/AntiAffinity：解决“Pod和Pod的关系”。目标是控制工作负载的拓扑分布。PodAffinity让同类Pod尽量靠近（如微服务间低延迟通信，需同节点或同机架）；PodAntiAffinity则强制分散（如高可用应用，避免单点故障）。它的配置在Pod.spec.affinity.podAffinity下。关键限制：PodAffinity/AntiAffinity依赖于节点label，且只能跨命名空间生效（除非指定topologyKey为failure-domain.beta.kubernetes.io/zone，才支持跨AZ）。如果你发现PodAntiAffinity没生效，第一反应不是yaml写错，而是检查所有相关节点是否都有相同的topologyKey label（如topology.kubernetes.io/zone: us-west-2a）。

2.6 调度器插件化演进：从Policy到Framework

K8s 1.19+ 默认启用Scheduler Framework，取代了旧的Policy文件。这意味着你不能再通过--policy-config-file参数加载自定义策略。所有调度逻辑（包括预选和优选）都通过插件（Plugin）实现。核心插件如：

NodeName,TaintToleration,NodeAffinity：预选插件
NodeResourcesFit,InterPodAffinity,NodeAffinity：优选插件

理解这一点，对高级排障至关重要。例如，你想禁用某个优选策略（如ImageLocalityPriority）来排除干扰，现在需要修改Scheduler的启动参数--config指向一个包含plugins字段的配置文件，而非编辑一个JSON Policy。官方文档里那些“deprecated”的字样，背后是整个调度架构的重构。不更新知识，排障就会陷入“方法论失效”的困境。

2.7 为什么你的配置“看起来对”，却不起作用？三个高频逻辑陷阱

陷阱一：Effect类型错位。你在节点上加了kubectl taint nodes node1 dedicated=special:NoExecute，却在Pod里写了toleration: key: dedicated, operator: Equal, value: special, effect: NoSchedule。注意，effect必须完全一致，NoExecute ≠ NoSchedule。这是字符级的精确匹配。
陷阱二：Label键值空格/大小写。kubectl label nodes node1 disktype=ssd和nodeAffinity: matchExpressions: - key: disktype, operator: In, values: ["ssd "]（注意values里ssd后面有个空格）。K8s的label匹配是严格字符串比较，空格也是字符。
陷阱三：Required与Preferred混用失效。你写了NodeAffinity的required规则（硬约束），同时也写了preferred规则（软偏好）。但当required规则本身无法满足时（如指定label的节点全被taint挡住了），整个NodeAffinity检查失败，preferred规则根本不会被评估。排障时，永远先确保required部分能过，再优化preferred。

3. 排障不是猜谜：一套标准化的五步诊断法，精准定位Pending根因

面对一个卡在Pending状态的Pod，别急着改yaml。我用这套在多个千节点集群验证过的五步法，能在5分钟内锁定问题核心。它不依赖任何第三方工具，纯靠kubectl和原生日志。

3.1 第一步：获取Pod的原始调度事件（kubectl describe的黄金信息）

这是最直接、最权威的线索来源。kubectl describe pod <pod-name> -n <namespace>的输出中，Events部分是调度器留下的“审讯笔录”。

Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 2m default-scheduler 0/12 nodes are available: 3 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 5 node(s) didn't match node selector, 4 node(s) didn't satisfy existing pods anti-affinity rules.

这段信息价值巨大：

数字量化：“0/12 nodes are available” 告诉你集群有12个节点，但0个可用，问题很严重。
分类归因：它明确告诉你失败原因被分为三类：taint（3个节点）、node selector（5个节点）、anti-affinity（4个节点）。这直接指明了排查方向——先看taint，因为它是硬门槛，优先级最高。
具体提示：node-role.kubernetes.io/master:这个taint是K8s默认给master节点加的，effect是NoSchedule。如果你的Pod没写toleration，它就永远进不了master。

实操心得：kubectl describe的Events是实时刷新的。如果Pod刚创建，Events可能为空。稍等10秒再执行，确保调度器已完成一轮完整评估。另外，kubectl get events --sort-by=.lastTimestamp可以查看集群全局事件，有时能发现更早的、影响范围更大的调度异常（如调度器Pod自身Crash）。

3.2 第二步：交叉验证节点状态（kubectl get nodes vs kubectl describe nodes）

kubectl get nodes只给你一张“健康快照”，而kubectl describe nodes才是“全身体检报告”。必须两者结合看。

用get nodes快速筛选：kubectl get nodes -o wide查看STATUS（是否Ready）、ROLES（是否master/node）、AGE（是否新加入）、VERSION（版本是否一致）。如果某个节点STATUS是NotReady，它会被调度器自动排除，无需再看其taint或label。
用describe nodes深挖细节：对get nodes中所有Ready节点，逐一执行kubectl describe node <node-name>。重点关注：
- Taints字段：列出所有taint及其effect。检查是否有你未预料到的taint（如运维临时加的dedicated=ai:NoSchedule）。
- Labels字段：复制粘贴出来，与你的Pod.spec.nodeSelector或nodeAffinity.matchExpressions中的key/value逐字比对。特别注意kubernetes.io/os: linux这类系统label，有时被意外覆盖。
- Allocatable字段：cpu: 3920m, memory: 15425Mi。这是节点实际可分配的资源，比Capacity（总资源）更重要。如果Allocatable的CPU已接近100%，即使节点显示Ready，预选阶段的CheckNodeCondition也会失败。

提示：kubectl get nodes -l <label-key>=<label-value>可以直接筛选出带特定label的节点，比describe一个个看快得多。例如，kubectl get nodes -l disktype=ssd快速定位所有SSD节点。

3.3 第三步：模拟调度器预选（手动执行逻辑推演）

当Events信息模糊（如只说“0/12 nodes available”但没分类），或你想彻底验证自己的理解时，就进入手动推演环节。拿出纸笔，或打开一个文本编辑器，按预选七步，对每个Ready节点做真·布尔运算。

假设Pod配置如下：

spec: tolerations: - key: "dedicated" operator: "Equal" value: "gpu" effect: "NoSchedule" affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: hardware-type operator: In values: ["A100", "V100"]

节点列表（已过滤Ready）：

node-gpu-01: Taints=[dedicated=gpu:NoSchedule], Labels=[hardware-type=A100]
node-cpu-01: Taints=[], Labels=[hardware-type=Intel-Xeon]
node-gpu-02: Taints=[dedicated=gpu:NoExecute], Labels=[hardware-type=A100]

推演：

node-gpu-01: TaintToleration检查 → taint.key="dedicated" == toleration.key, taint.value="gpu" == toleration.value, taint.effect="NoSchedule" == toleration.effect → ✅；NodeAffinity检查 → hardware-type=A100 ∈ ["A100","V100"] → ✅。通过。
node-cpu-01: TaintToleration → 无taint，✅；NodeAffinity → hardware-type=Intel-Xeon ∉ ["A100","V100"] → ❌。淘汰。
node-gpu-02: TaintToleration → taint.effect="NoExecute" ≠ toleration.effect="NoSchedule" → ❌。淘汰。

结论：只有node-gpu-01符合。如果Pod没调度过去，问题一定出在node-gpu-01自身（如资源不足、磁盘满、kubelet失联），而非调度逻辑。

3.4 第四步：检查调度器自身健康（别忘了“裁判员”可能生病了）

所有上述步骤都基于“调度器正常工作”的前提。但现实中，调度器Pod（通常是kube-scheduler）可能CrashLoopBackOff、OOMKilled，或与API Server连接中断。这是最隐蔽的“根因”。

检查调度器Pod状态：kubectl get pods -n kube-system | grep scheduler。正常状态是Running。如果看到CrashLoopBackOff，立刻kubectl logs -n kube-system <scheduler-pod-name> --previous查看上一次崩溃日志。
检查调度器配置：kubectl get cm -n kube-system kube-scheduler -o yaml。重点看data.config.yaml（如果存在）或args字段。确认--leader-elect=true（启用Leader选举，避免多实例冲突）和--bind-address（监听地址）配置正确。
验证调度器连通性：在调度器Pod内执行curl -k https://<api-server-ip>:6443/healthz。返回ok表示API Server可达。如果超时，检查网络策略（NetworkPolicy）是否误阻断了kube-system命名空间内的流量。

实操心得：在多Master集群中，kubectl get endpoints kube-scheduler -n kube-system会显示当前Active的调度器Endpoint。如果Endpoint为空，说明Leader选举失败，所有调度器都在等待，整个集群将无法调度任何新Pod。

3.5 第五步：启用调度器详细日志（终极武器，慎用）

当以上四步都无法定位，且问题偶发、难以复现时，就需要开启调度器的详细日志。这会产生海量日志，仅在调试时临时启用。

临时修改调度器参数：编辑kube-scheduler Deployment，为其容器添加-v=4参数（日志级别，4为详细调度决策日志）。
重启调度器：kubectl rollout restart deploy kube-scheduler -n kube-system。
实时跟踪日志：kubectl logs -f -n kube-system <new-scheduler-pod-name> | grep -E "(Predicate|Priority|Failed)"。

你会看到类似：

I0520 10:23:45.123456 1 factory.go:1234] Attempting to schedule pod: default/nginx-deployment-5c7b4d8c9-abcde I0520 10:23:45.123457 1 predicates.go:567] Predicate failed on node node-gpu-02: PodToleratesNodeTaints predicate mismatch for taints [{dedicated gpu NoExecute []}]

这行日志明确指出，在node-gpu-02上，PodToleratesNodeTaints这个预选函数失败，原因是taintdedicated=gpu:NoExecute与Pod的toleration不匹配。这就是最原始、最不可辩驳的证据。

注意：日志级别调至4后，日志量激增，可能迅速占满节点磁盘。调试完毕，务必立即将-v参数改回-v=2（默认），并重启调度器。

4. 从“能跑”到“跑好”：亲和性与污点的生产级最佳实践

配置能通过预选只是起点。在生产环境中，要让调度真正“聪明”、“稳定”、“可维护”，必须遵循一些经过血泪教训总结出的最佳实践。

4.1 污点管理：建立“节点角色”的宪法，而非临时补丁

把污点当作给节点“贴标签”的快捷方式，是最大的误区。污点的本质是节点能力的契约声明。一个设计良好的污点体系，应该像宪法一样稳定、清晰、可预期。

统一命名空间前缀：所有业务相关的污点key，强制使用business.example.com/前缀（如business.example.com/gpu:NoSchedule）。这能避免与K8s系统污点（如node-role.kubernetes.io/master）或未来K8s新特性污点冲突。kubectl taint nodes node1 gpu=true:NoSchedule这种裸key，迟早会撞车。
Effect分级使用：日常隔离，一律用NoSchedule；只有在进行节点维护、升级、下线等确定性操作时，才临时使用NoExecute，并务必配合tolerationSeconds。我见过一个集群，因NoExecute污点未设超时，导致一次网络抖动后，所有无tolerationSeconds的Pod被永久驱逐，数据丢失。
自动化污点注入：不要手动kubectl taint。将污点作为节点注册的一部分。例如，在cloud-init脚本或Ansible Playbook中，节点加入集群后，自动执行kubectl taint nodes $(hostname) business.example.com/gpu=true:NoSchedule --overwrite。--overwrite参数很重要，它能确保重复执行不报错，适配自动化流程。

4.2 亲和性配置：从“写死”到“继承”，降低yaml熵值

在大型集群中，为每个Deployment单独写一遍复杂的NodeAffinity，是运维噩梦。解决方案是利用K8s的PodPreset（已弃用）或更现代的MutatingAdmissionWebhook，但最简单有效的是命名空间级默认亲和性。

利用Default Scheduler Behavior：K8s调度器本身不支持命名空间级默认affinity，但你可以通过kubectl patch为命名空间打上label，然后在所有该命名空间下的Pod模板中，用envsubst或Helm模板，自动注入nodeAffinity。例如，Helm的values.yaml中定义nodeAffinity: {key: "zone", values: ["us-west-2a"]}，模板中{{- if .Values.nodeAffinity }}...{{- end }}。
软亲和的“兜底”策略：为所有生产命名空间，配置一个低权重（weight=10）的preferredDuringSchedulingIgnoredDuringExecution，要求topology.kubernetes.io/zone匹配。这样，即使没有硬约束，Pod也会优先留在同一个AZ内，降低跨AZ网络延迟和费用。这比在每个应用yaml里写一遍更可靠。

4.3 容忍（Toleration）的“最小权限”原则

给Pod加toleration，不是“越多越好”，而是“恰到好处”。过度授权会破坏污点的隔离意义。

显式声明，拒绝隐式匹配：永远使用operator: Equal，并明确写出value。避免operator: Exists，除非你100%确定该taint的value对所有Pod都无害。Exists就像一把万能钥匙，打开了所有门。
Effect精确匹配：toleration.effect必须与你要容忍的taint.effect完全一致。不要为了“省事”而写effect: ""，这只会匹配effect为空的taint，而绝大多数taint的effect都是NoSchedule。
生命周期绑定：toleration应与Pod的生命周期绑定。例如，一个需要GPU的训练任务，其toleration应随任务结束而消失。避免在长期运行的DaemonSet（如日志采集agent）上，配置了只针对短期任务的toleration，这会造成安全边界模糊。

4.4 排障工具链：构建你的个人“调度诊断包”

光靠kubectl是低效的。我整理了一个轻量级的Bash脚本集合，放在集群的Jump Server上，一键执行，输出结构化诊断报告。

#!/bin/bash # scheduler-diag.sh POD_NAME=$1 NAMESPACE=${2:-default} echo "=== POD SCHEDULING DIAGNOSIS FOR $POD_NAME ===" echo "1. POD EVENTS:" kubectl describe pod "$POD_NAME" -n "$NAMESPACE" 2>/dev/null | grep -A 10 "Events:" | grep -v "Events:" echo -e "\n2. NODE STATUS SUMMARY:" kubectl get nodes -o wide echo -e "\n3. READY NODES' TAINTS & LABELS:" kubectl get nodes -o wide | awk '$2=="Ready"{print $1}' | while read node; do echo "--- Node: $node ---" kubectl describe node "$node" 2>/dev/null | grep -E "^(Taints:|Labels:|Allocatable:)" done echo -e "\n4. SCHEDULER HEALTH:" kubectl get pods -n kube-system | grep scheduler kubectl get endpoints kube-scheduler -n kube-system 2>/dev/null

保存为scheduler-diag.sh，chmod +x，执行./scheduler-diag.sh my-app-7d8c9b4d8-abcde。5秒内，所有关键信息汇聚一屏，比手动敲10条命令高效太多。这个脚本没有外部依赖，纯K8s原生命令，安全、可靠、可审计。

4.5 监控告警：把“调度失败”变成“可预测的风险”

被动排障永远慢半拍。在Prometheus中，你应该监控并告警以下指标：

kube_scheduler_pending_pods：Pending状态的Pod总数。阈值设为>5，持续5分钟，触发告警。这表明调度器可能卡住或资源严重不足。
scheduler_scheduling_algorithm_duration_seconds_bucket：调度算法耗时的直方图。如果99分位数（le="1"）持续>1秒，说明调度器负载过高，需扩容。
kube_node_status_condition{condition="Ready",status="false"}：NotReady节点数。>0即告警，因为NotReady节点会直接从调度池中移除。
自定义指标：通过kubectl get events --field-selector reason=FailedScheduling的计数，统计每小时FailedScheduling事件数。突增即告警，可能是某类污点或亲和性配置被批量错误修改。

实操心得：告警消息里，一定要带上kubectl describe pod <pod-name>的Events摘要。运维收到告警，第一眼就能看到失败原因，无需再登录集群查询，平均MTTR（平均修复时间）能缩短70%。

4.6 灾难恢复：当整个调度链路崩溃时，你的Plan B是什么？

最坏情况：调度器全挂，API Server也半死不活，集群无法调度任何新Pod。此时，kubectl apply失败，你急需一个“手术刀”式的手动绑定。

手动绑定（Manual Binding）：这是一个危险但有效的Plan B。你需要构造一个Binding对象，直接告诉API Server“把这个Pod绑到那个节点上”。

cat <<EOF | kubectl create -f - apiVersion: v1 kind: Binding metadata: name: my-app-7d8c9b4d8-abcde namespace: default target: apiVersion: v1 kind: Node name: node-gpu-01 EOF

这会绕过调度器，强制将Pod绑定到node-gpu-01。但风险极大：它不检查资源、不检查taint、不检查亲和性。你必须100%确认该节点有足够资源、无冲突taint、且满足所有硬约束。仅限于紧急恢复，用完即删，并立即修复调度器。

静态Pod（Static Pod）：对于绝对不能宕机的核心组件（如etcd、coredns），将其定义为Static Pod。Static Pod由kubelet直接管理，不经过API Server和调度器。kubelet在节点上监控一个目录（如/etc/kubernetes/manifests），该目录下的yaml文件会自动被创建为Pod。这是K8s自举的基石，也是你的终极保险丝。

5. 常见问题速查表与独家避坑指南

以下是我在上百次调度排障中，整理出的最高频、最易踩、文档里却很少提的“暗坑”。每一个都附带了复现步骤、根本原因和一招制敌的解决方案。

问题现象	复现条件	根本原因	一招制敌方案
Pod Pending，Events里只显示“0/12 nodes are available”，无具体分类	集群有12个Ready节点，但Pod始终Pending	调度器版本过低（<1.18），或启用了已废弃的`--policy-config-file`，导致新版本的预选分类日志未启用	升级调度器到1.18+，并移除`--policy-config-file`参数。用`kubectl version`确认server和client版本一致。
给节点加了taint，但已有Pod被立即驱逐（NoExecute），而它们明明有toleration	`kubectl taint nodes node1 key=value:NoExecute`，且Pod的toleration中`effect: NoExecute`	`tolerationSeconds`未设置，或设置为0。NoExecute污点默认行为是“立即驱逐”	在Pod的toleration中，必须显式添加`tolerationSeconds: 3600`（单位秒）。这是唯一能防止立即驱逐的方法。
NodeAffinity的required规则写了，但Pod还是调度到了不匹配的节点	`nodeAffinity.required`中`operator: In`，`values: ["A100"]`，节点label是`hardware-type=A100`（末尾有空格）	K8s label匹配是严格字符串比较，空格是有效字符	用`kubectl get node <node> -o jsonpath='{.metadata.labels}'`导出label JSON，用`jq`或在线JSON格式化工具检查value末尾是否有空格。修正label：`kubectl label nodes <node> hardware-type=A100 --overwrite`。
PodAntiAffinity设置了，但两个Pod还是在同一个节点上	topologyKey设为`kubernetes.io/hostname`，两个Pod都Pending	两个Pod的`podAntiAffinity`规则，必须在同一个命名空间下定义，且`topologyKey`必须完全一致（包括大小写）	检查两个Pod的yaml，确保`spec.affinity.podAntiAffinity.requiredDuringSchedulingIgnoredDuringExecution.topologyKey`字段值完全相同，且两个Pod在同一namespace。
`kubectl describe node`看不到任何taint，但Pod就是调度不过去	节点`describe`输出中Taints字段为空	该节点被打了`NoSchedule`污点，但`kubectl describe`默认只显示非空taint。`NoSchedule`是默认effect，有时不显式打印	用`kubectl get node <node-name> -o jsonpath='{.spec.taints}'`。JSON输出会显示所有taint，包括effect为`NoSchedule`的。这才是真相。
调度器日志里出现`no fit: node xxx is not ready`，但`kubectl get nodes`显示Ready	`kubectl get nodes`输出STATUS为Ready	`kubectl get nodes`的Ready状态，是基于`NodeReady`condition。但调度器的`CheckNodeCondition`预选函数，还检查`DiskPressure`、`MemoryPressure`、`PIDPressure`等condition。如果其中任何一个为True，调度器会认为节点“not ready”	`kubectl describe node <node-name>`，在Conditions部分，查找`DiskPressure=True`等。清理节点磁盘或内存，或调整Kubelet的`--eviction-hard`参数。

5.1 一个真实案例：从“集群瘫痪”到“5分钟恢复”的全过程

某天凌晨，监控告警：kube_scheduler_pending_pods > 50。值班同事尝试kubectl describe pod，Events里全是“0/12 nodes are available”，但没分类。他按常规流程检查了节点taint、label，一切正常。时间一分一秒过去，Pending Pod数涨到200+，新服务无法上线。

我接手后，执行了五步法：

Events：确认是“0/12”，无分类。
Nodes：kubectl get nodes显示12个Ready，但kubectl get nodes -o wide发现其中3个节点的ROLES列是空的（不是<none>，是真正的空）。
Deep Dive：kubectl describe node <empty-role-node>，在Labels部分，赫然发现node-role.kubernetes.io/master=（value为空字符串）。这是K8s 1.20的一个已知bug，某些节点注册时，master role label的value被错误设为空。
Root Cause：调度器的CheckNodeCondition预选函数，在检查node-role.kubernetes.io/master这个taint时，会尝试匹配value=""，但Pod的toleration中value是""（空字符串），而K8s内部处理空字符串taint有bug，导致匹配失败，所有节点都被淘汰。
Fix：kubectl taint nodes <empty-role-node> node-role.kubernetes.io/master:NoSchedule-（减号表示删除）。对3个节点执行后，`