真正“无感无损”下线Worker节点需三步：提前校验PDB、资源余量和异常Pod；分批drain（每次1–2节点，间隔≥5分钟）；严格使用带--ignore-daemonsets、--grace-period=60等参数的命令，并完成收尾验证。
直接用 kubectl drain 对大集群 Worker 节点批量下线，不加控制极易引发服务抖动、PDB 触发失败、API Server 压力飙升甚至短暂不可用。真正“无感无损”的核心不是命令本身，而是节奏控制、资源校验和兜底策略的组合落地。
提前校验：三件事必须做完再敲 drain
别跳过这一步——90% 的 drain 卡住或中断都源于准备不足：
-
查 PDB 配置：运行
kubectl get pdb --all-namespaces，确认关键业务设置了minAvailable（比如 2 副本至少留 1 个）或maxUnavailable: 0。没配 PDB 的应用，drain 可能直接驱空全部副本。 -
看节点负载余量：用
kubectl top nodes和kubectl describe node <node-name>检查其他节点 CPU/Mem Allocatable 是否足够承接待迁移 Pod；若剩余资源低于 20%，先扩容或暂缓排空。 -
扫异常 Pod：执行
kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=<node>，重点识别：
– 没控制器管理的孤立 Pod（需--force）
– 使用emptyDir或本地存储的 Pod（需评估数据丢失风险，必要时加--delete-emptydir-data）
– DaemonSet 类型但未加--ignore-daemonsets会直接阻断 drain
分批节奏：一次只动 1–2 个节点，间隔 ≥5 分钟
大集群里同时 drain 多个节点，等于在短时间内向调度器发起大量 Pod 创建请求，etcd 写压力激增，apiserver queue 延迟上升，可能拖慢整个集群响应。实操建议：
- 按可用区（AZ）或机架维度分组，每组最多并行处理 1 个节点；
- 每个 drain 命令后，等
kubectl get pods -A --field-selector spec.nodeName=<node>返回空结果，且新 Pod 全部进入Running状态（用kubectl get events -A --sort-by=.lastTimestamp | tail -20确认无 Pending/Failed 事件）； - 监控面板上观察 5 分钟内服务延迟（如 95% RT）、错误率、Pod 启动成功率是否回归基线——没问题再动下一个。
命令参数要带齐，别信默认值
生产环境禁用裸 kubectl drain <node>。推荐组合参数如下：
-
--ignore-daemonsets：必加，否则 DaemonSet Pod 会卡住整个流程； -
--grace-period=60：设为 60 秒，给应用留足优雅退出时间（比默认 -1 更可控）； -
--timeout=300：超时设为 5 分钟，避免无限等待某个僵死 Pod； -
--delete-emptydir-data：明确接受 emptyDir 数据丢失，防止因该检查中断； -
--force：仅在确认存在孤儿 Pod 且业务可容忍时启用，否则先人工清理。
完整示例：kubectl drain worker-03 --ignore-daemonsets --grace-period=60 --timeout=300 --delete-emptydir-data --dry-run=client -o yaml（先 dry-run 验证逻辑）→ 无误后再去掉 --dry-run 执行。
下线后收尾：不是 uncordon 就完事
节点物理关机或云主机销毁前，务必完成闭环动作：
- 确认所有 Pod 已迁移完毕，原节点上
kubectl get pods -A --field-selector spec.nodeName=xxx为空； - 检查
kubectl get node xxx状态为NotReady或已消失（云环境自动注销）； - 如果后续要重用该节点，记得
kubectl uncordon xxx；若永久下线，无需 uncordon，直接从 IaaS 层回收资源即可； - 最后翻一下 Grafana 中的 Node Disk Pressure、Kubelet PLEG Duration、API Server Request Latency 面板，确认无残留毛刺。
