Kubernetes 1.34 发布说明怎样阅读升级影响

Kubernetes 1.34 的发布说明不适合从头到尾当成“新功能清单”阅读。更实用的做法是先锁定准备升级的具体 v1.34.x，再把内容按成熟度、弃用与移除、组件依赖、回退信号四层筛选。这样才能回答真正的运维问题：哪些能力可以直接采用，哪些只需要观察，哪些旧配置必须先改。

官方地址：https://kubernetes.io/blog/2025/08/27/kubernetes-v1-34-release/

官方 1.34 发布公告显示，这个版本包含 58 项增强，其中 23 项进入 Stable、22 项进入 Beta、13 项进入 Alpha。这个数字适合帮助我们估计阅读范围，但不应该直接等同于升级风险。升级影响取决于你的工作负载是否命中了这些能力，以及周边插件能否一起工作。

先确认你读的是哪个 1.34

“升级到 Kubernetes 1.34”至少有两个不同问题：一是从 1.33 或更早版本跨到 1.34 的 minor upgrade，二是在 1.34 分支内选择具体的 patch release。发布公告负责告诉你 1.34.0 带来了什么，CHANGELOG 和补丁发布页则负责告诉你当前维护状态和后续修复。

截至本轮写作使用的官方发布资料，1.34.0 的发布日期是 2025-08-27，1.34.12 的发布日期是 2026-09-15，1.34 分支的 EOL 日期是 2026-10-27。也就是说，今天再做 1.34 评估时，不能只看最初的 1.34.0；更应该先确认组织是否仍需要维护一个已经结束生命周期的分支。

# 记录当前集群版本，避免把“目标 minor 版本”误当成已安装版本
kubectl version --output=yaml

# 只查看控制面与节点的版本差异，后续再结合版本偏差策略判断窗口
kubectl get nodes -o custom-columns=NAME:.metadata.name,VERSION:.status.nodeInfo.kubeletVersion

上面的命令只是盘点入口。输出后要把控制面、kubelet、kubectl、容器运行时、CNI、CSI 和入口控制器分别记在升级单里，不要只保存一个集群版本字符串。

按 Stable、Beta、Alpha 给变更加权

发布说明的第一遍阅读应该先看 Feature State，而不是先看功能名字。Stable 通常意味着能力已经进入稳定使用阶段，但仍然要确认 API、默认值和周边实现是否适合现有集群；Beta 需要检查 feature gate、升级前后的默认行为和扩展组件；Alpha 则更适合在实验集群验证，不应因为“新”就自动纳入生产变更。

1.34 的代表性变化包括 DRA 核心 API 进入 Stable、KYAML 输出格式进入 Alpha，以及 Pod-level resources 等能力进入 Beta。阅读这些条目时，重点不是把名词抄进周报，而是判断集群里是否真的使用 GPU、设备资源、特定 kubectl 输出或 pod 级资源配置。

把弃用和移除单独拉出来

新特性可以稍后采用，弃用和移除却可能在升级窗口里直接变成阻断项。因此第二遍阅读要单独打开发布公告中的 deprecations/removals，并对照官方版本偏差策略检查控制面、节点和客户端的组合关系。

建议把每一条风险写成“对象 + 现状 + 目标 + 处理动作”，例如：某个旧 API 仍出现在 GitOps 仓库，目标版本不再推荐，处理动作是在测试集群先切换到替代 API，再把旧清单从发布流水线中删除。只写“存在弃用项”没有办法指导升级。

# 导出常用资源清单，便于搜索 API 版本和旧字段
kubectl get deployments,statefulsets,daemonsets,ingresses -A -o yaml > workload-inventory.yaml

# 只在本地审阅副本中检索旧 API；不要把命令输出直接当成线上变更
rg "apiVersion:|extensions/|v1beta1" workload-inventory.yaml

检索结果还需要人工映射到官方迁移说明，因为命中字符串不等于一定会被当前集群使用，未命中也不代表 Helm、Kustomize、Webhook 或控制器代码里没有旧接口。

把发布说明映射到六类集群资产

运维评估最容易遗漏的是“发布说明写的是组件能力，自己的风险藏在业务资产里”。可以按工作负载、存储、设备资源、调度与节点、镜像与身份、扩展组件和脚本六个方向做映射。

