Kubernetes v1.34 抢先看

Kubernetes v1.34 将于 2025 年 8 月底发布。此版本不包含任何移除或弃用,但包含了大量增强功能。以下是我们在此周期中最期待的一些功能!

请注意,此信息反映了 v1.34 开发的当前状态,发布前可能会发生变化。

以下列表重点介绍了一些可能包含在 v1.34 版本中的显著增强功能,但这并非所有计划变更的详尽列表。这不是一个承诺,发布内容可能会发生变化。

DRA 核心功能趋于稳定

动态资源分配 (DRA) 提供了一种灵活的方式来对 Kubernetes 集群中的 GPU 或自定义硬件等设备进行分类、请求和使用。

自 v1.30 版本以来,DRA 一直围绕着使用对 Kubernetes 核心不透明的**结构化参数**来声明设备。相关的增强提案 KEP-4381 从存储卷的动态供应中汲取了灵感。带有结构化参数的 DRA 依赖于一组支持的 API 类型:在 resource.k8s.io 下的 ResourceClaim、DeviceClass、ResourceClaimTemplate 和 ResourceSlice API 类型,同时通过新的 resourceClaims 字段扩展了 Pod 的 .spec。DRA 的核心功能目标是在 Kubernetes v1.34 中达到稳定版本。

通过 DRA,设备驱动程序和集群管理员可以定义可用的设备类。工作负载可以在设备请求中声明某个设备类的设备。Kubernetes 将匹配的设备分配给特定的声明,并将相应的 Pod 放置在可以访问所分配设备的节点上。该框架提供了使用 CEL 进行灵活的设备过滤、集中式设备分类和简化的 Pod 请求等诸多好处。

此功能升级后,resource.k8s.io/v1 API 将默认可用。

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

kubelet 凭证提供商的 ServiceAccount 令牌集成很可能在 Kubernetes v1.34 中达到 Beta 阶段并默认启用。这允许 kubelet 在从需要身份验证的容器镜像仓库中拉取镜像时使用这些令牌。

该支持已作为 Alpha 功能存在,并在 KEP-4412 中进行跟踪。

现有的 Alpha 集成允许 kubelet 使用短期的、自动轮换的 ServiceAccount 令牌(遵循 OIDC 兼容的语义)向容器镜像仓库进行身份验证。每个令牌都作用于一个关联的 Pod;整个机制取代了对长期镜像拉取 Secret 的需求。

采用这种新方法可以降低安全风险,支持工作负载级别的身份,并有助于减少运营开销。它使镜像拉取身份验证更接近现代的、具有身份感知能力的良好实践。

Deployment 的 Pod 替换策略

在对 Deployment 进行更改后,正在终止的 Pod 可能会在相当长的时间内保持运行状态,并可能消耗额外的资源。作为 KEP-3973 的一部分,将为 Deployment 引入 .spec.podReplacementPolicy 字段(作为 Alpha 功能)。

如果你的集群启用了此功能,你将能够选择以下两种策略之一

TerminationStarted
一旦旧 Pod 开始终止,就立即创建新 Pod,从而加快滚动更新速度,但代价是可能消耗更多资源。
TerminationComplete
等到旧 Pod 完全终止后再创建新 Pod,这会导致滚动更新速度变慢,但能确保资源消耗得到控制。

此功能允许你选择在更新或扩缩容期间何时创建新 Pod,从而使 Deployment 的行为更具可预测性。当你在资源受限的集群中工作或处理具有较长终止周期的工作负载时,此功能非常有用。

预计此功能将作为 Alpha 功能提供,可以通过在 API Server 和 kube-controller-manager 中使用 DeploymentPodReplacementPolicyDeploymentReplicaSetTerminatingReplicas 特性门控来启用。

kubelet 和 API Server 的生产就绪级追踪

为了解决长期以来通过关联不连贯的日志来调试节点级问题的挑战,KEP-2831 提供了对 kubelet 深入的、上下文相关的洞察。

此功能使用与供应商无关的 OpenTelemetry 标准来检测关键的 kubelet 操作,特别是其对容器运行时接口 (CRI) 的 gRPC 调用。它允许操作员可视化事件的整个生命周期(例如:Pod 启动),从而精确定位延迟和错误的来源。其最强大的方面是追踪上下文的传播;kubelet 在其请求中传递一个追踪 ID 给容器运行时,从而使运行时能够链接其自身的跨度(span)。

