最可靠方式是立即添加noexecute污点，因其不仅阻止新pod调度，还会驱逐无匹配容忍的现存pod，实现秒级隔离与动态清理；noschedule仅拒新调度，不处理已运行pod，无法满足高危场景下的即时风险切断需求。
在生产环境突发高危情况（如节点资源耗尽、内核异常、磁盘只读、网络分区或安全入侵迹象）时，需秒级阻止新 Pod 调度并隔离问题 Worker 节点——最可靠、最符合 Kubernetes 原生调度逻辑的方式，是立即为其添加 NoExecute 类型的污点。
为什么选 NoExecute 而非 NoSchedule
两者关键区别在于对“已运行 Pod”的处理：
- NoSchedule：仅阻止新 Pod 调度，不影响当前正在运行的 Pod；
- NoExecute：不仅拒绝新调度，还会主动驱逐所有不带匹配容忍的现有 Pod（Deployment/StatefulSet 会自动在其他健康节点重建副本）。
高危场景下，必须快速切断问题节点上的业务流量和潜在风险载体，NoExecute 是唯一能实现“动态锁定+即时清理”的效果。
一键执行的应急命令
发现异常节点（例如 node-worker-07）后，立即执行：
kubectl taint node node-worker-07 emergency=high:NoExecute
说明：
- 键名
emergency清晰标识用途，避免与其他污点混淆； - 值
high可扩展为critical或带时间戳（如20260521T0945Z），便于事后审计； - 效果必须为
NoExecute，这是触发驱逐的前提。
验证与确认动作
执行后两步验证缺一不可：
- 检查污点是否生效：
kubectl describe node node-worker-07 | grep -i taints
应输出类似：Taints: emergency=high:NoExecute - 观察 Pod 状态变化：
kubectl get pods -A -o wide | grep node-worker-07
几分钟内，无容忍的 Pod 应显示Terminating或已消失；对应 Deployment 的READY数应在其他节点恢复。
配套建议：提前准备容忍白名单（可选但推荐）
若节点上运行着必须保留的运维类 Pod（如日志采集 agent、监控探针、SSH 调试容器），应在它们的 Pod 模板中预置容忍：
tolerations: - key: "emergency" operator: "Exists" effect: "NoExecute"
这样即使加了污点，这些关键守护进程也不会被驱逐，保障故障分析链路不断。
