Kubernetes V1.37 抢先看：弃用三件与升级前体检

  • 2026/8/2
  • 阅读时间 2 分钟
目录

官方博客刚发了 Kubernetes v1.37 Sneak Peek，正式版计划是 2026 年 8 月 26 日 星期三

预告内容更像一份升级前体检单：哪些命令要废除、哪些行为策略会突然变严、哪些能力终于稳定了。比单纯记新名词有用。下面先排雷、再看硬货；细节以官方正式 CHANGELOG 为准

要弃用那些？

升级时真正容易踩坑的，往往不是新功能，而是有些参数要弃用。v1.37 预告里有三件要先查

1. kubectl run -f 要弃用

kubectl run 生成的 Pod 本来就只认命令行参数（名字、镜像等），带 -f 容易让人以为能像 apply 一样吃完整清单。官方打算弃用这个参数

脚本里若还有 kubectl run -f …，改成 kubectl apply -f，或改用正经的 Deployment / Job 清单

2. Static Pod 不能再引用 Secret / ConfigMap

Static Pod：由 kubelet 直接根据本机清单文件拉起的 Pod，不经过 API Server 调度创建。常见于控制面组件（如放在 /etc/kubernetes/manifests 里的 apiserver、etcd）。它出现在 API 里多半是镜像（mirror Pod），真正生命周期仍由本机 kubelet 管理

Static Pod 不经 API Server 创建，本来就不该直接读 API 对象。以前有条能挂上的歪路，现在修死了：v1.37 起严格禁止通过 secretRef / configMapRef 一类字段引用 Secret、ConfigMap；曾经用来放行的 feature gate 也一并移除

动作很具体：查一遍 /etc/kubernetes/manifests（以及你们自定义的 static pod 目录）。还在挂 Secret / ConfigMap 的，要么改成普通 Pod / DaemonSet 走 API，要么接受 static 的边界，把配置落到本地文件或主机路径

3. kube-proxy 的 IPVS 模式开始打弃用警告

当年引入 IPVS，是为了缓解 iptables 的性能问题。但内核 IPVS API 单独撑不起完整 Service 语义，IPVS 模式底下其实还在用 iptables——社区早就写过这个结论

预告节奏大概是：现在启动打警告 → 约 v1.40 默认关闭（仍可能用 feature gate 打开）→ 约 v1.43 整段移除。先确认自己是不是还在跑 IPVS：

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

若是 mode: ipvs，开始规划迁回 iptables，或评估 nftables 等当前主路径，别等到被硬砍

大趋势：cgroup v1 继续退场

从 v1.35 起，kubelet 默认 failCgroupV1: true。节点还在 cgroup v1 时，kubelet 可能直接起不来，除非临时覆盖：

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
failCgroupV1: false  # 仅短期过渡

v1.37 仍允许这个开关，但官方态度很清楚：这是短期补丁，尽快迁到 cgroup v2。原地调整资源、分级内存保护等能力，都绑在 v2 上；靠 false 硬撑只会越来越吃力

破坏性变更：SELinuxMount 预计 GA

若集群启用了 SELinux，这项要单独过一遍逻辑

SELinuxMount 预计在 v1.37 GA 并默认开启。对声明了 CSIDriver.spec.seLinuxMount: true 的卷，会用挂载选项 -o context=标签 打标签，而不再整卷递归打标。一个挂载点只能有一个 SELinux context——以前不同标签的 Pod 还能靠递归打标凑合共享同一卷，现在可能直接起不来

个别工作负载想保留旧行为，可在 Pod 上设 seLinuxChangePolicy: Recursive。没开 SELinux 的集群基本无感；开了 SELinux、又有多标签共享卷的，升级前务必在测试环境验证一轮

值得关注的 3 个点

排完雷之后，再看三个方向信号——分别对应可观测、节点安全边界、存储故障可编排

1. metrics.k8s.io 终于 GA

将近九年 Beta，metrics.k8s.io 预计在 v1.37 转 Stable。它是 HPA 和 kubectl top 的底座。功能上预计无大改；v1 与 v1beta1 过渡期都会能用，方便按自己节奏切稳定版

2. Rootless kubelet（UserNS）进 Beta

节点组件（含 kubelet）传统上常以宿主机 root 跑，出事面大。v1.37 预计把 Kubelet in User Namespace（Rootless Mode）推到 Beta：节点组件在 Linux user namespace 里当命名空间内的 root，宿主机侧可以是非特权用户——多一层隔离，缩小组件漏洞的冲击面

适合对节点安全边界敏感、愿意跟 Beta 的环境；生产要跟发行版和运行时成熟度一起评估，别一刀切全上

3. Volume Health Monitor 重回 Alpha

存储坏了，以前多半从挂不上、IO 卡住反推，还要对照厂商控制台。这轮把卷健康监控 KEP 重置为 Alpha（早年有过实现），补一组 CSI RPC，并把结果写回 API：PVC 的 status.healthStatus、Pod 的 status.volumeHealth、CSINode 的 status.storageHealth

错误词表偏机器可读（如 Inaccessible、Degraded），细节走 reason / message；控制器侧与节点侧报告分开展示，方便对症。方向是让存储故障可编排——现在仍是 Alpha，适合跟驱动进度，别急着当生产告警的唯一源

升级前五分钟

按上面的逻辑，动手前可以快速过一遍：

  1. 脚本里还有没有 kubectl run -f
  2. Static Pod 是否还挂 Secret / ConfigMap
  3. kube-proxy 是不是还在 ipvs
  4. 节点是否仍靠 failCgroupV1: false 硬撑 cgroup v1
  5. 开了 SELinux 的：有没有多标签共享同一卷

Sneak Peek 的价值，不在背名词，而在升级窗口前把坑标在日历上。真会踩坑的，多半是 Static Pod、IPVS、SELinux 挂载这几件——新功能可以慢慢跟，这三件建议尽快就查

正式能力与时间表，仍以 8 月 26 日 CHANGELOG 为准。

原文：Kubernetes v1.37 Sneak Peek

类似的帖子

技术 Kubernetes云原生运维升级

评论