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

Kubernetes API 的移除与弃用流程

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

• 一般可用（GA）或稳定 API 版本可以被标记为已弃用，但在 Kubernetes 的一个主要版本内不得移除。

• 测试版或预发布 API 版本在弃用后必须支持至少三个发行版本。

• Alpha 或实验性 API 版本可以在任何版本中被移除，且无需事先发出弃用通知； 如果同一特性已经有了不同的实现，这个过程可能会变为撤回。

无论是由于某个特性从测试阶段升级为稳定阶段而导致 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: Deprecate v1.Endpoints 中找到更多信息。

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

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

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

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

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

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

Kubernetes v1.33 的特色改进

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

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

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

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

精选的其他 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 with possible standardized network interface data 中找到更多关于此计划增强特性的信息。

有序的命名空间删除

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

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

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

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

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