Kubernetes kubeadm 单控制平面节点升级健康检查问题解析

在 Kubernetes 集群管理工具 kubeadm 的 v1.30.0 版本中，用户在执行单控制平面节点升级时发现了一个关键问题：当节点被排空（drain）后，升级过程中创建的健康检查任务（upgrade-health-check Job）会失败。本文将深入分析该问题的技术背景、影响范围及解决方案。

---

问题现象

当用户在单控制平面节点的 Kubernetes 集群（v1.29.1）上执行以下操作序列时：

1. 排空唯一的控制平面节点
2. 执行 kubeadm upgrade apply v1.30.0 命令

系统会报错：

[ERROR CreateJob]: Job "upgrade-health-check-lvr8s" 在命名空间 "kube-system" 中未在15秒内完成

技术背景

健康检查机制

kubeadm 在升级过程中会创建一个临时 Job 来验证集群是否能够接受新工作负载。这个设计初衷是为了确保：

• 控制平面组件健康
• 调度器能够正常分配 Pod
• 网络插件正常工作

问题根源

在单节点场景下，当唯一节点被排空时：

1. 节点会被标记为不可调度（Unschedulable）
2. 健康检查 Job 创建的 Pod 因节点不可调度而处于 Pending 状态
3. 超时机制触发错误（原15秒超时设计）

在 v1.29 版本中，该错误会被 defer 语句中的删除操作覆盖，而 v1.30 版本由于错误处理逻辑变更导致问题暴露。

---

影响分析

受影响场景

• 单控制平面节点集群
• 执行节点排空后升级
• 使用 kubeadm v1.30.0 版本

潜在风险

虽然升级过程最终会完成（通过 --ignore-preflight-errors=CreateJob 可绕过），但缺少健康检查可能掩盖真实的集群问题。

---

解决方案

Kubernetes 社区通过两种方式解决了该问题：

1. 智能跳过机制（v1.30.1 修复）

在 PR #124570 中实现了：

• 检测单控制平面节点场景
• 自动跳过健康检查 Job 创建
• 记录警告日志而非报错

2. 容忍度方案（设计讨论）

曾考虑为 Job 添加容忍度：

tolerations:
- key: node.kubernetes.io/unschedulable
  effect: NoSchedule

但该方案被否决，原因在于：

• 违反节点排空的设计原则
• 可能导致非预期调度行为

---

最佳实践建议

对于运维人员的建议：

1. 单节点集群升级时：

   • 直接升级到包含修复的 v1.30.1+ 版本
   • 或使用 --ignore-preflight-errors=CreateJob 参数

2. 生产环境多节点集群：

   • 仍建议保留健康检查机制
   • 确保至少有一个可调度节点

3. 升级前检查：

kubectl get nodes -o jsonpath='{.items[*].spec.unschedulable}' | grep true

---

架构思考

该问题反映出分布式系统管理工具在单节点场景下的特殊处理需求。kubeadm 作为集群生命周期管理工具，需要在以下维度保持平衡：

• 通用性 vs 特殊场景处理
• 安全检查严格性 vs 用户体验
• 自动化程度 vs 可预测性

未来版本可能会进一步优化健康检查策略，例如：

• 动态评估集群拓扑
• 分级检查机制
• 更智能的超时配置

通过这个案例，开发者可以更深入理解 Kubernetes 调度系统与控制平面组件的交互机制。