运维实战：K8s节点维护，用cordon、drain还是delete？一张图帮你做决策

Kubernetes节点维护决策指南：cordon、drain与delete的深度实践

在Kubernetes集群的日常运维中，节点维护是每个工程师都无法回避的挑战。无论是计划内的内核升级、硬件更换，还是应对突发的节点故障，如何优雅地处理节点下线与恢复，直接关系到服务的稳定性和运维效率。本文将深入剖析三种核心操作——cordon、drain和delete的适用场景、操作细节与风险控制，帮助您在复杂环境中做出最优决策。

1. 节点维护操作的核心概念解析

Kubernetes提供了三种不同层级的节点管理操作，每种操作都有其特定的使用场景和影响范围。理解它们的本质区别是做出正确决策的基础。

1.1 cordon：最温和的调度隔离

cordon操作的核心作用是将节点标记为不可调度（SchedulingDisabled），其特点包括：

• 最小影响：仅阻止新Pod被调度到该节点，不影响现有Pod运行
• 可逆性强：通过uncordon可立即恢复节点调度能力
• 典型场景：
  • 节点预维护检查阶段
  • 临时隔离问题节点进行诊断
  • 资源预留场景

# 标记节点为不可调度 kubectl cordon <node-name> # 恢复节点调度能力 kubectl uncordon <node-name>

注意：cordon不会自动处理节点上的现有Pod，如果这些Pod存在异常，仍需人工介入处理

1.2 drain：安全的Pod驱逐机制

drain操作是节点维护中最常用的命令，它实现了"先疏散，后维护"的安全流程：

1. 自动执行cordon操作，阻止新Pod调度
2. 优雅驱逐现有Pod（遵循PodDisruptionBudget）
3. 等待Pod在其他节点重新创建并就绪

关键参数说明：

# 完整的安全驱逐命令示例 kubectl drain <node-name> \ --ignore-daemonsets \ --delete-local-data \ --force \ --timeout=300s

1.3 delete：彻底的节点移除

delete是最激进的操作，不仅驱逐Pod，还会从集群中完全移除节点：

1. 驱逐节点上所有Pod（类似drain）
2. 从API Server中删除节点对象
3. 需要节点重新注册才能恢复

恢复流程更为复杂：

# 在节点上重启kubelet服务 systemctl restart kubelet # 观察节点自动注册过程 kubectl get nodes -w

2. 决策流程图：什么情况下使用哪种操作？

根据维护类型、紧急程度和恢复需求，我们可以建立以下决策模型：

开始 │ ├─ 是否需要永久移除节点？ → 是 → 使用delete │ ├─ 是否紧急故障处理？ → 是 → 使用drain --force │ ├─ 是否需要保留现有Pod？ → 是 → 使用cordon │ └─ 计划内维护 → 使用标准drain流程

2.1 内核升级场景操作流程

1. 准备阶段：

   # 先标记节点不可调度 kubectl cordon node-01 # 检查Pod状态，确保无关键业务受影响 kubectl get pods -o wide --field-selector spec.nodeName=node-01

2. 驱逐Pod：

   # 优雅驱逐Pod，给予5分钟过渡时间 kubectl drain node-01 \ --ignore-daemonsets \ --timeout=300s

3. 执行升级：

   # 通过SSH连接到节点 ssh node-01 # 执行实际升级操作 sudo apt update && sudo apt upgrade -y linux-image-generic

4. 恢复服务：

   # 重启节点后恢复调度 kubectl uncordon node-01

2.2 硬件故障应急处理

对于突发硬件故障，需要更果断的措施：

# 强制快速驱逐，不考虑优雅终止 kubectl drain <故障节点> \ --force \ --grace-period=0 \ --ignore-daemonsets \ --delete-local-data

警告：强制驱逐可能导致短暂服务中断，确保应用有足够的副本冗余

3. 高级场景与风险控制

3.1 有状态应用的特别考量

当节点运行有状态工作负载时，需要额外注意：

• StatefulSet Pod：确保按正确顺序重建
• 本地存储数据：提前做好数据备份
• 持久卷：确认StorageClass配置正确

# 检查Pod使用的存储类型 kubectl describe pod <pod-name> | grep -A5 Volumes

3.2 PodDisruptionBudget的最佳实践

PDB是确保服务可用性的关键防线，建议配置：

apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: zk-pdb spec: minAvailable: 2 selector: matchLabels: app: zookeeper

关键参数对照：

3.3 大规模集群的批量操作策略

当需要维护多个节点时，建议采用：

1. 分批次操作：每次只维护部分节点
2. 滚动策略：等待一批节点恢复后再继续
3. 自动化脚本：

#!/bin/bash nodes=("node-{1..5}") for node in "${nodes[@]}"; do kubectl drain "$node" \ --ignore-daemonsets \ --delete-local-data \ --timeout=600s # 执行维护操作... kubectl uncordon "$node" sleep 300 # 等待集群稳定 done

4. 常见问题排查与恢复技巧

4.1 drain操作卡住怎么办？

典型原因及解决方案：

• DaemonSet Pod阻塞：添加--ignore-daemonsets
• 本地存储Pod：添加--delete-local-data
• Pod无法重建：检查副本控制器配置
• 资源不足：检查集群剩余资源

# 查看阻塞原因 kubectl get pods --field-selector spec.nodeName=<node-name>

4.2 节点无法恢复调度排查步骤

1. 检查节点状态：

   kubectl describe node <node-name>

2. 验证kubelet日志：

   journalctl -u kubelet -n 50 --no-pager

3. 检查网络连接：

   kubectl run -it --rm debug-tools --image=nicolaka/netshoot

4.3 关键指标监控建议

在节点维护期间应监控：

• Pod重建成功率：kube_pod_status_ready
• 节点不可用时间：kube_node_spec_unschedulable
• 资源水位：node_memory_MemAvailable_bytes

# 使用kubectl查看资源使用情况 kubectl top nodes

5. 决策因素权重分析

不同场景下，决策标准应有不同侧重：

实际项目中，我通常会先使用cordon进行"软隔离"观察效果，确认无异常后再执行drain。对于已知的硬件故障节点，直接使用delete可以更快释放资源。记住，任何维护操作前，做好完整的etcd备份是最后的保障。