Calico升级至v3.28.0+版本时kube-controller-manager的重启问题解析

背景说明

在Calico从v3.26升级到v3.29.2的过程中，v3.28.0版本引入了一个重要的架构变更：projectcalico.org/v3资源的UID生成机制发生了改变。这项变更是为了解决Kubernetes垃圾回收机制可能遇到的重复UID问题（PR#8586）。

变更影响分析

核心变更点在于：

1. UID生成算法调整后，现有资源的UID会发生变化
2. 所有管理projectcalico.org/v3资源的控制器（包括kube-controller-manager）都需要在升级后重启

AWS EKS环境下的特殊考量

在托管Kubernetes服务如AWS EKS中：

• 用户无法直接控制kube-controller-manager等控制平面组件的生命周期
• 这些组件通常会在EKS集群版本升级时自动重启

实际升级建议

对于无法立即重启控制平面组件的情况：

1. 风险等级评估：该变更主要影响资源引用关系，不会导致服务中断
2. 临时解决方案：可以等待下一次EKS自动升级完成控制器重启
3. 监控建议：升级后观察垃圾回收日志，确认无异常资源清理行为

最佳实践

1. 对于自建集群：按照标准流程滚动重启控制平面组件
2. 对于托管服务：
   • 规划在维护窗口期执行Calico升级
   • 考虑协调Calico升级与EKS版本更新
3. 所有环境都应：
   • 提前备份Calico资源配置
   • 验证升级后的网络策略有效性

注：该变更虽然涉及底层机制，但经过充分测试验证，实际业务影响可控。团队可根据自身运维能力选择适当的升级策略。