Kubernetes v1.33 先睹为快

By Agustina Barbetta, Aakanksha Bhende, Udi Hofesh, Ryota Sawada, Sneha Yadav |

随着 Kubernetes v1.33 版本的临近，Kubernetes 项目持续演进。为了提升项目整体健康状况，部分特性可能会被弃用、移除或替换。这篇博文概述了 v1.33 版本的一些计划变更，发布团队认为您应该了解这些变更，以确保您的 Kubernetes 环境持续平稳运行，并及时了解最新进展。以下信息基于 v1.33 版本的当前状态，在最终发布日期之前可能发生变化。

Kubernetes API 移除和弃用流程

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

  • 正式可用 (GA) 或稳定的 API 版本可能会被标记为弃用，但在 Kubernetes 的一个主要版本内不得被移除。

  • Beta 或预发布 API 版本在弃用后必须在接下来的 3 个版本中得到支持。

  • Alpha 或实验性 API 版本可以在任何版本中移除，无需事先弃用通知；如果同一特性已有不同的实现，此过程可能变为撤销。

无论是由于特性从 Beta 升级到 Stable 而移除 API，还是因为该 API 未成功，所有移除都遵循此弃用策略。每当一个 API 被移除时，迁移选项都会在弃用指南中进行说明。

Kubernetes v1.33 的弃用和移除

稳定版 Endpoints API 的弃用

EndpointSlices API 自 v1.21 版本以来一直很稳定，它有效地取代了原始的 Endpoints API。虽然原始的 Endpoints API 简单明了，但在扩展到大量网络端点时也面临一些挑战。EndpointSlices API 引入了双栈网络等新功能，使得原始 Endpoints API 已准备好被弃用。

此弃用仅影响直接从工作负载或脚本中使用 Endpoints API 的用户；这些用户应该迁移到使用 EndpointSlices。在接下来的几周内，将有一篇专门的博文详细介绍此弃用带来的影响和迁移计划。

更多信息请参阅 KEP-4974: 弃用 v1.Endpoints。

移除节点状态中的 kube-proxy 版本信息

根据在 发布公告 中强调的 v1.31 版本弃用，status.nodeInfo.kubeProxyVersion 字段将在 v1.33 中被移除。该字段由 kubelet 设置，但其值并不总是准确。由于自 v1.31 版本以来它默认处于禁用状态，v1.33 版本将完全移除此字段。

更多信息请参阅 KEP-4004: 弃用 status.nodeInfo.kubeProxyVersion 字段。

移除对 Windows Pods 的主机网络支持

Windows Pod 网络旨在实现与 Linux 的特性对等，并通过允许容器使用节点的网络命名空间来提高集群密度。原始实现随 v1.26 作为 Alpha 功能发布，但由于遇到意外的 containerd 行为并且已有替代解决方案，Kubernetes 项目决定撤销相关的 KEP。我们预计将在 v1.33 版本中完全移除此支持。

更多信息请参阅 KEP-3503: 对 Windows Pods 的主机网络支持。

作为本文作者，我们挑选了一项改进作为最重要的变更来重点介绍！

Linux Pods 内的用户命名空间支持

当今最古老的开放 KEP 之一是 KEP-127，通过为 Pods 使用 Linux 用户命名空间来改进 Pod 安全性。此 KEP 于 2016 年底首次开放，经过多次迭代后，在 v1.25 中发布了 Alpha 版本，在 v1.30 中发布了初始 Beta 版本（当时默认禁用），现在预计将成为 v1.33 的一部分，在该版本中此功能将默认可用。

除非您手动指定 pod.spec.hostUsers 选择启用，否则此支持不会影响现有的 Pods。正如在v1.30 抢先看博文中强调的，这是减轻漏洞风险的重要里程碑。

更多信息请参阅 KEP-127: 在 Pods 中支持用户命名空间。

精选的其他 Kubernetes v1.33 改进

以下增强功能列表很可能会包含在即将发布的 v1.33 版本中。这不是承诺，发布内容可能会发生变化。

用于 Pods 垂直伸缩的原地资源调整大小

配置 Pod 时，您可以使用各种资源，例如 Deployment、StatefulSet 等。伸缩性需求可能需要通过更新 Pod 副本数量进行水平伸缩，或通过更新分配给 Pod 容器的资源进行垂直伸缩。在此增强之前，Pod 的 spec 中定义的容器资源是不可变的，更新 Pod 模板中的任何这些详细信息都会触发 Pod 替换。

但是，如果您可以在不重启现有 Pods 的情况下动态更新其资源配置呢？

KEP-1287 正是为了允许这种原地 Pod 更新。它为有状态进程的垂直扩容提供了各种可能性，无需停机，可在流量低时无缝缩容，甚至可以在启动期间分配更大的资源，并在初始设置完成后最终减少。此功能在 v1.27 中作为 Alpha 版本发布，预计将在 v1.33 中作为 Beta 版本落地。

更多信息请参阅 KEP-1287: 原地更新 Pod 资源。

DRA 的 ResourceClaim 设备状态升级至 Beta

ResourceClaim 的 status 中的 devices 字段，最初在 v1.32 版本中引入，很可能会在 v1.33 中升级至 Beta。此字段允许驱动程序报告设备状态数据，从而改进可观测性和故障排除能力。

例如，在 ResourceClaim 的状态中报告网络接口的接口名称、MAC 地址和 IP 地址，对于配置和管理网络服务以及调试网络相关问题具有重要帮助。您可以在动态资源分配：ResourceClaim 设备状态文档中阅读更多关于 ResourceClaim 设备状态的信息。

此外，您可以在KEP-4817: DRA: 具有可能的标准化网络接口数据的资源声明状态中找到更多关于此计划增强的信息。

有序命名空间删除

此 KEP 引入了更结构化的 Kubernetes 命名空间删除流程，以确保安全且确定性的资源移除。当前半随机的删除顺序可能导致安全漏洞或意外行为，例如相关 NetworkPolicy 删除后 Pods 仍然存在。通过强制执行遵循逻辑和安全依赖关系的结构化删除顺序，此方法确保 Pods 在其他资源之前被移除。此设计通过减轻与非确定性删除相关的风险，提高了 Kubernetes 的安全性和可靠性。

更多信息请参阅 KEP-5080: 有序命名空间删除。

索引 Job 管理增强功能

这两个 KEP 都计划升级至 GA，以提供更好的 Job 处理可靠性，特别是针对索引 Job。KEP-3850 为索引 Job 提供每索引的退避限制，这使得每个索引完全独立于其他索引。此外，KEP-3998 扩展了 Job API，以定义当并非所有索引都成功时，使索引 Job 视为成功完成的条件。

更多信息请参阅 KEP-3850: 索引 Job 的每索引退避限制 和 KEP-3998: Job 成功/完成策略。

想了解更多？

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

Kubernetes v1.33 版本计划于 2025 年 4 月 23 日 星期三 发布。敬请关注更新！

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

参与其中

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