Kubernetes v1.33 版本来了！

作者：Agustina Barbetta, Aakanksha Bhende, Udi Hofesh, Ryota Sawada, Sneha Yadav

译者：Xin Li[1] (DaoCloud)

随着 Kubernetes v1.33 版本的发布临近，Kubernetes 项目仍在不断发展。 为了提升项目的整体健康状况，某些特性可能会被弃用、移除或替换。 这篇博客文章概述了 v1.33 版本的一些计划变更，发布团队认为你有必要了解这些内容， 以确保 Kubernetes 环境的持续平稳运行，并让你掌握最新的发展动态。 以下信息基于 v1.33 版本的当前状态，在最终发布日期之前可能会有所变化。

Kubernetes API 的移除与弃用流程

Kubernetes 项目针对特性的弃用有一套完善的弃用政策[2]。 该政策规定，只有在有更新的、稳定的同名 API 可用时，才能弃用稳定的 API， 并且每个稳定性级别的 API 都有最低的生命周期要求。被弃用的 API 已被标记为将在未来的 Kubernetes 版本中移除。在移除之前（自弃用起至少一年内），它仍然可以继续使用， 但使用时会显示警告信息。已被移除的 API 在当前版本中不再可用，届时你必须迁移到使用替代方案。

  • 一般可用（GA）或稳定 API 版本可以被标记为已弃用，但在 Kubernetes 的一个主要版本内不得移除。
  • 测试版或预发布 API 版本在弃用后必须支持至少三个发行版本。
  • Alpha 或实验性 API 版本可以在任何版本中被移除，且无需事先发出弃用通知； 如果同一特性已经有了不同的实现，这个过程可能会变为撤回。

无论是由于某个特性从测试阶段升级为稳定阶段而导致 API 被移除，还是因为该 API 未能成功，所有的移除操作都遵循此弃用政策。每当一个 API 被移除时， 迁移选项都会在弃用指南[3]中进行说明。

Kubernetes v1.33 的弃用与移除

稳定版 Endpoints API 的弃用

EndpointSlices[4] API 自 v1.21 起已稳定，实际上取代了原有的 Endpoints API。虽然原有的 Endpoints API 简单直接， 但在扩展到大量网络端点时也带来了一些挑战。EndpointSlices API 引入了诸如双栈网络等新特性， 使得原有的 Endpoints API 已准备好被弃用。

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

你可以在 KEP-4974: Deprecate v1.Endpoints[5]中找到更多信息。

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

继在 v1.31 中被弃用，并在发布说明[6]中强调后，status.nodeInfo.kubeProxyVersion 字段将在 v1.33 中被移除。 此字段由 kubelet 设置，但其值并不总是准确的。由于自 v1.31 起该字段默认已被禁用，v1.33 发行版将完全移除此字段。

你可以在 KEP-4004: Deprecate status.nodeInfo.kubeProxyVersion field[7]中找到更多信息。

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

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

你可以在 KEP-3503: Host network support for Windows pods[8]中找到更多信息。

Kubernetes v1.33 的特色改进

作为本文的作者，我们挑选了一项改进作为最重要的变更来特别提及！

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

当前最古老的开放 KEP 之一是 KEP-127[9]， 通过使用 Linux 用户命名空间[10]为 Pod 提供安全性改进。该 KEP 最初在 2016 年末提出，经过多次迭代，在 v1.25 中发布了 Alpha 版本， 在 v1.30 中首次进入 Beta 阶段（在此版本中默认禁用），现在它将成为 v1.33 的一部分， 默认情况下即可使用该特性。

除非你手动指定 pod.spec.hostUsers 以选择使用此特性，否则此支持不会影响现有的 Pod。 正如在 v1.30 预览博客[11]中强调的那样， 就缓解漏洞的影响而言，这是一个重要里程碑。

你可以在 KEP-127: Support User Namespaces in pods[12]中找到更多信息。

精选的其他 Kubernetes v1.33 改进

以下列出的改进很可能会包含在即将到来的 v1.33 发行版中。 这些改进尚无法承诺，发行内容仍有可能发生变化。

Pod 垂直扩展的就地资源调整

在制备某个 Pod 时，你可以使用诸如 Deployment、StatefulSet 等多种资源。 为了满足可扩缩性需求，可能需要通过更新 Pod 副本数量进行水平扩缩，或通过更新分配给 Pod 容器的资源进行垂直扩缩。在此增强特性之前，Pod 的 spec中定义的容器资源是不可变的，更新 Pod 模板中的这类细节会触发 Pod 的替换。

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

