Kubernetes v1.37 抢先看
随着 Kubernetes v1.37 发布日期的临近，项目不断发展和成熟， 为了项目的整体健康，某些特性可能会被弃用、移除或被更好的特性替代。 本文概述了 Kubernetes v1.37 版本中的一些计划内变更， 发布团队认为你应该了解这些变更，以便持续维护你的 Kubernetes 环境， 并跟上最新的变化。以下信息反映了 v1.37 版本的当前状态， 在实际发布日期之前可能会发生变化。
Kubernetes v1.37 的弃用和移除
kubectl：kubectl run --filename/-f 将被弃用
kubectl run 的 --filename（或 -f）参数将被弃用，
因为生成的 Pod 始终纯粹由 NAME 和 --image 等 CLI 参数构建。
原始 Issue 和讨论请参见 kubernetes/kubernetes#138671。
kubelet：静态 Pod 不再能引用 Secret 或 ConfigMap
静态 Pod 从未打算直接读取 API 资源，因为它们不是通过 API 服务器创建的 ——
但一个缺陷曾允许它们通过 configMapRef 或 secretRef 等字段引用 Secret 或 ConfigMap。
该缺陷现已修复：从 v1.37 起，这些引用被严格禁止，
并且先前用于绕过此限制的 PreventStaticPodAPIReferences 特性门控已被移除。
原始 Issue 和讨论请参见 kubernetes/kubernetes#140226。
弃用 kube-proxy 对 ipvs 模式的支持
kube-proxy 对 ipvs 模式的支持是在 v1.8 中引入的，旨在解决 iptables 性能瓶颈。
然而，由于内核 ipvs API 单独无法完全实现 Kubernetes Service，
ipvs 模式在底层仍继续使用 iptables
（KEP-3866，“kube-proxy 的 ipvs 模式救不了我们”）。
在 ipvs 模式下（或在 KubeProxyConfiguration 中设置 mode: ipvs）运行 kube-proxy 的集群，
现在会在启动时记录一条弃用警告。弃用时间表如下：
- 到 v1.40，
kube-proxy的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 调整大小（In-Place Pod Resizing）和 分层内存保护（Tiered Memory Protection），完全依赖于 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 在 Beta 阶段停留近九年后，
预计将在 Kubernetes v1.37 中毕业至稳定版（GA）。
该 API 提供了一种标准方式来检索 Pod 和节点的 CPU 和内存使用情况，
为广泛使用的 Kubernetes 特性（例如水平 Pod 自动扩缩器（HPA））
以及 kubectl top 等命令提供支持。
此次毕业认可了该 API 的稳定性和广泛采用，预计不会有功能性变更。
在过渡期间，v1 和 v1beta1 都将继续可用，
使开发者能够按自己的节奏采用稳定版 API，而不会破坏现有工作流。
要了解有关此增强的更多信息，请参阅 KEP-5207：metrics.k8s.io API 定义。
UserNS 中的 kubelet，即 Rootless 模式
传统上，Kubernetes 节点组件（例如 kubelet）在主机上以 root 特权运行。
虽然这对许多部署是必要的，但这也意味着这些组件中某个组件的漏洞可能会对底层系统产生更大的影响。
在 Kubernetes v1.37 中，用户命名空间中的 kubelet （即 Rootless 模式）预计将毕业至 Beta。 此增强允许 Kubernetes 节点组件在 Linux 用户命名空间内以主机上的非特权用户身份运行， 同时在命名空间内仍表现为 root。 通过减少对主机级 root 特权的需求，它增加了一层额外的隔离， 并有助于限制影响节点组件的潜在漏洞的影响范围。
要了解有关此增强的更多信息，请参阅 KEP-2033：UserNS 中的 Kubelet（即 Rootless 模式）。
卷健康监控
历史上，Kubernetes 一直缺乏一个供 CSI 驱动报告存储故障的 API， 这些故障仅通过挂载失败或 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）之一。
如果你不知道从哪里开始，请加入我们每月的新贡献者入门介绍， 在活动中我们会向社区介绍项目的结构，并指导你如何为项目做出首次贡献。
- 阅读更多关于如何成为 Kubernetes 贡献者的信息
- 在我们的博客上阅读更多关于 Kubernetes 的最新动态
- 在 Slack 上加入我们
- 在 X 上关注我们
- 在 LinkedIn 上关注我们
- 在 Bluesky 上关注我们以获取最新更新
- 在 Discuss 上参与社区讨论
- 在 Stack Overflow 上提问（或回答问题）
- 分享你的 Kubernetes 最终用户故事
- 了解更多关于 Kubernetes 发布团队的信息