集群升级生命周期：升级前的评估、升级中的风险、升级后的验证、回滚策略
集群升级并非单一的技术操作，而是一个包含评估、执行、验证与兜底的全流程治理过程。本章围绕升级生命周期中的四个核心阶段展开，重点阐述每个阶段的关键活动、风险控制点以及可量化的判断标准，为后续的 API 迁移与灰度验证奠定基础。
2.1 升级前评估：风险识别与准入清单
升级前的评估是决定升级是否启动的“闸门”。评估不充分，后续所有环节都将面临不可控的连锁风险。评估工作应覆盖以下四个维度：
| 评估维度 | 核心检查项 | 通过标准 |
|---|---|---|
| 版本兼容性 | Kubernetes API 弃用清单、CRD 版本、Webhook 转换 | 目标版本无已弃用 API，CRD 存储版本与目标版本一致 |
| 组件健康度 | etcd 健康、CoreDNS 延迟、kubelet 证书有效期 | etcd 端到端延迟 < 10ms，证书剩余 > 30 天 |
| 工作负载就绪 | PodDisruptionBudget、HPA 配置、存储挂载状态 | 所有关键工作负载 PDB 已配置，HPA 指标正常 |
| 备份与快照 | etcd 全量备份、持久卷快照、集群配置导出 | 备份文件校验通过，快照可独立恢复 |
实践建议： 在评估阶段引入
kubent（Kubernetes 弃用 API 检测工具）和 kube-score 进行自动化扫描，将人工检查项转化为 CI 流水线中的准入 Gate。评估结果应生成一份 升级准入报告，由 SRE 与 API 治理负责人共同签字确认。
2.2 升级中的风险：实时监控与熔断机制
升级执行阶段是风险暴露最集中的窗口。控制面组件升级、节点池滚动、API Server 版本切换等操作均可能引发服务中断或数据面异常。以下是升级过程中需要重点关注的三大风险域：
- 控制面风险： API Server 版本切换导致客户端请求失败、etcd 领导者选举超时、调度器与控制器管理器版本不匹配。
- 数据面风险： kubelet 升级后节点状态异常、CNI 插件兼容性断裂、Pod 因 PDB 限制无法驱逐导致升级卡死。
- API 兼容性风险： 旧版客户端调用已弃用 API、Webhook 转换失败、自定义控制器无法处理新版本资源字段。
关键熔断指标： 在升级过程中，若以下任一指标触发阈值，应立即暂停升级并执行回滚：
· API Server 错误率 > 5%（5xx 响应）
· etcd 写入延迟 > 50ms 持续 30 秒
· 不可用节点数 > 集群总节点数的 10%
· 关键工作负载（如 ingress-controller、coredns）Pod 重启次数 > 3 次/分钟
· API Server 错误率 > 5%（5xx 响应）
· etcd 写入延迟 > 50ms 持续 30 秒
· 不可用节点数 > 集群总节点数的 10%
· 关键工作负载（如 ingress-controller、coredns）Pod 重启次数 > 3 次/分钟
2.3 升级后验证：多维度健康检查清单
升级完成后，不能仅凭节点状态 Ready 就判定成功。必须从控制面、数据面、业务面三个层次进行系统性验证，确保集群功能完整且性能未退化。
2.3.1 控制面验证
- 所有控制面组件（kube-apiserver、kube-controller-manager、kube-scheduler）版本与目标版本一致。
- etcd 集群成员健康，端到端延迟 < 10ms，无 leader 切换事件。
- 所有 Webhook 配置（Mutating / Validating）在新版本下正常响应。
2.3.2 数据面验证
- 所有节点 kubelet 版本一致，节点状态 Ready，磁盘与内存压力正常。
- CNI 插件（Calico / Cilium）Pod 运行正常，Pod 间网络连通性测试通过。
- CSI 驱动正常工作，PV 挂载与卸载操作无超时。
2.3.3 业务面验证
- 核心工作负载（Deployment / StatefulSet）副本数正常，无 CrashLoopBackOff。
- Ingress / Service 流量可达，HTTP 状态码 200 占比 > 99.9%。
- 自定义控制器与 Operator 能够正常调谐资源，无 API 调用错误。
验证自动化脚本示例（kubeconform + 自定义检查）：
#!/bin/bash
# 升级后验证脚本片段
echo "=== 控制面版本检查 ==="
kubectl version --short | grep -E "Server|Client"
echo "=== etcd 健康检查 ==="
kubectl exec -n kube-system etcd-$(hostname) -- etcdctl endpoint health
echo "=== 节点状态检查 ==="
kubectl get nodes | awk '{if($2!="Ready") print "WARN: " $0}'
echo "=== 关键工作负载检查 ==="
kubectl get pods -n kube-system -o wide | grep -E "coredns|kube-proxy|calico"2.4 回滚策略：快速恢复与数据一致性保障
回滚是升级生命周期的最后一道防线。一个可执行的回滚策略必须满足以下条件：可重复、可验证、有时效性。回滚操作应尽可能自动化，减少人工介入带来的二次风险。
| 回滚场景 | 回滚方式 | 预期耗时 | 数据一致性保障 |
|---|---|---|---|
| 控制面升级失败 | 从 etcd 备份恢复 + 重新部署旧版本控制面组件 | 15-30 分钟 | etcd 全量备份确保数据不丢失 |
| 节点池升级异常 | 回退节点镜像版本，重新加入集群 | 5-10 分钟/节点 | 节点本地数据通过 PV 快照恢复 |
| API 兼容性问题 | 回滚 API Server 版本，保留旧版 API 注册表 | 10-15 分钟 | 通过 API 转换 Webhook 保持数据格式兼容 |
| 业务工作负载异常 | 回滚 Deployment 至上一版本镜像 + 配置 | 2-5 分钟 | Kubernetes 原生回滚机制保留历史版本 |
回滚执行原则：
1. 先恢复，后排查： 回滚的首要目标是恢复服务，根因分析应在服务恢复后进行。
2. 保留现场： 回滚前必须保存当前集群状态快照（etcd 快照 + 资源清单导出），用于事后复盘。
3. 灰度回滚： 对于大规模集群，优先对异常节点池或区域执行回滚，避免全局回滚影响正常业务。
4. 回滚验证： 回滚完成后，必须重新执行 2.3 节中的验证清单，确认集群已恢复至升级前状态。
1. 先恢复，后排查： 回滚的首要目标是恢复服务，根因分析应在服务恢复后进行。
2. 保留现场： 回滚前必须保存当前集群状态快照（etcd 快照 + 资源清单导出），用于事后复盘。
3. 灰度回滚： 对于大规模集群，优先对异常节点池或区域执行回滚，避免全局回滚影响正常业务。
4. 回滚验证： 回滚完成后，必须重新执行 2.3 节中的验证清单，确认集群已恢复至升级前状态。
2.5 生命周期总结：从评估到回滚的闭环
集群升级生命周期是一个完整的闭环流程。评估阶段提供决策依据，执行阶段依赖实时监控与熔断，验证阶段确认升级质量，回滚策略兜底异常情况。四个阶段相互衔接，缺一不可。