Kubespray集群升级中kubeadm健康检查失败问题分析

问题背景

在使用Kubespray进行Kubernetes集群升级时，特别是在从1.30.8版本升级到1.31.4版本的过程中，部分用户遇到了控制平面节点升级失败的问题。该问题表现为第二个控制平面节点升级时，kubeadm的升级前健康检查(upgrade-health-check)作业未能按时完成，导致整个升级过程中断。

问题现象

升级过程中，当第一个控制平面节点成功升级后，第二个控制平面节点执行kubeadm upgrade apply命令时会失败，并显示以下关键错误信息：

[upgrade/health] FATAL: [preflight] Some fatal errors occurred:
[ERROR CreateJob]: Job "upgrade-health-check-rcfkg" in the namespace "kube-system" did not complete in 15s: no condition of type Complete

经过深入分析发现，这个问题具有以下特征：

1. 仅当kube-controller-manager组件已经升级到新版本(v1.31.4)时才会出现
2. 当kube-controller-manager仍运行旧版本(v1.30.8)时，健康检查作业能够正常完成
3. 问题在集群使用VIP(虚拟IP)作为API服务器端点时更容易复现

技术分析

kubeadm升级机制

Kubernetes集群升级过程中，kubeadm采用了分阶段的安全升级策略：

1. 对于第一个控制平面节点，使用kubeadm upgrade apply命令执行完整升级
2. 对于后续控制平面节点，理论上应该使用kubeadm upgrade node命令进行升级

问题根源

Kubespray当前实现中存在一个关键设计问题：它对所有控制平面节点都使用了kubeadm upgrade apply命令。根据Kubernetes官方文档，这实际上是不正确的做法，因为：

1. kubeadm upgrade apply会执行严格的预检健康检查
2. 这些健康检查在部分升级完成的集群环境中可能无法通过
3. 正确的做法是后续节点使用kubeadm upgrade node命令，该命令不会执行预检检查

健康检查超时机制

upgrade-health-check作业设计为在15秒内完成，但在以下情况下可能超时：

1. 集群组件版本混合状态下的协调延迟
2. 网络延迟或API服务器响应变慢
3. 控制器管理器版本升级后的短暂不稳定期

解决方案

Kubespray项目已经通过PR#12015修复了这个问题，主要改进包括：

1. 正确区分首个控制平面节点和后续节点的升级命令
2. 对后续控制平面节点使用kubeadm upgrade node命令
3. 移除了不必要的健康检查环节

最佳实践建议

对于需要进行Kubernetes集群升级的用户，建议：

1. 确保使用最新版本的Kubespray进行升级操作
2. 对于大型集群，适当增加健康检查超时时间
3. 在升级前做好完整的集群状态备份
4. 考虑分批次升级控制平面节点，降低风险

总结

Kubernetes集群升级是一个复杂的过程，工具链的正确使用至关重要。Kubespray通过修复这个问题，进一步提高了集群升级的可靠性和成功率。用户应当理解不同升级命令的适用场景，并遵循工具的最佳实践指南，以确保升级过程顺利完成。