作者：Arsh Sharma, Christopher Tineo, Kirti Goyal, Sophia Ugochukwu, Swathi Rao, Troy Connor | 2026 年 7 月 31 日（周五）

随着 Kubernetes v1.37 发布日期临近，项目不断发展和成熟，功能可能会被弃用、移除，或被更好的功能取代，以提升项目的整体健康状况。本文概述了 Kubernetes v1.37 版本计划的变更，发布团队认为您应该了解这些变更，以便持续维护您的 Kubernetes 环境并跟上最新变化。以下信息反映了 v1.37 版本的当前状态，在正式发布日期前可能会有所变更。

Kubernetes v1.37 的弃用和移除

Kubectl：kubectl run --filename/-f 将被弃用

--filename（或 -f）标志用于 kubectl run 将被弃用，因为生成的 Pod 始终仅由 CLI 参数（如 NAME 和 --image）构建。

原始问题和讨论请参阅 kubernetes/kubernetes#138671。

Kubelet：静态 Pod 不再能引用 Secrets 或 ConfigMaps

静态 Pod 原本就不应该直接读取 API 资源，因为它们并非通过 API 服务器创建，但此前存在一个漏洞，允许它们通过 configMapRef 或 secretRef 等字段引用 Secrets 或 ConfigMaps。该漏洞现已修复：从 v1.37 开始，这些引用将被严格禁止，之前允许您选择退出限制的 PreventStaticPodAPIReferences 功能门控已被移除。

原始问题和讨论请参阅 kubernetes/kubernetes#140226。

弃用 kube-proxy 对 ipvs 模式的支持

kube-proxy 对 ipvs 模式的支持是在 v1.8 中引入的，目的是解决 iptables 的性能瓶颈。然而，由于内核 ipvs API 无法完全实现 Kubernetes Services，ipvs 模式在底层仍继续使用 iptables（KEP-3866，“kube-proxy 的 ipvs 模式无法拯救我们”）。

以 ipvs 模式（或 KubeProxyConfiguration 中的 mode: ipvs）运行 kube-proxy 的集群在启动时会记录弃用警告。弃用时间表如下：

  • 到 v1.40，ipvs 模式将默认禁用（仍可通过功能门控选择）
  • 到 v1.43，ipvs 模式的支持将被完全移除 KEP-5495，毕业标准。 要确认您当前运行的模式，请使用：
kubectl -n kube-system get configmap kube-proxy -o jsonpath='{.data.config\.conf}' | grep 'mode:'

要了解此弃用背后的原因，请参阅 KEP-5495：弃用 kube-proxy 中的 ipvs 模式。

正在进行的主要变更

未来移除 cgroup v1 支持

随着现代 Linux 发行版和容器运行时默认使用 cgroup v2，对旧版 cgroup v1 的支持正式被逐步淘汰。从 v1.35 版本开始，failCgroupV1 设置默认值为 true。因此，kubelet 将无法在任何仍依赖 cgroup v1 的节点上初始化，除非应用显式配置覆盖。

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
failCgroupV1: false # 临时覆盖

使用此覆盖应被视为短期解决方案。高级资源管理功能（如原地 Pod 调整大小和分层内存保护）完全依赖 cgroup v2。虽然该覆盖在 Kubernetes v1.37 中仍然可用，但我们鼓励用户迁移到 cgroup v2，因为对 cgroup v1 的支持计划在未来版本中移除。

要了解更多关于此弃用的信息，请参阅 KEP-5573：移除 cgroup v1 支持。

Kubernetes v1.37 中的破坏性变更

SELinux 卷重新标记（“SELinuxMount”）升级为 GA

SELinuxMount 预计将在 v1.37 中达到 GA 并默认启用。此时，卷将使用 -o context=<label>（挂载选项默认值）进行挂载，而不是递归重新标记，但仅当卷的 CSI 驱动程序通过设置 .spec seLinuxMount: true 的 CSIDriver 选择加入时才会如此。