这项工作得到了一个并行增强功能 KEP-647 的补充,该增强功能为 Kubernetes API Server 带来了相同的追踪能力。这些增强功能共同提供了一个更统一的、端到端的事件视图,简化了从控制平面到节点精确定位延迟和错误的过程。这些功能已经通过官方的 Kubernetes 发布流程逐渐成熟。KEP-2831 在 v1.25 中作为 Alpha 功能引入,而 KEP-647 在 v1.22 中作为 Alpha 功能首次亮相。这两项增强功能都在 v1.27 版本中一起升级为 Beta。展望未来,Kubelet 追踪 (KEP-2831) 和 API Server 追踪 (KEP-647) 现在目标是在即将到来的 v1.34 版本中毕业为稳定版。

服务的 PreferSameZonePreferSameNode 流量分发

Kubernetes Service 中的 spec.trafficDistribution 字段允许用户表达关于流量应如何路由到 Service 端点的偏好。

KEP-3015 弃用了 PreferClose 并引入了两个额外的值:PreferSameZonePreferSameNodePreferSameZone 等同于当前的 PreferClosePreferSameNode 优先将流量发送到与客户端位于同一节点上的端点。

此功能在 v1.33 中通过 PreferSameTrafficDistribution 特性门控引入。其目标是在 v1.34 中升级为 Beta 版本,并默认启用该特性门控。

支持 KYAML:一种 Kubernetes 的 YAML 方言

KYAML 旨在成为一种更安全、歧义更少的 YAML 子集,专为 Kubernetes 设计。无论你使用哪个版本的 Kubernetes,你都可以使用 KYAML 来编写清单和/或 Helm charts。你可以编写 KYAML 并将其作为输入传递给**任何**版本的 kubectl,因为所有 KYAML 文件也都是有效的 YAML 文件。在 kubectl v1.34 中,我们期望你也能请求 kubectl 输出 KYAML 格式(如 kubectl get -o kyaml …)。如果你愿意,仍然可以请求 JSON 或 YAML 格式的输出。

KYAML 解决了 YAML 和 JSON 的特定挑战。YAML 的重要空白要求仔细注意缩进和嵌套,而其可选的字符串引用可能导致意外的类型强制转换(例如:“挪威 Bug”)。同时,JSON 缺乏注释支持,并且对尾随逗号和带引号的键有严格要求。

KEP-5295 引入了 KYAML,它试图通过以下方式解决最重要的问题:

  • 始终用双引号包裹值字符串

  • 除非键可能产生歧义,否则不加引号

  • 始终使用 {} 表示映射(关联数组)

  • 始终使用 [] 表示列表

这听起来很像 JSON,因为它确实如此!但与 JSON 不同,KYAML 支持注释,允许尾随逗号,并且不要求键必须加引号。

我们希望看到 KYAML 在 kubectl v1.34 中作为一种新的输出格式被引入。与所有这些功能一样,这些变化都不是 100% 确定的;敬请关注!

作为一种格式,KYAML 是并且将继续是 **YAML 的严格子集**,确保任何兼容的 YAML 解析器都可以解析 KYAML 文档。Kubernetes 不要求你提供专门格式化为 KYAML 的输入,我们也没有计划改变这一点。

通过 HPA 可配置容忍度实现精细的自动扩缩容控制

KEP-4951 引入了一项新功能,允许用户在每个 HPA 的基础上配置自动扩缩容的容忍度,覆盖了默认的集群范围 10% 容忍度设置,后者对于多样化的工作负载来说通常过于粗糙。该增强功能在 HPA 的 spec.behavior.scaleUpspec.behavior.scaleDown 部分添加了一个可选的 tolerance 字段,从而可以为扩容和缩容操作设置不同的容忍值,这尤其有价值,因为扩容的响应能力通常比缩容的速度更关键,以便处理流量激增。

此功能在 Kubernetes v1.33 中作为 Alpha 版本发布,受 HPAConfigurableTolerance 特性门控控制,预计将在 v1.34 中升级为 Beta。这一改进有助于解决大规模部署中的扩缩容挑战,例如在缩容时,10% 的容忍度可能意味着保留数百个不必要的 Pod 运行。使用新的、更灵活的方法将能够针对响应式和保守的扩缩容行为进行特定于工作负载的优化。

想了解更多吗?

新功能和弃用信息也会在 Kubernetes 版本说明中公布。我们将在 Kubernetes v1.34 的变更日志中正式宣布该版本的新内容。

Kubernetes v1.34 计划于 2025 年 8 月 27 日,星期三发布。敬请关注更新!

参与其中

参与 Kubernetes 的最简单方法是加入众多与你的兴趣相符的特别兴趣小组(SIG)之一。有什么想向 Kubernetes 社区分享的吗?请在我们的每周社区会议上以及通过以下渠道分享你的声音。感谢你持续的反馈和支持。