[转载] Kubernetes v1.37 抢先看

本文为授权转载，非本账号原创。

原文：Kubernetes v1.37 抢先看（参考地址：https://kubernetes.io/zh-cn/blog/2026/07/31/kubernetes-v1-37-sneak-peek/）

原作者及译者：借由 Arsh Sharma、 Christopher Tineo、 Kirti Goyal、 Sophia Ugochukwu、 Swathi Rao、 Troy Connor | 译者 Xin Li (DaoCloud) | 2026.07.31

来源：Kubernetes 官方中文博客；许可：CC BY 4.0（参考地址：https://creativecommons.org/licenses/by/4.0/）。保留原作者和译者署名，正文仅做适配博客编辑器的排版与链接格式转换，未改写技术内容。

内容不代表原作者或 Kubernetes 项目对本账号的认可或背书。

随着 Kubernetes v1.37 发布日期的临近，项目不断发展和成熟， 为了项目的整体健康，某些特性可能会被弃用、移除或被更好的特性替代。 本文概述了 Kubernetes v1.37 版本中的一些计划内变更， 发布团队认为你应该了解这些变更，以便持续维护你的 Kubernetes 环境， 并跟上最新的变化。以下信息反映了 v1.37 版本的当前状态， 在实际发布日期之前可能会发生变化。

Kubernetes v1.37 的弃用和移除（参考地址：https://kubernetes.io/zh-cn/blog/2026/07/31/kubernetes-v1-37-sneak-peek/#kubernetes-v1-37-%e7%9a%84%e5%bc%83%e7%94%a8%e5%92%8c%e7%a7%bb%e9%99%a4）

kubectl：kubectl run --filename/-f 将被弃用（参考地址：https://kubernetes.io/zh-cn/blog/2026/07/31/kubernetes-v1-37-sneak-peek/#kubectl-kubectl-run-filename-f-%e5%b0%86%e8%a2%ab%e5%bc%83%e7%94%a8）

kubectl run 的 --filename（或 -f）参数将被弃用， 因为生成的 Pod 始终纯粹由 NAME 和 --image 等 CLI 参数构建。

原始 Issue 和讨论请参见 kubernetes/kubernetes#138671（参考地址：https://github.com/kubernetes/kubernetes/issues/138671）。

kubelet：静态 Pod 不再能引用 Secret 或 ConfigMap（参考地址：https://kubernetes.io/zh-cn/blog/2026/07/31/kubernetes-v1-37-sneak-peek/#kubelet-%e9%9d%99%e6%80%81-pod-%e4%b8%8d%e5%86%8d%e8%83%bd%e5%bc%95%e7%94%a8-secret-%e6%88%96-configmap）

静态 Pod 从未打算直接读取 API 资源，因为它们不是通过 API 服务器创建的 —— 但一个缺陷曾允许它们通过 configMapRef 或 secretRef 等字段引用 Secret 或 ConfigMap。 该缺陷现已修复：从 v1.37 起，这些引用被严格禁止， 并且先前用于绕过此限制的 PreventStaticPodAPIReferences 特性门控已被移除。

原始 Issue 和讨论请参见 kubernetes/kubernetes#140226（参考地址：https://github.com/kubernetes/kubernetes/issues/140226）。

弃用 kube-proxy 对 ipvs 模式的支持（参考地址：https://kubernetes.io/zh-cn/blog/2026/07/31/kubernetes-v1-37-sneak-peek/#%e5%bc%83%e7%94%a8-kube-proxy-%e5%af%b9-ipvs-%e6%a8%a1%e5%bc%8f%e7%9a%84%e6%94%af%e6%8c%81）

kube-proxy 对 ipvs 模式的支持是在 v1.8 中引入的，旨在解决 iptables 性能瓶颈。 然而，由于内核 ipvs API 单独无法完全实现 Kubernetes Service， ipvs 模式在底层仍继续使用 iptables （KEP-3866，“kube-proxy 的 ipvs 模式救不了我们”（参考地址：https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/3866-nftables-proxy/README.md#the-ipvs-mode-of-kube-proxy-will-not-save-us））。

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

• 到 v1.40，kube-proxy 的 ipvs 模式预计将默认禁用（仍可通过特性门控选择）
• 到 v1.43，对 ipvs 模式的支持将被完全移除 KEP-5495，毕业标准（参考地址：https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/5495-deprecate-ipvs-mode-in-kube-proxy/README.md#graduation-criteria）。

要确认你当前运行的是哪种模式，请使用：

kubectl -n kube-system get configmap kube-proxy -o jsonpath='{.data.config\.conf}' | grep 'mode:'

要了解此次弃用背后的基本原理，请参见 KEP-5495：弃用 kube-proxy 中的 ipvs 模式（参考地址：https://kubernetes.dev/resources/keps/5495）。

持续进行中的重大变更（参考地址：https://kubernetes.io/zh-cn/blog/2026/07/31/kubernetes-v1-37-sneak-peek/#%e6%8c%81%e7%bb%ad%e8%bf%9b%e8%a1%8c%e4%b8%ad%e7%9a%84%e9%87%8d%e5%a4%a7%e5%8f%98%e6%9b%b4）

未来将移除对 CGroup v1 的支持 （参考地址：https://kubernetes.io/zh-cn/blog/2026/07/31/kubernetes-v1-37-sneak-peek/#cgroup-v1-support）