由于单个挂载只能持有一个 SELinux 上下文，在同一节点上共享卷但具有不同 SELinux 标签的 Pod（之前在递归重新标记下可以共存）现在可能会启动失败。要为特定工作负载保留之前的递归行为，请在 Pod 规范中设置 seLinuxChangePolicy: Recursive。

未启用 SELinux 的集群不受任何影响。要了解更多信息，请参阅 SELinux 卷标签变更进入 GA（及 v1.37 中的可能影响）

Kubernetes v1.37 的特色增强

Metrics API 达到 GA

metrics.k8s.io API 预计在 Kubernetes v1.37 中经过近九年的 Beta 阶段后升级为稳定版（GA）。该 API 提供了一种检索 Pod 和节点 CPU 及内存使用情况的标准方式，为广泛使用的 Kubernetes 功能（如 Horizontal Pod Autoscaler (HPA)）和 kubectl top 等命令提供支持。

此升级认可了该 API 的稳定性和广泛采用，预计不会有功能性变更。v1 和 v1beta1 在过渡期间仍可使用，使开发者能够按自己的节奏采用稳定 API，而不会破坏现有工作流。

要了解更多关于此增强的信息，请参阅 KEP-5207：metrics.k8s.io API 定义。

Kubelet UserNS（又称 Rootless 模式）

传统上，Kubernetes 节点组件（如 kubelet）在主机上以 root 权限运行。虽然这对许多部署是必要的，但这也意味着这些组件中的漏洞可能对底层系统产生更大的影响。

在 Kubernetes v1.37 中，User Namespace 中的 kubelet（Rootless 模式）预计将升级为 Beta。此增强允许 Kubernetes 节点组件在 Linux 用户命名空间中作为主机上的非特权用户运行，同时在命名空间内仍表现为 root。通过减少对主机级 root 权限的需求，它增加了一层额外的隔离，并有助于限制潜在漏洞对节点组件的影响。

要了解更多关于此增强的信息，请参阅 KEP-2033：UserNS 中的 Kubelet（又称 Rootless 模式）。

卷健康监控

历史上，Kubernetes 缺乏一个 API 供 CSI 驱动程序报告存储故障，这些故障只有在挂载失败或 I/O 挂起时才会显现。由于修复控制器没有机器可读的数据可供操作，找出此故障根本原因的唯一方法是将 Kubernetes 对象与外部供应商仪表板进行交叉引用。

在 Kubernetes v1.37 中，此 KEP 在 v1.21 的初始实现后将毕业状态重置为 Alpha，并引入了四个新的 CSI RPC。控制器插件使用 ControllerListVolumeHealth（列出不健康的卷）和 ControllerGetVolumeHealth（检查特定卷）报告存储卷的健康状况。控制器端健康监控器轮询这些 CSI 控制器并将结果存储在 PersistentVolumeClaim.status.healthStatus 中。

在节点端，kubelet 调用 NodeGetVolumeHealth 获取该节点上单个卷的健康状况，并将其记录在 Pod.status.volumeHealth 中，而 NodeGetStorageHealth 报告注册到节点的驱动程序的健康状况，记录在 CSINode.status.storageHealth 中。

错误词汇保持简单、可扩展且可机器解析（Inaccessible、Degraded 等），通过 reason 和 message 可获得进一步的驱动程序特定详细说明。最后，控制器端和节点端的报告保持独立，因此分别显示，为使用者提供更全面的存储健康视图。

要了解更多关于此增强的信息，请参阅 KEP-1432：卷健康监控。

想了解更多？

新功能和弃用也在 Kubernetes 发布说明中公布。我们将作为该版本的 CHANGELOG 的一部分正式宣布 Kubernetes v1.37 中的新内容。

Kubernetes v1.37 计划于 2026 年 8 月 26 日（周三） 发布。敬请关注更新！

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

参与贡献

参与 Kubernetes 最简单的方式是加入与您兴趣相符的众多 特别兴趣组 (SIG) 之一。

如果您不知道从何开始，请加入我们的每月 新贡献者入门培训，我们将向社区介绍项目结构，并指导您如何为项目做出首次贡献。