2. 集群升级基础：Kubernetes版本演进策略、升级路径规划、升级前的风险评估、回滚机制设计

2.1 Kubernetes版本演进策略

Kubernetes社区采用3次发布/年的节奏，每个版本约持续14个月的支持窗口。理解版本生命周期是制定升级策略的前提。

2.2 升级路径规划

Kubernetes官方要求次版本升级不能跳过（例如从v1.27→v1.29不允许，必须经过v1.28）。升级路径规划需遵循以下原则：

• 逐版本升级：每次只升级一个次版本（如v1.27→v1.28→v1.29）。
• 控制平面优先：先升级master节点，再升级worker节点。
• 节点池滚动：每次只升级一个节点，观察稳定后再继续。
• 组件兼容性检查：确保kube-apiserver版本 ≥ kube-controller-manager/kube-scheduler ≥ kubelet ≥ kube-proxy。

以下SVG图展示了从v1.27到v1.30的完整升级路径与节点状态变化：

2.3 升级前的风险评估

升级前必须完成以下7项风险评估，每一项都可能成为升级阻塞项：

2.4 回滚机制设计

回滚是升级计划的安，必须在升级开始前设计并验证。回滚策略分为三个层级：

2.4.1 控制平面回滚

• etcd快照恢复：升级前对etcd做全量快照（etcdctl snapshot save），回滚时恢复快照。
• 二进制版本回退：将kube-apiserver、kube-controller-manager、kube-scheduler二进制文件替换回旧版本。
• kubeadm回滚：使用 kubeadm upgrade revert 命令（kubeadm部署场景）。

2.4.2 Worker节点回滚

• 节点排水取消：如果节点尚未完成排水，执行 kubectl uncordon 恢复调度。
• kubelet版本回退：停止kubelet服务，替换旧版本二进制，重新启动。
• 节点镜像回滚：如果使用节点镜像（如AMI、GCE镜像），回滚到升级前的镜像版本。

2.4.3 全集群回滚

• 条件：仅当控制平面升级后出现严重故障且无法局部修复时使用。
• 步骤：停止所有控制平面组件 → 恢复etcd快照 → 回退所有控制平面二进制 → 回退所有Worker节点 → 验证集群健康。
• 时间预算：全集群回滚通常需要 30-60分钟，需提前通知业务方。

以下SVG图展示了回滚决策流程与各层级触发条件：

2.5 升级前检查清单

以下清单可作为升级前的标准化检查模板，建议团队在每次升级前逐项确认：

1. 版本兼容性确认：目标版本是否在集群所有组件的支持矩阵内。
2. API弃用扫描：运行 kubectl get apiservices 检查已弃用API。
3. etcd备份：执行 etcdctl snapshot save 并验证快照完整性。
4. 节点资源预留：确保有至少20%的节点资源冗余用于升级期间Pod迁移。
5. PDB配置检查：关键应用PDB是否允许至少一个Pod不可用。
6. 监控告警确认：升级期间告警阈值是否已调整（如NodeNotReady告警）。
7. 回滚预案演练：在测试环境验证回滚流程，记录实际耗时。
8. 业务窗口确认：升级时间是否在业务低峰期，是否有变更审批。