随着现代 Linux 发行版和容器运行时使用 CGroup v2（参考地址：https://kubernetes.io/zh-cn/docs/concepts/architecture/cgroups/） 作为默认值， 对旧版 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 支持（参考地址：https://kubernetes.dev/resources/keps/5573）。

Kubernetes v1.37 中的破坏性变更（参考地址：https://kubernetes.io/zh-cn/blog/2026/07/31/kubernetes-v1-37-sneak-peek/#kubernetes-v1-37-%e4%b8%ad%e7%9a%84%e7%a0%b4%e5%9d%8f%e6%80%a7%e5%8f%98%e6%9b%b4）

SELinux 卷重新标记（"SELinuxMount"）进入 GA （参考地址：https://kubernetes.io/zh-cn/blog/2026/07/31/kubernetes-v1-37-sneak-peek/#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 中可能的影响）（参考地址：https://kubernetes.io/zh-cn/blog/2026/04/22/breaking-changes-in-selinux-volume-labeling/）

Kubernetes v1.37 的重点增强（参考地址：https://kubernetes.io/zh-cn/blog/2026/07/31/kubernetes-v1-37-sneak-peek/#kubernetes-v1-37-%e7%9a%84%e9%87%8d%e7%82%b9%e5%a2%9e%e5%bc%ba）

Metrics API 进入 GA（参考地址：https://kubernetes.io/zh-cn/blog/2026/07/31/kubernetes-v1-37-sneak-peek/#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 定义（参考地址：https://www.kubernetes.dev/resources/keps/5207/）。

UserNS 中的 kubelet，即 Rootless 模式（参考地址：https://kubernetes.io/zh-cn/blog/2026/07/31/kubernetes-v1-37-sneak-peek/#userns-%e4%b8%ad%e7%9a%84-kubelet-%e5%8d%b3-rootless-%e6%a8%a1%e5%bc%8f）

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

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

要了解有关此增强的更多信息，请参阅 KEP-2033：UserNS 中的 Kubelet（即 Rootless 模式）（参考地址：https://kubernetes.dev/resources/keps/4960）。

卷健康监控（参考地址：https://kubernetes.io/zh-cn/blog/2026/07/31/kubernetes-v1-37-sneak-peek/#%e5%8d%b7%e5%81%a5%e5%ba%b7%e7%9b%91%e6%8e%a7）

历史上，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：卷健康监控（参考地址：https://kubernetes.dev/resources/keps/1432）。

想了解更多？（参考地址：https://kubernetes.io/zh-cn/blog/2026/07/31/kubernetes-v1-37-sneak-peek/#%e6%83%b3%e4%ba%86%e8%a7%a3%e6%9b%b4%e5%a4%9a）

新特性和弃用也会在 Kubernetes 发布说明中公布。 我们将作为该版本 CHANGELOG 的一部分，正式公布 Kubernetes v1.37（参考地址：https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.37.md） 中的新内容。

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

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

• Kubernetes v1.36（参考地址：https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.36.md）

• Kubernetes v1.35（参考地址：https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.35.md）

• Kubernetes v1.34（参考地址：https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.34.md）

• Kubernetes v1.33（参考地址：https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.33.md）

参与其中（参考地址：https://kubernetes.io/zh-cn/blog/2026/07/31/kubernetes-v1-37-sneak-peek/#%e5%8f%82%e4%b8%8e%e5%85%b6%e4%b8%ad）

参与 Kubernetes 最简单的方式是加入众多与你兴趣相符的 特别兴趣小组（参考地址：https://kubernetes.dev/community/community-groups/sigs/）（SIG）之一。

如果你不知道从哪里开始，请加入我们每月的新贡献者入门介绍（参考地址：https://www.kubernetes.dev/docs/orientation/）， 在活动中我们会向社区介绍项目的结构，并指导你如何为项目做出首次贡献。

• 阅读更多关于如何成为 Kubernetes 贡献者（参考地址：https://www.kubernetes.dev/docs/guide/）的信息
• 在我们的博客（参考地址：https://kubernetes.io/blog/）上阅读更多关于 Kubernetes 的最新动态
• 在 Slack（参考地址：http://slack.k8s.io/） 上加入我们
• 在 X（参考地址：https://x.com/kubernetesio） 上关注我们
• 在 LinkedIn（参考地址：https://www.linkedin.com/company/kubernetes/） 上关注我们
• 在 Bluesky（参考地址：https://bsky.app/profile/kubernetes.io） 上关注我们以获取最新更新
• 在 Discuss（参考地址：https://discuss.kubernetes.io/） 上参与社区讨论
• 在 Stack Overflow（参考地址：http://stackoverflow.com/questions/tagged/kubernetes） 上提问（或回答问题）
• 分享你的 Kubernetes 最终用户故事（参考地址：https://www.cncf.io/case-studies/）
• 了解更多关于 Kubernetes 发布团队（参考地址：https://github.com/kubernetes/sig-release/tree/master/release-team）的信息

• ←上一页（参考地址：https://kubernetes.io/zh-cn/blog/2026/07/14/custom-metrics-exporter-kubernetes/）
• 下一页→（参考地址：https://kubernetes.io/zh-cn/blog/2026/08/03/gateway-api-v1-6-release/）