概述
Kubernetes 升级分为风险不同的两部分：控制面获得新 API 并移除旧 API；节点运行 kubelet 与容器运行时。仍调用被移除 API 的客户端会一直正常，直到 apiserver 不再提供该版本，随后返回 404 或 410。这类故障常出现在负责调谐旧清单的控制器里，而不是应用本身，因此必须先做 API 盘点。版本偏差策略允许节点落后控制面一个小版本，这正是分阶段升级的基础。
步骤
- 找出仍在使用废弃 API 的工作负载：
kubectl get --raw /metrics | grep apiserver_requested_deprecated_apis- 检查节点与控制面的版本偏差：
kubectl version -o yaml- 先升级控制面：
gcloud container clusters upgrade payments-prod \
--master --cluster-version 1.30- 升级一个金丝雀节点池并确认工作负载健康：
gcloud container node-pools upgrade canary \
--cluster payments-prod --node-pool-version 1.30
kubectl get nodes -L cloud.google.com/gke-nodepool- 升级后检查是否出现 410 响应：
kubectl get --raw /metrics | grep 'apiserver_request_total{code="410"' | head验证
每一步之间都应确认 Pod 处于 Ready，且 CNI、CSI、Ingress 等附加组件仍正常工作。kubectl version 应满足偏差策略，金丝雀节点应报告新的 kubelet 版本。升级后执行一次真实的 Deployment 发布与 Service 变更，因为只读检查无法发现准入与调度问题。旧节点池在新节点池承载流量满一天后再删除，以便必要时回退。
注意事项
- 托管控制面升级不可回滚，节点池可以替换但不能降级控制面。
- 附加组件应先升级到支持目标小版本，再升级节点。
- 跨多个小版本升级时必须逐个小版本执行，不能跳跃。
- 410 响应需要在升级后持续观察一段时间，而不是只看当次发布。
- 集群落后三个小版本后将失去受支持的升级路径，应记录下次升级时间。