Kubernetes v1.34 抢先一览

作者 Agustina Barbetta, Alejandro Josue Leon Bellido, Graziano Casto, Melony Qin, Dipesh Rawat | 译者 Michael Yao (DaoCloud) |

Kubernetes v1.34 将于 2025 年 8 月底发布。 本次发版不会移除或弃用任何特性，但包含了数量惊人的增强特性。 以下列出一些本次发版最令人兴奋的特性！

请注意，以下内容反映的是 v1.34 当前的开发状态，发布前可能会发生变更。

Kubernetes v1.34 的重点增强特性

以下列出了一些可能会包含在 v1.34 版本中的重要增强特性， 但这并不是所有计划更改的详尽列表。 这并不构成承诺，发布内容可能会发生变更。

DRA 核心功能趋向稳定

动态资源分配（DRA） 提供了一种灵活的方式来分类、请求和使用集群中的 GPU 或定制硬件等设备。

自 v1.30 版本起，DRA 已基于结构化参数来申领设备，这些参数对于 Kubernetes 核心是不可见的。 相关增强提案 KEP-4381 借鉴了存储卷动态制备的思路。 使用结构化参数的 DRA 依赖一组辅助 API 类别：包括 resource.k8s.io 下的 ResourceClaim、DeviceClass、ResourceClaimTemplate 和 ResourceSlice， 还在 Pod 的 .spec 中新增了 resourceClaims 字段。 DRA 的核心功能计划在 Kubernetes v1.34 中进阶至稳定阶段。

借助 DRA，设备驱动和集群管理员定义可用的设备类。 工作负载可以在设备请求中从设备类申领设备。 Kubernetes 为每个申领分配匹配的设备，并将相关 Pod 安排到可访问所分配设备的节点上。 这种框架提供了使用 CEL 的灵活设备筛选、集中式设备分类和简化的 Pod 请求等优点。

一旦此特性进入稳定阶段，resource.k8s.io/v1 API 将默认可用。

使用 ServiceAccount 令牌进行镜像拉取身份认证

ServiceAccount 令牌与 kubelet 凭据提供程序集成的特性预计将在 Kubernetes v1.34 中进入 Beta 阶段并默认启用。 这将允许 kubelet 在从需要身份认证的镜像仓库中拉取容器镜像时使用这些令牌。

此特性已作为 Alpha 存在，并由 KEP-4412 跟踪。

现有的 Alpha 集成允许 kubelet 使用生命期短、自动轮换的 ServiceAccount 令牌 （符合 OIDC 标准）来向容器镜像仓库进行身份认证。 每个令牌与一个 Pod 相关联；整个机制可替代长期存在的镜像拉取 Secret。

采用这一新方式可以降低安全风险、支持工作负载级身份，并减少运维负担。 它让镜像拉取认证更加贴合现代、具备身份感知的最佳实践。

Deployment 的 Pod 替换策略

对 Deployment 做出变更后，终止中的 Pod 可能会保留较长时间，并消耗额外资源。 作为 KEP-3973 的一部分，.spec.podReplacementPolicy 字段将以 Alpha 形式引入到 Deployment 中。

如果你的集群启用了此特性，你可以选择以下两种策略之一：

TerminationStarted
一旦旧 Pod 开始终止，立即创建新 Pod，带来更快的上线速度，但资源消耗可能更高。
TerminationComplete
等待旧 Pod 完全终止后才创建新 Pod，上线速度较慢，但资源消耗控制更好。

此特性通过让你选择更新或扩缩容期间何时创建新 Pod，从而使 Deployment 行为更可控。 在资源受限的集群或终止时间较长的工作负载中尤为有用。

预计此特性将作为 Alpha 特性推出，并可通过在 API 服务器和 kube-controller-manager 中启用 DeploymentPodReplacementPolicy 和 DeploymentReplicaSetTerminatingReplicas 特性门控启用。

kubelet 和 API 服务器的生产级追踪特性

为了解决通过日志关联进行节点级调试的长期难题， KEP-2831 为 kubelet 提供了深度上下文可视化能力。

此特性使用供应商中立的 OpenTelemetry 标准，为关键的 kubelet 操作（特别是其对容器运行时接口的 gRPC 调用）做了插桩。 它使运维人员能够可视化整个事件生命周期（例如：Pod 启动）以定位延迟或错误来源。 其强大之处在于传播链路上下文：kubelet 在向容器运行时发送请求时附带链路 ID，使运行时能够链接自身的 Span。

