Kubernetes v1.36 发布后怎么升级：从弃用项审计到灰度验证

Kubernetes 官方在 2026 年 4 月 22 日发布了 v1.36，版本代号为 Haru。官方发布信息显示，这个版本包含 70 项增强，其中一部分进入 Stable，一部分进入 Beta 和 Alpha。对于业务团队来说，真正的问题不是“要不要马上升级”，而是“怎么把升级风险拆开看”。

本文不做功能清单搬运，而是把 v1.36 发布后的升级动作整理成一套可复用流程：先确认版本变化，再审计弃用和移除风险，然后用测试集群验证，最后灰度升级并准备回滚预案。

目标和边界

本文面向已经在生产环境使用 Kubernetes 的后端、运维和 DevOps 团队。目标是帮助你把 v1.36 的发布新闻转成升级执行计划，而不是只看一眼新特性就改集群版本。

本文不会逐项解释所有增强项，也不会替代你所在云厂商或发行版的升级文档。更稳妥的做法是：用官方 Kubernetes 发布博客和 changelog 识别通用变化，再结合自己的发行版、CNI、CSI、Ingress、监控和准入策略做验证。

先说结论：v1.36 升级前最需要做的是资源清单审计、插件兼容性检查、测试集群演练和灰度节点池验证。尤其是 gitRepo volume 禁用、Service externalIPs 警告、Ingress NGINX 维护状态变化这类风险，不能等生产报错后再处理。

全流程总览

一次 Kubernetes 小版本升级，推荐拆成五步：v1.36 发布信息确认、弃用扫描、测试集群、灰度升级、回滚预案。每一步都要留下证据，方便上线评审和事故复盘。

阶段一：读官方发布信息，不急着升生产

目标

先把 v1.36 的变化范围摸清楚。官方发布博客提到这个版本包含稳定、Beta 和 Alpha 功能变化，同时 changelog 里会列出更细的升级注意事项、API 变化和依赖变化。

关键动作

建议把发布信息拆成三张表：新稳定能力、需要验证的 Beta 能力、可能影响现有资源的弃用或移除项。业务团队最关心的是第三张表，因为它直接影响升级风险。

kubectl version
kubectl get nodes -o wide
kubectl get apiservices
kubectl get crd
kubectl get pods -A --field-selector=status.phase!=Running

常用工具/代码选择

如果集群由云厂商托管，还要读对应厂商的 Kubernetes 发行说明。上游 v1.36 已发布，不代表托管服务已经开放升级，也不代表插件版本已经完全匹配。

检查点

在升级评审前，应该能回答三个问题：当前集群在哪个版本、目标版本是否被供应商支持、升级会影响哪些控制面插件和业务资源。

阶段二：先审计弃用和移除风险

升级真正容易出问题的地方，通常不是新功能，而是旧用法。v1.36 相关资料里，gitRepo volume 禁用、Service externalIPs 的警告、Ingress NGINX 维护状态变化，都值得在升级前单独检查。

目标

在升级之前发现不兼容资源，并给出迁移计划。不要等控制面升级后再去翻 YAML。

关键动作

先导出资源清单，再扫描关键字段。gitRepo volume 如果还在用，要迁移到更可控的初始化容器或镜像构建流程；externalIPs 要确认是否还符合网络安全策略；Ingress NGINX 相关流量入口要评估迁移到其他 Ingress Controller 或 Gateway API 的路线。

kubectl get deploy,sts,ds,job,cronjob,svc,ingress -A -o yaml > cluster-resources.yaml

grep -n "gitRepo:" cluster-resources.yaml || true
grep -n "externalIPs:" cluster-resources.yaml || true
grep -n "ingressClassName:" cluster-resources.yaml || true

常用工具/代码选择

大集群不要只用 grep。可以把资源导出到 Git 仓库，用策略扫描工具或 CI 任务检查 apiVersion、字段、IngressClass、Service 类型、存储类和安全上下文。

检查点

每个风险项都要有处理状态：无需处理、已迁移、待业务确认、阻塞升级。只要还有“看起来应该没事”的资源，就不适合直接升级生产。

阶段三：用测试集群验证控制面和插件

目标

测试集群不是摆设。它要尽量复刻生产里的关键能力：网络、存储、证书、准入控制、监控、日志采集、镜像拉取和常见工作负载。

关键动作

先升级测试集群，再部署核心服务的缩小版本。验证维度不要只看 Pod 是否 Running，还要看服务发现、Ingress、持久卷、HPA、探针、日志和告警。

kubectl get componentstatuses 2>/dev/null || true
kubectl get nodes
kubectl get pods -A
kubectl get events -A --sort-by=.metadata.creationTimestamp
kubectl describe ingress -A

常用工具/代码选择

推荐准备一组冒烟测试：创建 Deployment、Service、Ingress、PVC，访问一个测试接口，触发一次滚动更新，再删除资源。这样能覆盖调度、网络、存储和控制器协作。

检查点

测试集群要产出一份升级报告：通过项、失败项、待确认项、插件版本、业务改动点。没有测试报告的升级，后续很难判断生产问题是不是版本引起的。

阶段四：灰度升级和回滚预案

目标

生产升级要尽量把影响面缩小。先升级低风险节点池、低流量命名空间或非核心业务，再逐步扩大范围。

关键动作

灰度时至少观察四类指标：Pod 重启次数、调度失败事件、接口错误率、P95/P99 延迟。升级窗口内要有明确冻结规则，不要同时做业务发布、插件改造和集群升级。

kubectl get pods -A --sort-by=.status.startTime
kubectl get events -A --sort-by=.lastTimestamp
kubectl top nodes
kubectl top pods -A

常用工具/代码选择

回滚预案至少包含：etcd 或托管控制面备份策略、节点池回退路径、插件版本回退、业务流量切回、负责人和值班窗口。云厂商托管集群还要确认回退是否受平台限制。

检查点

灰度完成后不要立刻宣布结束。至少再观察一个业务峰值周期，确认告警、重启、延迟和扩缩容都稳定，再推进下一批。

我的推荐流程

1. 先读 Kubernetes v1.36 官方发布博客和 changelog，整理变化清单。
2. 导出当前集群资源，扫描 gitRepo、externalIPs、Ingress、老 API 版本和关键插件配置。
3. 在测试集群升级到 v1.36，部署核心服务缩小版并跑冒烟测试。
4. 确认 CNI、CSI、Ingress、监控、日志、证书和准入策略都兼容。
5. 制定灰度批次，先升级低风险节点池或低流量业务。
6. 观察至少一个高峰周期，再推进下一批。
7. 保留回滚预案和升级报告，方便后续复盘。

容易踩坑

落地速查表

总结一下，Kubernetes v1.36 的发布对云原生团队是一个升级窗口提醒。不要把升级看成“点一下版本号”，而要把它拆成官方信息确认、弃用审计、测试演练、灰度推进和回滚准备。这样才能把新闻里的版本变化，变成生产环境可控的工程动作。