Kubernetes v1.37 升级前瞻：IPVS 退场、cgroup v2 迁移与 SELinuxMount GA

Kubernetes v1.37 计划于 2026 年 8 月 26 日发布。相比单纯增加 API，这一版本更值得平台团队关注的是几项运行时约束变化：静态 Pod 不再允许引用 Secret 或 ConfigMap，kube-proxy 的 IPVS 模式进入退场周期，cgroup v1 的兼容窗口继续收窄，而 SELinux 卷挂载策略可能直接改变部分 Pod 的启动结果。

本文依据发布前信息整理，因此功能状态、Feature Gate 和最终时间线仍可能在正式发布前调整。升级决策应以 v1.37 最终 CHANGELOG 和发行说明为准。

三项需要提前清理的兼容性问题

kubectl run -f 将被弃用

kubectl run 生成 Pod 时，实际对象始终由名称、镜像等命令行参数构造，因此 --filename 和 -f 参数将被弃用。

依赖清单文件创建资源时，应直接使用：

kubectl apply -f pod.yaml

临时启动一个 Pod，则继续使用参数式调用：

kubectl run toolbox \
  --image=busybox:1.36 \
  --restart=Never \
  --command -- sleep 3600

升级前可以扫描脚本和 CI 配置，找出仍在使用这一组合的地方：

rg -n --glob '*.sh' --glob '*.yaml' --glob '*.yml' \
  'kubectl[[:space:]]+run.*(--filename|-f)([=[:space:]]|$)' .

这里需要区分 kubectl run -f 与合法的 kubectl apply -f，不要进行全局机械替换。

静态 Pod 不能再读取 API 对象

静态 Pod 由 kubelet 直接管理，不经过 API Server 创建。过去由于实现缺陷，静态 Pod 清单可以通过 configMapRef、secretRef 等字段引用 Secret 或 ConfigMap；v1.37 将严格禁止这种引用，同时删除此前用于退出该限制的 PreventStaticPodAPIReferences Feature Gate。

升级前应检查每个节点的静态 Pod 清单目录。常见目录是 /etc/kubernetes/manifests，但实际路径应以 kubelet 的 staticPodPath 配置为准：

sudo rg -n \
  'configMapRef|secretRef|configMapKeyRef|secretKeyRef|configMap:|secret:' \
  /etc/kubernetes/manifests

发现引用后，不要简单把敏感数据写进静态 Pod YAML。可以这样实践：由节点配置管理系统把文件安全地下发到主机，再通过受限的 hostPath 挂载；或者把工作负载改成由 API Server 管理的普通 Pod、Deployment 或 DaemonSet。前一种方案会引入节点密钥轮换和文件权限管理成本，后一种方案则会改变组件的启动依赖，需要按控制面可用性要求评估。

kube-proxy 的 IPVS 模式开始退场

IPVS 模式最初用于缓解 iptables 的性能瓶颈，但它无法仅依靠内核 IPVS API 完整实现 Kubernetes Service，实际仍依赖 iptables。v1.37 中，使用 IPVS 的 kube-proxy 预计会在启动时输出弃用警告。

当前计划是：

• v1.40 默认禁用 IPVS 模式，但仍可通过 Feature Gate 选择。
• v1.43 完全移除 IPVS 支持。

先检查集群当前使用的模式：

kubectl -n kube-system get configmap kube-proxy \
  -o jsonpath='{.data.config\.conf}' | sed -n '/^[[:space:]]*mode:/p'

如果结果是 mode: ipvs，现在还不必仓促切换生产集群，但应该建立替代方案的基准测试。迁移 kube-proxy 数据平面会影响 Service 转发、连接保持、NodePort、外部流量策略和网络策略集成，不能只验证“Pod 能否访问 Service”。

cgroup v1：临时开关仍在，但迁移已经不能再拖

从 Kubernetes v1.35 开始，failCgroupV1 默认值已经是 true。仍运行 cgroup v1 的节点会导致 kubelet 初始化失败，除非显式配置临时覆盖：

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
failCgroupV1: false

这只能作为短期缓冲。原地调整 Pod 资源和分层内存保护等能力完全依赖 cgroup v2，而且 cgroup v1 支持计划在未来版本中删除。

可以在节点上执行以下命令判断 cgroup 版本：

#!/usr/bin/env bash
set -euo pipefail

if [[ -f /sys/fs/cgroup/cgroup.controllers ]]; then
  echo 'cgroup v2 detected'
  cat /sys/fs/cgroup/cgroup.controllers
else
  echo 'cgroup v1 detected: migration is required'
  exit 1
fi

迁移时需要同时核对 Linux 发行版、内核、systemd、容器运行时和 kubelet 的 cgroup driver。建议先建立一组 v2 节点，迁移无状态工作负载并观察 CPU 限流、内存压力、OOM、监控指标和设备插件，再逐步替换旧节点。直接在原节点原地切换会扩大回滚难度。