这一工作得到了另一个增强提案 KEP-647 的配合， 后者为 Kubernetes API 服务器引入了相同的链路追踪能力。 两者结合提供了从控制面到节点的端到端事件视图，极大简化了定位延迟和错误的过程。 这些特性已在 Kubernetes 正式版本发布流程中逐渐成熟：
KEP-2831 在 v1.25 中以 Alpha 发布， KEP-647 在 v1.22 中首次作为 Alpha 发布， 这两个特性在 v1.27 中一起进阶至 Beta。 展望未来，kubelet 追踪（KEP-2831）和 API 服务器追踪（KEP-647）计划在 v1.34 中进入稳定阶段。

Service 的 PreferSameZone 和 PreferSameNode 流量分发

Kubernetes Service 的 spec.trafficDistribution 字段允许用户表达服务端点的流量路由偏好。

KEP-3015 弃用了 PreferClose，并引入了两个新值：PreferSameZone 和 PreferSameNode。 PreferSameZone 等价于当前的 PreferClose；
PreferSameNode 优先将流量发送至与客户端位于同一节点的端点。

此特性在 v1.33 中引入，受 PreferSameTrafficDistribution 特性门控控制。 v1.34 中此特性预计将进入 Beta，并默认启用。

支持 KYAML：Kubernetes 的 YAML 方言

KYAML 是为 Kubernetes 设计的更安全、更少歧义的 YAML 子集。 无论你使用哪个版本的 Kubernetes，都可以使用 KYAML 编写清单和 Helm 模板。 你可以编写 KYAML 并将其作为输入传递给任意版本的 kubectl，因为所有 KYAML 文件都是合法的 YAML。 在 kubectl v1.34 中，你还可以请求以 KYAML 格式输出（如：kubectl get -o kyaml …）。 当然，如果你愿意，也可以继续使用 JSON 或 YAML 格式输出。

KYAML 解决了 YAML 和 JSON 的一些具体问题：
YAML 对缩进的敏感性需要你注意空格和嵌套， 而其可选的字符串引号可能导致意外类型转换 （参见 “挪威 bug”）。 与此同时，JSON 不支持注释，且对尾逗号和键的引号有严格要求。

KEP-5295 引入了 KYAML，尝试解决这些主要问题：

  • 所有值字符串始终使用英文双引号

  • 键不加英文引号，除非可能产生歧义

  • 所有映射使用 {} 表示（即关联数组）

  • 所有列表使用 [] 表示

这听起来像 JSON？确实如此！但与 JSON 不同的是，KYAML 支持注释、允许尾逗号，且不强制键加引号。

我们希望在 kubectl v1.34 中将 KYAML 引入为一种新的输出格式。 如同其他特性一样，这些变更尚未百分百确定，敬请关注！

KYAML 作为一种格式，是 YAML 的严格子集， 这确保任何符合规范的 YAML 解析器都能解析 KYAML 文档。 Kubernetes 并不要求你必须提供 KYAML 格式的输入，也没有这方面的计划。

HPA 支持精细化自动扩缩控制容忍度配置

KEP-4951 引入了一项新特性，允许用户在每个 HPA 上配置扩缩容忍度， 以覆盖默认的集群级 10% 容忍度设置，这一默认值对多样化的工作负载来说往往过于粗略。 本次增强为 HPA 的 spec.behavior.scaleUp 和 spec.behavior.scaleDown 部分新增了可选的 tolerance 字段， 使得扩容和缩容操作可以采用不同的容忍值。 这非常有用，因为在应对突发流量时，扩容响应通常比缩容速度更为关键。

此特性作为 Alpha 特性，在 Kubernetes v1.33 中引入，并受 HPAConfigurableTolerance 特性门控控制。 预计将在 v1.34 中进阶为 Beta。 这项改进有助于解决大规模部署中的扩缩容难题，例如在缩容时，10% 的容忍度可能意味着会保留数百个不必要的 Pod。 通过这一更灵活的配置方式，用户可以针对不同工作负载优化扩缩容行为的响应性和保守性。

想了解更多？

新特性和弃用项也会在 Kubernetes 发布说明中公布。我们将在 Kubernetes v1.34 变更日志中正式宣布新增内容。

Kubernetes v1.34 的计划发布时间为 2025 年 8 月 27 日（周三）。敬请期待更多更新！

参与其中

参与 Kubernetes 最简单的方式就是加入与你兴趣相关的特别兴趣小组（SIG）。 有想要向社区分享的内容？欢迎在每周的社区会议上发声， 或通过以下渠道参与讨论。感谢你一如既往的反馈和支持！