Kubernetes 1.34 维护窗口怎么排升级：版本偏差检查与灰度门禁

如果你手里的生产集群还跑着 Kubernetes 1.34，现在最先要做的是梳理清楚各个组件的现有版本和可行的升级路径，别等维护窗口收窄了才临时赶工调整。Kubernetes 官方发布的公告显示，1.34 会在 2026 年 8 月 27 日进入维护模式，整个版本的生命周期结束日期定在 10 月 27 日；进入维护模式之后，官方补丁的发布范围会明显缩小，留给常规升级的操作缓冲时间也会变得更紧张。

Kubernetes 1.34 不是在 8 月 27 日当天就彻底没法用，你完全可以把这个日期当成升级的时间节点：先核对 control plane、kubelet、kube-proxy 这几个核心组件的版本偏差，再决定是留在 1.34 的维护周期内完成操作，还是直接往 1.35 或者 1.36 迁移。

Kubernetes 1.34 的变动，核心影响的是版本支持窗口

Kubernetes 项目的常规惯例是维护最近三个小版本。官方的补丁发布规则会把整个支持期拆成标准支持阶段，再加上时长大概两个月的维护模式阶段：进入维护模式之后，发布团队只会优先处理带 CVE 的高危漏洞、依赖问题和核心组件的严重故障。这不是说集群到点就直接停服务，而是你后续能拿到的修复覆盖范围、可选的官方支持会一步步收窄。

所以手里有 1.34 集群的运维同学第一步不用直接改镜像标签，先理清楚三个问题：当前集群的补丁版本是不是 1.34.9；集群里有没有还在使用已废弃旧 API 的扩展组件；业务侧能不能在 10 月 27 日之前跑完一遍完整的回归测试。

先把组件版本偏差的规则整理成核对清单

版本偏差的规则最容易在滚动升级的时候被忽略。高可用集群里的 kube-apiserver 实例之间最多只能差一个小版本；kubelet 版本不能比 kube-apiserver 新，最多可以落后三个小版本；kube-proxy 同样版本不能高于 kube-apiserver，而且它和所在节点 kubelet 的偏差也有对应的上限要求。

kubectl version
kubectl get nodes -o custom-columns=NODE:.metadata.name,KUBELET:.status.nodeInfo.kubeletVersion
kubectl -n kube-system get pods -o wide
kubectl get --raw='/version'

输出记录的时候别笼统只写一个“集群版本”就完事。把 control plane、节点 kubelet、kube-proxy、CNI、CSI 和 Ingress Controller 单独列项，标注清楚当前版本、目标版本、偏差规则和对应的验证负责人。如果你用的是云厂商的托管 Kubernetes 服务，还要把服务商的升级策略单独列出来，不能直接拿社区通用规则替代供应商给出的官方支持承诺。

从资产盘点到灰度放量，按四个阶段推进就足够稳妥

第一阶段：锁定目标版本和回退边界

选 1.35 或者 1.36 作为目标版本的时候，先确认你用的发行版、容器运行时和所有扩展组件的官方支持矩阵。给 etcd 快照、关键 ConfigMap、Ingress 配置和业务部署清单都留好可快速恢复的副本，同时明确谁有权限随时暂停升级操作。

第二阶段：清理废弃 API 和旧插件

挨个检查已废弃 API、Webhook、CRD schema、准入配置和节点标签。升级之前先在非生产集群跑一遍完全相同的配置清单，盯着控制器日志、集群事件和工作负载滚动状态走一遍全流程。只看 Pod 是不是 Running 状态远远不够，还要验证入口流量、定时任务、存储挂载和证书续期的运行状态都正常才行。

第三阶段：小范围节点灰度验证

先选可以安全驱逐、业务处于低峰期且有明确运维负责人的节点做试点。升级一台之后检查 kubectl get nodes、核心命名空间事件、P95 延迟和错误率；所有指标都稳定之后再扩容到下一批节点。control plane 和 worker 节点别在同一个时间窗口里无限制全量变更。

第四阶段：结果验收和操作留痕

把升级前后的版本信息、事件日志、关键 SLI、失败工作负载和回退判断标准都记录到变更单里。如果出现 API 请求失败、Webhook 超时、CNI 路由异常或者存储挂载错误的情况，先暂停操作扩散，保留好现场证据，再对照对应发行版的官方文档执行回退或者修复操作。

常见误区：官方补丁支持和生态兼容不是一回事

“官方还支持 1.34”只能说明 Kubernetes 项目本身的补丁维护边界，不能证明某个 CNI、CSI、Ingress 或者业务 Operator 已经做过对应的适配验证。反过来，“马上进入维护模式”也不等于必须在通知发布当天立刻完成所有升级。更稳妥的做法是把维护日期当成最终提醒，用一周或者一个常规发布周期的时间提前完成演练就可以。

如果暂时没法安排升级，至少要把 1.34.9 的适配状态、扩展组件支持矩阵、漏洞响应方式和下一次演练的日期写进运维记录；如果已经准备启动升级，先在同版本的预生产集群复现真实流量和故障恢复的全流程。

相关问题

Kubernetes 1.34 进维护模式之后还能继续运行吗？

可以继续运行，但项目官方能提供的修复范围会收窄，直到 2026 年 10 月 27 日结束生命周期。企业还要结合自己使用的发行版和云厂商的支持政策综合判断运行风险。

kubelet 能不能先升级到比 apiserver 更新的版本？

不建议这么操作。官方版本偏差规则明确要求 kubelet 版本不得新于 kube-apiserver，并且最多只能落后三个小版本。

升级前只执行 kubectl version 够不够？

不够。它不能替代节点逐台核对、kube-proxy/CNI/CSI 检查、废弃 API 扫描和业务回归，至少要把这些环节的结果合并到同一份变更清单中。

把 8 月 27 日当作升级演练的时间门槛

Kubernetes 1.34 的维护模式是一个非常清晰的时间信号：先确认版本偏差，再确认生态兼容，最后用灰度和可回退动作控制升级风险。对于已经稳定运行很久的集群，提前完成一次小范围演练，往往比临近 EOL 时被动赶进度更容易发现潜在的隐藏问题。