KEP-1287[13] 正是为了实现这种就地 Pod 更新而设计的。 它为无状态进程的垂直扩缩开辟了多种可能性，例如在不停机的情况下进行扩容、 在流量较低时无缝缩容，甚至在启动时分配更多资源，待初始设置完成后减少资源分配。 该特性在 v1.27 中以 Alpha 版本发布，并预计在 v1.33 中进入 beta 阶段。

你可以在 KEP-1287：Pod 资源的就地更新[14]中找到更多信息。

DRA 的 ResourceClaim 设备状态升级为 Beta

在 v1.32 版本中首次引入的 ResourceClaim status 中的 devices 字段， 预计将在 v1.33 中升级为 beta 阶段。此字段允许驱动程序报告设备状态数据， 从而提升可观测性和故障排查能力。

例如，在 ResourceClaim 的状态中报告网络接口的接口名称、MAC 地址和 IP 地址， 可以显著帮助配置和管理网络服务，并且在调试网络相关问题时也非常有用。 你可以在动态资源分配：ResourceClaim 设备状态[15]文档中阅读关于 ResourceClaim 设备状态的更多信息。

此外，你可以在KEP-4817: DRA: Resource Claim Status with possible standardized network interface data[16]中找到更多关于此计划增强特性的信息。

有序的命名空间删除

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

你可以在 KEP-5080: Ordered namespace deletion[17]中找到更多信息。

针对带索引作业（Indexed Job）管理的增强

这两个 KEP 都计划升级为 GA，以提供更好的作业处理可靠性，特别是针对索引作业。KEP-3850[18] 为索引作业中的不同索引分别支持独立的回退限制， 这使得每个索引可以完全独立于其他索引。此外，KEP-3998[19]扩展了 Job API，定义了在并非所有索引都成功的情况下将索引作业标记为成功完成的条件。

你可以在 KEP-3850: Backoff Limit Per Index For Indexed Jobs[20] 和KEP-3998: Job success/completion policy[21] 中找到更多信息。

想了解更多？

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

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

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

  • Kubernetes v1.32[23]
  • Kubernetes v1.31[24]
  • Kubernetes v1.30[25]

参与进来

参与 Kubernetes 最简单的方式是加入与你兴趣相符的众多特别兴趣小组[26]（SIG） 之一。你有什么想向 Kubernetes 社区广播的内容吗？ 通过我们每周的社区会议[27]和以下渠道分享你的声音。 感谢你持续的反馈和支持。

  • 在 Bluesky 上关注我们 @kubernetes.io[28] 以获取最新更新
  • 在 Discuss[29] 上参与社区讨论
  • 在 Slack[30] 上加入社区
  • 在 Server Fault[31] 或Stack Overflow[32] 上提问（或回答问题）
  • 分享你的 Kubernetes 故事[33]
  • 在博客[34]上阅读更多关于 Kubernetes 最新动态的内容
  • 了解更多关于 Kubernetes 发布团队[35]的信息

参考资料

[1]

Xin Li:

[2]

弃用政策: /

[3]

弃用指南: /

[4]

EndpointSlices: /

[5]

KEP-4974: Deprecate v1.Endpoints:

[6]

发布说明:

[7]

KEP-4004: Deprecate status.nodeInfo.kubeProxyVersion field:

[8]

KEP-3503: Host network support for Windows pods:

[9]

KEP-127:

[10]

用户命名空间: /

[11]

v1.30 预览博客: /

[12]

KEP-127: Support User Namespaces in pods:

[13]

KEP-1287:

[14]

KEP-1287：Pod 资源的就地更新:

[15]

动态资源分配：ResourceClaim 设备状态:

[16]

KEP-4817: DRA: Resource Claim Status with possible standardized network interface data:

[17]

KEP-5080: Ordered namespace deletion:

[18]

KEP-3850:

[19]

KEP-3998:

[20]

KEP-3850: Backoff Limit Per Index For Indexed Jobs:

[21]

KEP-3998: Job success/completion policy:

[22]

Kubernetes v1.33: .33.md

[23]

Kubernetes v1.32: .32.md

[24]

Kubernetes v1.31: .31.md

[25]

Kubernetes v1.30: .30.md

[26]

特别兴趣小组: .md

[27]

社区会议:

[28]

@kubernetes.io: /profile/kubernetes.io

[29]

Discuss: /

[30]

Slack: /

[31]

Server Fault:

[32]

Stack Overflow:

[33]

故事: /forms/d/e/1FAIpQLScuI7Ye3VQHQTwBASrgkjQDSS5TP0g3AXfFhwSM9YpHgxRKFA/viewform

[34]

博客: /

[35]

Kubernetes 发布团队:

本文参与 腾讯云自媒体同步曝光计划，分享自微信公众号。原始发表：2025-03-30，如有侵权请联系 cloudcommunity@tencent 删除kuberneteshttps博客索引网络