K8s节点维护三剑客：Cordon、Drain、Delete的实战场景与选择策略

1. 理解K8s节点维护的核心需求

当你管理一个Kubernetes集群时，节点维护是绕不开的日常工作。想象一下，这就像管理一支足球队——有时候你需要让某个球员暂时休息（节点升级），有时候球员受伤需要治疗（硬件故障），还有些时候球队需要精简人员（集群缩容）。这时候，你就需要三把"瑞士军刀"：cordon、drain和delete。

我刚开始接触K8s时，经常搞混这三个命令。直到有一次线上事故，因为用错了命令导致服务中断，才真正明白它们的区别。简单来说：

• cordon：就像给节点贴个"请勿打扰"的标签，新来的Pod不会分配到这里，但现有的Pod照常工作
• drain：更礼貌的"请离开"，会优雅地迁移现有Pod到其他节点
• delete：直接"开除"，节点从集群中彻底消失

选择哪个命令，取决于你的维护目标：

1. 无损隔离（cordon）：临时性维护，比如安全检查
2. 优雅驱逐（drain）：计划性维护，比如内核升级
3. 永久移除（delete）：节点退役或硬件报废

2. cordon：最温和的隔离手段

2.1 适用场景与实操

上周我们集群有个节点需要安装安全补丁，我就用了cordon。这个命令特别适合：

• 短期维护（<30分钟）
• 不需要重启节点的操作
• 测试新节点稳定性时隔离观察

实际操作很简单：

bash复制# 查看当前节点状态
kubectl get nodes

# 隔离节点
kubectl cordon node-01

# 验证状态
kubectl describe node node-01 | grep -i schedul

你会看到SchedulingDisabled: true的标记。这时候新创建的Pod会自动避开这个节点，但原有的Pod纹丝不动。

2.2 常见误区

新手容易犯两个错误：

1. 以为cordon能迁移Pod：实际上它只阻止新调度，不会影响已有Pod
2. 忘记恢复调度：维护完成后一定要执行：

bash复制kubectl uncordon node-01

我有个同事曾经cordon了一个节点后忘记uncordon，三天后那个节点还处于隔离状态，导致集群资源利用率不均。

3. drain：优雅驱逐的艺术

3.1 完整操作流程

drain是我用得最多的命令，特别是在这些场景：

• 节点操作系统升级
• 硬件更换
• 集群重新平衡负载

完整流程应该是：

bash复制# 1. 先cordon（安全起见）
kubectl cordon node-02

# 2. 驱逐Pod（带保护参数）
kubectl drain node-02 \
  --ignore-daemonsets \
  --delete-local-data \
  --force \
  --timeout=300s

# 3. 执行维护操作
# ...你的维护脚本...

# 4. 恢复节点
kubectl uncordon node-02

3.2 参数详解

这几个参数必须掌握：

• --ignore-daemonsets：忽略DaemonSet管理的Pod（如kube-proxy）
• --delete-local-data：删除使用emptyDir的Pod
• --force：强制驱逐不由控制器管理的Pod
• --timeout：设置等待时间（单位秒）

去年我们升级内核时就遇到个坑：没加--timeout参数，结果有些Pod终止超时，导致drain卡住。后来发现是某个Java应用关闭时需要30秒完成事务处理。

3.3 驱逐过程解析

drain的实际工作流程是这样的：

1. 将节点标记为不可调度（相当于自动执行cordon）
2. 根据PodDisruptionBudget(PDB)配置，按顺序优雅终止Pod
3. 等待Pod在其他节点重新启动并健康
4. 如果遇到无法驱逐的Pod，根据参数决定是否强制驱逐

4. delete：彻底删除节点

4.1 使用场景与风险

delete是三个命令中最"暴力"的，适用于：

• 永久移除云主机
• 节点硬件报废
• 故障节点强制剔除

它的操作流程：

bash复制# 1. 驱逐Pod（建议先drain）
kubectl drain node-03 --force --ignore-daemonsets

# 2. 从集群删除节点
kubectl delete node node-03

# 3. 在节点机器上清理（如果需要重新加入）
kubeadm reset

4.2 注意事项

1. 数据丢失风险：如果Pod使用本地存储，数据可能永久丢失
2. 服务中断：没有优雅终止期，可能影响用户体验
3. 重新加入麻烦：需要重新配置和加入集群

上个月我们有个物理服务器硬盘故障，被迫使用delete。结果发现那个节点上运行的MySQL Pod使用了本地PV，导致数据无法恢复。后来我们改用了网络存储。

5. 决策流程图与避坑指南

5.1 命令选择决策树

根据我的经验，可以按这个流程选择：

code复制是否需要永久移除节点？
├─ 是 → 使用delete
└─ 否 → 是否需要迁移现有Pod？
   ├─ 是 → 使用drain
   └─ 否 → 使用cordon

5.2 常见问题解决方案

问题1：drain卡住不动

• 检查是否有PDB限制
• 查看Pod事件：kubectl describe pod <pod-name>
• 适当增加--timeout值

问题2：delete后节点自动重新加入

• 在节点执行：systemctl stop kubelet
• 清理残留配置：rm -rf /etc/kubernetes/

问题3：cordon后仍有Pod被调度

• 检查是否有nodeSelector硬性指定
• 查看调度器日志：kubectl logs -n kube-system <scheduler-pod>

6. 实战场景分析

6.1 节点升级案例

上周我们给集群的20个节点升级Docker版本，完整流程是：

1. 批量cordon所有节点（防止意外调度）
2. 逐个节点执行：

   bash复制kubectl drain <node> --ignore-daemonsets
   apt-get upgrade docker-ce
   reboot
   kubectl uncordon <node>
   

3. 验证服务状态

整个过程零停机，关键是要控制好滚动升级的批次间隔。

6.2 硬件故障处理

当遇到硬件故障时：

1. 立即cordon故障节点
2. 尝试drain（如果节点还能响应）
3. 如果无法drain，直接delete
4. 准备新节点加入集群

6.3 集群缩容技巧

在云环境下自动缩容时：

• 先drain节点
• 等待5分钟确认所有Pod已迁移
• 再调用云API删除虚拟机
• 最后执行kubectl delete node

这样能确保服务不中断。