Kubernetes v1.33 抢先看

作者：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 在每个稳定性级别都有最低的生命周期。被弃用的 API 意味着其在未来的 Kubernetes 版本中将被移除。在被移除之前（从弃用算起至少一年），该 API 将继续有效，但使用时会显示警告信息。被移除的 API 在当前版本中不再可用，届时你必须迁移到其替代 API。

  • 正式发布（GA）或稳定的 API 版本可能会被标记为已弃用，但不能在 Kubernetes 的一个大版本中移除。

  • Beta 或预发布 API 版本在弃用后必须支持 3 个版本。

  • Alpha 或实验性 API 版本可能在任何版本中被移除，而无需事先发布弃用通知；如果同一特性的不同实现已经存在，此过程可能会变成撤回。

无论一个 API 是因为特性从 Beta 阶段毕业到稳定阶段而被移除，还是因为该 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 Pod 的主机网络支持

Windows Pod 网络的目标是实现与 Linux 的功能对等，并通过允许容器使用节点的网络命名空间来提高集群密度。最初的实现作为 Alpha 版本在 v1.26 中引入，但由于遇到了意外的 containerd 行为，并且存在替代方案，Kubernetes 项目决定撤回相关的 KEP。我们预计在 v1.33 中将完全移除此支持。

你可以在 KEP-3503: Windows Pod 的主机网络支持中找到更多信息。

作为本文的作者，我们挑选了一项改进作为最值得一提的重大变化！

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

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

此支持不会影响现有的 Pod，除非你手动指定 `pod.spec.hostUsers` 来选择加入。正如在 v1.30 预览博文中所强调的，这是缓解漏洞的一个重要里程碑。

你可以在 KEP-127: 支持 Pod 中的用户命名空间中找到更多信息。

其他精选的 Kubernetes v1.33 改进

以下增强功能很可能会包含在即将发布的 v1.33 版本中。这并非承诺，发布内容可能会有变动。

用于 Pod 垂直扩缩的就地资源调整

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

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

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

你可以在 KEP-1287: 就地更新 Pod 资源中找到更多信息。

DRA 的 ResourceClaim 设备状态升级为 Beta

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

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

此外，你可以在 KEP-4817: DRA: 带有可能的标准化网络接口数据的 Resource Claim Status 中找到有关计划增强的更多信息。

有序的命名空间删除

此 KEP 引入了一种更结构化的 Kubernetes 命名空间删除过程，以确保安全和确定性的资源移除。当前半随机的删除顺序可能产生安全漏洞或意外行为，例如 Pod 在其关联的 NetworkPolicies 被删除后仍然存在。通过强制执行尊重逻辑和安全依赖关系的结构化删除顺序，此方法确保 Pod 在其他资源之前被移除。该设计通过降低与非确定性删除相关的风险，提高了 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 社区广播的吗？请在我们每周的社区会议上以及通过以下渠道分享你的声音。感谢你持续的反馈和支持。