Kubernetes v1.32 预览

2024.11.08

随着 Kubernetes v1.32 发布日期的临近，Kubernetes 项目继续发展和成熟。在这个过程中，某些特性可能会被弃用、移除或被更好的特性取代，以确保项目的整体健康与发展。

本文概述了 Kubernetes v1.32 发布的一些计划变更，发布团队认为你应该了解这些变更，以确保你的 Kubernetes 环境得以持续维护并跟上最新的变化。以下信息基于 v1.32 发布的当前状态，实际发布日期前可能会有所变动。

Kubernetes API 的移除和弃用流程

Kubernetes 项目对功能特性有一个文档完备的弃用策略。该策略规定，只有当较新的、稳定的相同 API 可用时，原有的稳定 API 才可能被弃用，每个稳定级别的 API 都有一个最短的生命周期。弃用的 API 指的是已标记为将在后续发行某个 Kubernetes 版本时移除的 API；移除之前该 API 将继续发挥作用（从弃用起至少一年时间），但使用时会显示一条警告。移除的 API 将在当前版本中不再可用，此时你必须迁移以使用替换的 API。

正式发布的（GA）或稳定的 API 版本可被标记为已弃用，但不得在 Kubernetes 主要版本未变时删除。
Beta 或预发布 API 版本，必须保持在被弃用后 3 个发布版本中仍然可用。
Alpha 或实验性 API 版本可以在任何版本中删除，不必提前通知；如果同一特性已有不同实施方案，则此过程可能会成为撤销。

无论 API 是因为特性从 Beta 升级到稳定状态还是因为未能成功而被移除，所有移除操作都遵守此弃用策略。每当 API 被移除时，迁移选项都会在弃用指南中进行说明。

关于撤回 DRA 的旧的实现的说明

增强特性 #3063 在 Kubernetes 1.26 中引入了动态资源分配（DRA）。

然而，在 Kubernetes v1.32 中，这种 DRA 的实现方法将发生重大变化。与原来实现相关的代码将被删除，只留下 KEP #4381 作为"新"的基础特性。

改变现有方法的决定源于其与集群自动伸缩的不兼容性，因为资源可用性是不透明的，这使得 Cluster Autoscaler 和控制器的决策变得复杂。新增的结构化参数模型替换了原有特性。

这次移除将使 Kubernetes 能够更可预测地处理新的硬件需求和资源声明，避免了与 kube-apiserver 之间复杂的来回 API 调用。

请参阅增强问题 #3063 以了解更多信息。

API 移除

在 Kubernetes v1.32 中，计划仅移除一个 API：

flowcontrol.apiserver.k8s.io/v1beta3 版本的 FlowSchema 和 PriorityLevelConfiguration 已被移除。为了对此做好准备，你可以编辑现有的清单文件并重写客户端软件，使用自 v1.29 起可用的 flowcontrol.apiserver.k8s.io/v1 API 版本。所有现有的持久化对象都可以通过新 API 访问。flowcontrol.apiserver.k8s.io/v1beta3 中的重要变化包括：当未指定时，PriorityLevelConfiguration 的 spec.limited.nominalConcurrencyShares 字段仅默认为 30，而显式设置的 0 值不会被更改为此默认值。

有关更多信息，请参阅 API 弃用指南。

Kubernetes v1.32 的抢先预览

以下增强特性有可能会被包含在 v1.32 发布版本中。请注意，这并不是最终承诺，发布内容可能会发生变化。

Windows 工作继续

KEP #4802 为 Kubernetes 集群中的 Windows 节点添加了体面关机支持。在此之前，Kubernetes 为 Linux 节点提供了体面关机特性，但缺乏对 Windows 节点的同等支持。这一增强特性使 Windows 节点上的 kubelet 能够正确处理系统关机事件，确保在 Windows 节点上运行的 Pod 能够体面终止，从而允许工作负载在不受干扰的情况下重新调度。这一改进提高了包含 Windows 节点的集群的可靠性和稳定性，特别是在计划维护或系统更新期间。

允许环境变量中使用特殊字符

随着这一增强特性升级到 Beta 阶段， Kubernetes 现在允许几乎所有的可打印 ASCII 字符（不包括 =）作为环境变量名称。这一变化解决了此前对变量命名的限制，通过适应各种应用需求，促进了 Kubernetes 的更广泛采用。放宽的验证将通过 RelaxedEnvironmentVariableValidation 特性门控默认启用，确保用户可以轻松使用环境变量而不受严格限制，增强了开发者在处理需要特殊字符配置的应用（如 .NET Core）时的灵活性。

使 Kubernetes 感知到 LoadBalancer 的行为

KEP #1860 升级到 GA 阶段，为 type: LoadBalancer 类型的 Service 引入了 ipMode 字段，该字段可以设置为 "VIP" 或 "Proxy"。这一增强旨在改善云提供商负载均衡器与 kube-proxy 的交互方式，对最终用户来说是透明的。使用 "VIP" 时，kube-proxy 会继续处理负载均衡，保持现有的行为。使用 "Proxy" 时，流量将直接发送到负载均衡器，提供云提供商对依赖 kube-proxy 的更大控制权；这意味着对于某些云提供商，你可能会看到负载均衡器性能的提升。

为资源生成名称时重试

这一增强特性改进了使用 generateName 字段创建 Kubernetes 资源时的名称冲突处理。此前，如果发生名称冲突， API 服务器会返回 409 HTTP 冲突错误，客户端需要手动重试请求。通过此次更新， API 服务器在发生冲突时会自动重试生成新名称，最多重试七次。这显著降低了冲突的可能性，确保生成多达 100 万个名称时冲突的概率低于 0.1%，为大规模工作负载提供了更高的弹性。

想了解更多？

新特性和弃用特性也会在 Kubernetes 发布说明中宣布。我们将在此次发布的 Kubernetes v1.32 的 CHANGELOG 中正式宣布新内容。

你可以在以下版本的发布说明中查看变更公告：

Kubernetes 博客