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、Admission 配置和节点标签。升级前先在非生产集群跑一遍完全相同的配置清单，观察控制器日志、集群事件和工作负载滚动状态。只看 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 时被动追赶更容易发现潜在的隐藏问题。