Kubernetes 集群升级策略：控制风险、验证兼容、平滑迁移

Kubernetes 升级是平台团队绕不开的工作。长期不升级会带来安全补丁缺失、云厂商支持窗口收缩、插件兼容性下降和 API 废弃风险。但升级本身也有风险：控制面变更、节点重启、CNI 插件不兼容、Admission 策略变化、应用使用了废弃 API。

一次成熟的升级，不是“点一下升级按钮”，而是从资产盘点、兼容性扫描、测试环境演练、分批节点替换、业务验证到事故回滚的一整套流程。

升级前盘点

首先确认当前集群真实状态：

• Kubernetes 版本和目标版本。
• 节点操作系统和容器运行时。
• CNI、CSI、Ingress Controller、CoreDNS、metrics-server、监控日志组件版本。
• CRD 和 Operator 清单。
• 业务使用的 API 版本。
• PodDisruptionBudget、HPA、Webhook、Admission 策略。

最容易被忽略的是 CRD 和 Webhook。很多集群升级失败或业务发布异常，不是 Kubernetes 核心组件问题，而是第三方 Operator、准入 Webhook 或老 CRD 不兼容。

API 废弃检查

K8s 会在版本演进中废弃旧 API。升级前应扫描所有 YAML、Helm Chart、GitOps 仓库和集群内资源，找出废弃 API。例如老版本的 Ingress、PodSecurityPolicy、CronJob、HorizontalPodAutoscaler 等都经历过 API 迁移。

建议建立自动检查：

kubectl api-resources
kubectl get --raw /metrics | grep apiserver_requested_deprecated_apis

也可以使用专门工具扫描 manifest。重点不是工具名称，而是把检查纳入升级流程，避免升级当天才发现资源无法创建。

控制面与数据面

升级通常分为控制面升级和节点升级。托管 Kubernetes 会简化控制面操作，但节点池仍然需要滚动替换或升级。

控制面升级前要确认：

• etcd 备份或云厂商恢复能力。
• API Server 可用性 SLA。
• 管理入口和审计日志正常。
• 核心插件支持目标版本。

节点升级前要确认：

• 每个节点池的业务类型。
• PodDisruptionBudget 是否阻止驱逐。
• DaemonSet 是否能在新节点正常运行。
• 镜像拉取速度和镜像缓存策略。
• 节点最大 Pod 数和 IP 容量。

先升级测试集群

测试集群必须尽量接近生产。至少应包含相同的 CNI、CSI、Ingress、监控、日志、核心 Operator 和一组典型业务。只升级一个空集群没有太大验证价值。

测试内容包括：

• 应用能否正常部署。
• HPA 是否正常获取指标。
• Ingress 路由和证书是否正常。
• PVC 创建、挂载、扩容是否正常。
• NetworkPolicy 是否仍然生效。
• 日志和指标是否继续采集。
• GitOps 或 CI/CD 是否能发布。

测试环境通过后，再进入生产灰度。

生产灰度策略

生产升级建议按节点池分批。先升级低风险节点池，例如 dev、batch 或非核心业务。观察一段时间后，再升级在线业务节点池。最后处理核心服务或有状态服务节点池。

对在线业务，升级节点通常意味着驱逐 Pod 到其他节点。需要提前确认 PodDisruptionBudget、readinessProbe 和副本数。单副本服务在节点升级时必然有中断风险，应先改造为多副本或安排维护窗口。

有状态服务要更谨慎。节点升级前应确认数据副本健康、主从状态正常、备份可用，并逐个节点处理。

插件升级顺序

插件升级顺序要按依赖关系安排。一般来说：

1. 先确认目标 K8s 版本支持的 CNI、CSI、Ingress、监控组件版本。
2. 升级不兼容的插件到过渡版本。
3. 升级控制面。
4. 升级节点。
5. 再升级到目标插件版本。

不要在同一窗口里同时升级太多关键组件。否则一旦出问题，很难判断根因来自 K8s、CNI、Ingress 还是应用。

Webhook 风险

MutatingWebhook 和 ValidatingWebhook 会拦截资源创建和更新。如果 Webhook 服务不可用，可能导致业务发布失败。升级期间要重点检查：

• Webhook 服务是否高可用。
• failurePolicy 是 Fail 还是 Ignore。
• 证书是否有效。
• Webhook 是否支持新 API。

对非关键策略，可以在升级窗口临时调整为更宽松模式，但要记录并在升级后恢复。

回滚与恢复

控制面升级的回滚能力取决于部署方式和云厂商能力。节点升级回滚通常通过保留旧节点池实现。生产中建议使用“新建节点池替换旧节点池”的方式，而不是原地升级所有节点。

这样做的好处是：

• 可以让少量业务先调度到新节点验证。
• 出问题时可以 cordon 新节点，把 Pod 调回旧节点。
• 节点镜像、运行时和 kubelet 配置更容易保持一致。

回滚预案要写清楚触发条件，例如核心接口错误率升高、Pod 大面积 CrashLoop、CNI 异常、Ingress 5xx 持续上升。

升级后的验证

升级完成后，不要立刻宣布结束。至少验证：

• 节点全部 Ready。
• 系统 DaemonSet 全部可用。
• CoreDNS、Ingress、CNI、CSI 无异常日志。
• 关键业务 SLO 正常。
• 告警系统正常。
• 新建 Deployment、Service、Ingress、PVC 均成功。
• 废弃 API 指标归零或符合预期。

同时清理临时兼容配置，更新集群基线文档。

总结

Kubernetes 升级的难点不是命令，而是风险编排。真正可靠的升级流程会把兼容性、插件、业务验证、节点替换和回滚预案拆解清楚。升级不是一次性事件，而是平台生命周期管理的一部分。频繁、小步、可验证的升级，通常比多年不动后一次大跨越安全得多。