SELinuxMount GA 带来的行为变化

SELinuxMount 预计在 v1.37 进入 GA 并默认启用。对于通过 CSIDriver.spec.seLinuxMount: true 明确选择支持该能力的 CSI 驱动，Kubernetes 会使用 -o context=<label> 挂载卷，而不是递归修改卷内文件标签。

挂载参数通常比递归 relabel 更高效，但一个挂载点只能拥有一个 SELinux context。此前能够在同一节点共享卷、但使用不同 SELinux 标签的 Pod，升级后可能无法同时启动。未启用 SELinux 的集群不受影响。

对必须保留旧行为的工作负载，可以这样实践，在 Pod 的安全上下文中显式要求递归处理：

apiVersion: v1
kind: Pod
metadata:
  name: selinux-recursive-example
spec:
  securityContext:
    seLinuxChangePolicy: Recursive
  containers:
    - name: app
      image: registry.k8s.io/pause:3.10
      volumeMounts:
        - name: data
          mountPath: /data
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: shared-data

运行前需要把 shared-data 改成现有 PVC，并确认目标 Kubernetes 版本接受该字段。该设置应针对具体工作负载使用，而不是作为集群级默认补丁，否则会失去挂载式标签处理的性能收益。

还应检查 CSI 驱动是否声明支持 SELinux mount：

kubectl get csidriver \
  -o custom-columns='NAME:.metadata.name,SELINUX_MOUNT:.spec.seLinuxMount'

三项值得跟踪的新能力

Metrics API 进入稳定阶段

metrics.k8s.io 在 Beta 阶段运行近九年后，预计升级为 GA。它为节点和 Pod 的 CPU、内存使用量提供标准读取方式，也是 HPA 与 kubectl top 的基础。此次升级预计没有功能行为变化，v1 与 v1beta1 会在迁移期并存。

在安装并正常运行 Metrics Server 的集群中，可以直接检查 API discovery：

kubectl get --raw /apis/metrics.k8s.io | jq '.preferredVersion, .versions'
kubectl get --raw /apis/metrics.k8s.io/v1/nodes | jq '.items[0].usage'

在 v1.37 正式发布前，第二条命令可能需要继续使用 /apis/metrics.k8s.io/v1beta1/nodes。GA 不代表集群会自动安装 Metrics Server，也不意味着这一 API 能替代 Prometheus 等长期监控系统；它提供的是自动伸缩和即时查询所需的资源指标。

Rootless kubelet 预计进入 Beta

kubelet 在 User Namespace 中运行的能力预计升级到 Beta。节点组件可以在用户命名空间内部表现为 root，同时在宿主机上保持非特权用户身份，从而缩小组件漏洞对宿主机的影响范围。

这不是一个只切换开关就能完成的安全加固项目。CSI、CNI、设备插件、主机目录、特权容器以及依赖宿主机 namespace 的运维组件都可能受到影响。适合先在专用节点池验证，不宜直接覆盖 GPU、存储或复杂网络节点。

Volume Health Monitor 重新以 Alpha 推进

卷健康监控方案在 v1.37 重新调整为 Alpha，并引入控制器侧与节点侧的 CSI 健康检查 RPC。设计目标是把 Inaccessible、Degraded 等机器可读状态写入 PVC、Pod 和 CSINode 的状态中，同时保留 reason 与 message 供驱动补充细节。

这会让自动修复控制器不必只依赖 mount 失败事件或厂商控制台。不过 Alpha API、字段和 CSI RPC 仍可能变化，生产系统不应立即把自动删除 Pod、迁移卷等破坏性动作绑定到单一健康状态。更稳妥的做法是先接入只读告警，联合节点侧和控制器侧报告进行判断。

升级前的执行清单

• 扫描仓库，替换所有 kubectl run -f 调用。
• 检查各节点 staticPodPath，清除对 Secret 和 ConfigMap 的引用。
• 确认 kube-proxy 模式；若为 IPVS，为 v1.40 前的迁移建立测试计划。
• 盘点所有节点的 cgroup 版本，将 failCgroupV1: false 仅作为临时措施。
• 列出设置了 seLinuxMount: true 的 CSI 驱动，并测试不同 SELinux 标签共享卷的场景。
• 验证监控、HPA 客户端和内部工具对 metrics.k8s.io/v1 的兼容性。
• 将 Rootless kubelet 和 Volume Health Monitor 放入隔离环境验证，不把发布前状态视为稳定接口。

v1.37 的升级风险主要不在新 API 数量，而在旧运行模式的退出和节点级行为变化。越早把 IPVS、cgroup v1、静态 Pod API 引用和 SELinux 共享卷纳入资产盘点，正式升级时需要处理的未知量就越少。