• 工作负载：Job、Sidecar、Pod 资源、容器重启策略是否命中变更。
• 存储：CSI、卷扩容、快照、VolumeAttributesClass 是否由现有插件支持。
• 设备资源：DRA、GPU、网卡或其他设备声明是否在集群中启用。
• 调度与节点：cgroup 驱动、taint 管理、CPU Manager 和节点镜像是否匹配。
• 镜像与身份：镜像拉取、ServiceAccount token、准入策略是否需要重新回归。
• 扩展组件与脚本：Ingress、CNI、CSI、监控、备份、kubectl 脚本是否依赖旧行为。

完成映射后，每一项都应有一个可观察的结果。例如存储项不是“检查 CSI”，而是“创建测试 PVC、扩容、挂载并确认业务读写”；设备项不是“关注 DRA”，而是“确认 ResourceClaim、DeviceClass 和节点设备插件在预发布集群的行为”。

用小范围升级验证，而不是只看发布成功

发布命令返回成功，只能说明控制面升级动作完成，不能说明业务升级完成。建议把验证拆成四道门：控制面健康、节点回归、扩展组件、关键业务。

# 升级后先看节点是否全部回到可调度状态
kubectl get nodes -o wide

# 查看系统组件和关键命名空间的异常事件，聚焦升级窗口产生的新问题
kubectl get events -A --sort-by=.lastTimestamp

# 对关键工作负载检查副本数与就绪数，避免只看 Pod 是否存在
kubectl get deploy,statefulset -A \
  -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,DESIRED:.spec.replicas,READY:.status.readyReplicas

验证项要提前写成通过条件，例如节点无 NotReady、核心 Deployment 的 readyReplicas 达到目标、CSI 创建和删除卷成功、入口流量的健康检查恢复、备份任务产生可读取的结果。若只是看到 Pod 处于 Running，却没有验证存储、网络和外部依赖，结论仍然不完整。

回退路径和告警确认要先于生产升级

Kubernetes 的 minor upgrade 不应依赖“出问题再想怎么降级”。回退通常不是简单把控制面版本改回去，而是要依赖云厂商或发行版的支持方式、节点轮换策略、配置仓库版本和数据面兼容性。因此升级前至少要明确四件事：谁有权限停止扩大范围、哪些指标触发暂停、如何恢复上一版节点池、业务数据如何保证可用。

如果 1.34 的某项 Beta 能力只在 feature gate 打开后生效，回退单上还要记录关闭 gate 后的资源和配置是否仍可被旧版本解析。对于 Storage、DRA、Webhook 这类会改变资源或控制链路的能力，更应该把“恢复旧 manifest”和“验证旧控制器读写”列为独立动作。

一份够用的升级判定清单

1. 目标版本写成具体的 v1.34.x，并记录该分支支持状态。
2. 命中的 Stable、Beta、Alpha 能力分别标注采用、验证或暂不采用。
3. 弃用和移除项逐条绑定到清单、插件、脚本或控制器。
4. 控制面、节点、CSI、CNI、入口、监控和备份都有回归信号。
5. 暂停扩大范围和恢复上一版本节点的责任人、条件与动作已写清。

相关问题

Kubernetes 1.34 的 58 项增强需要全部测试吗？

不需要。应先按成熟度筛选，再按集群资产命中关系缩小范围。未使用的功能不必强行做功能测试，但版本兼容、基础健康、网络、存储和关键业务回归仍然要做。

只升级 kubectl 能算完成 1.34 升级吗？

不能。kubectl 客户端版本只是访问入口，控制面、kubelet、容器运行时和扩展组件仍要按版本偏差策略分别评估。

为什么发布公告和当前支持状态要分开看？

发布公告描述的是 1.34 初始能力，补丁发布页描述的是维护节奏和生命周期。升级决策需要同时知道“版本带来了什么”和“现在是否还值得部署”。

阅读 Kubernetes 1.34 发布说明时，可以记住一个顺序：先定具体 patch，再分成熟度；先筛弃用移除，再映射集群资产；先写验证门和回退动作，再决定是否扩大升级范围。