Kubernetes v1.32 抢先看

作者：Matteo Bianchi、Edith Puclla、William Rizzo、Ryota Sawada、Rashan Smith | 2024 年 11 月 8 日，星期五

随着 Kubernetes v1.32 发布日期的临近，该项目也在不断发展和成熟。为了项目的整体健康，一些功能可能会被弃用、移除或被更好的功能所取代。

这篇博客概述了 Kubernetes v1.32 版本中一些计划中的变更，发布团队认为您应该了解这些变更，以便持续维护您的 Kubernetes 环境并跟上最新的变化。下面列出的信息基于 v1.32 版本的当前状态，在实际发布日期前可能会有所变动。

Kubernetes API 移除和弃用流程

Kubernetes 项目对功能特性有明确的弃用策略。该策略规定，只有在有更新、更稳定的 API 版本可用时，才能弃用稳定的 API，并且 API 在每个稳定性级别都有最低生命周期。被弃用的 API 已被标记为将在未来的 Kubernetes 版本中移除，在移除之前（从弃用之日起至少一年）将继续运行。使用它将显示警告。被移除的 API 在当前版本中不再可用，因此您必须迁移到使用替代的 API。

正式发布（GA）或稳定的 API 版本可能会被标记为已弃用，但不能在 Kubernetes 的一个大版本中移除。
Beta 或预发布 API 版本在弃用后必须支持 3 个版本。
Alpha 或实验性 API 版本可以在任何版本中被移除，而无需事先发出弃用通知；如果同一功能已经有了不同的实现，这个过程可能会变成一种撤回。

无论是由于功能从 Beta 升级到稳定版而移除 API，还是因为该 API 未能成功，所有移除都遵循此弃用策略。每当移除 API 时，都会在弃用指南中传达迁移方案。

关于撤回旧 DRA 实现的说明

增强提案 #3063 在 Kubernetes 1.26 中引入了动态资源分配 (DRA)。

然而，在 Kubernetes v1.32 中，这种 DRA 的方法将发生重大变化。与原始实现相关的代码将被移除，留下 KEP #4381 作为“新”的基础功能。

改变现有方法的决定源于它与集群自动扩缩的不兼容性，因为资源可用性不透明，这使得集群自动扩缩器和控制器的决策变得复杂。新添加的结构化参数模型取代了该功能。

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

另请参阅增强提案#3063以了解更多信息。

API 移除

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

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

有关更多信息，请参阅 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 的现有行为得以保留，由 kube-proxy 处理负载均衡。使用 "Proxy" 则会将流量直接发送到负载均衡器，从而使云提供商在依赖 kube-proxy 方面拥有更大的控制权；这意味着对于某些云提供商，您可能会看到负载均衡器性能的提升。

为资源重试生成名称

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

想了解更多吗？

新功能和弃用信息也会在 Kubernetes 发布说明中公布。我们将在 Kubernetes v1.32 的 CHANGELOG 中正式宣布该版本的新特性。

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

Kubernetes 博客