前言¶
Kubernetes 1.37 定于 2026 年 8 月 26 日正式发布。7 月 31 日，Kubernetes 官方博客发布了 v1.37 Sneak Peek，Release Team 列出了运维侧需要提前知晓的弃用项与重点增强。根据 Kubernetes 增强追踪器 与社区 mid-cycle 统计，本版本共跟踪 86 项增强，其中约 16 项计划毕业至 Stable（GA）。
对平台团队而言，1.37 不是「功能堆砌」型版本，而是几条长期演进线的交汇点：HPA 原生缩容至零进入 Beta 并默认开启、DRA 设备污点容忍正式 GA、kube-proxy IPVS 模式启动弃用时间线，同时 metrics.k8s.io 在 Beta 停留近九年后毕业稳定。如果你正在规划三四季度升级窗口，下面几项值得优先评估。
发布时间与版本概况¶
Kubernetes 1.37 的正式发布日已写入 Release 日历：2026 年 8 月 26 日（周三）。需要强调的是，Sneak Peek 文首已说明：文中内容反映当前发布状态，正式发布前仍可能调整。
从增强分布看（数据来源：Cloudsmith 对官方 Tracker 的梳理）：
- 86 项有效增强（排除 Deferred / Removed from Milestone）
- 28 项处于 Graduating 阶段，其中 16 项目标 Stable
- 34 项 Net New Alpha
除本文重点外，1.37 还涉及 Pod 级资源请求（KEP-2837）GA、KYAML 输出稳定、Kubelet Rootless Mode Beta、Volume Health Monitor 重新进入 Alpha 等变更。完整清单可参考 Cloudsmith 1.37 特性梳理 与官方 CHANGELOG（发布日同步）。
HPA 缩容至零：Beta 默认开启¶
背景与意义¶
队列型 Worker、定时批处理、事件驱动微服务等场景，业务空闲时 Pod 长期占着节点却几乎不干活。过去要实现「闲时缩到 0」，常见做法是引入 KEDA 或 Knative，在 HPA 之上再挂一层事件源适配。
KEP-2021 从 1.16 Alpha 起就跟踪「基于对象/外部指标缩容至零、再扩容回来」的能力；1.36 完成 Alpha 重实现后，1.37 计划将 HPAScaleToZero 特性门控提升至 Beta 并默认开启（参见 kubernetes/kubernetes#139648）。
这意味着：对具备合适指标源的工作负载，原生 HPA 即可覆盖「闲时零副本」，不必再为这一基础能力单独引入第三方控制器。
使用约束（务必读）¶
缩容至零不支持 CPU/内存利用率类指标。原因很简单：副本数为 0 时没有 Pod 在跑，Resource Metrics API 读不到利用率，HPA 无法计算目标副本数。
该能力仅适用于 Object 或 External 指标——例如消息队列深度、自定义 Prometheus 指标、云厂商观测指标等，这些信号与当前 Pod 数量无关。
1.37 Beta 还引入了 HPA Status 中的 ScaledToZero 条件，用于区分「控制器自动缩到 0」与「人工暂停 Deployment」等状态，避免扩容逻辑误判。
配置示例¶
以下是一个基于外部指标的 HPA 示例：minReplicas: 0，当队列消息可见数降为 0 时缩容至零：
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: queue-worker
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: queue-worker
minReplicas: 0
maxReplicas: 10
metrics:
- type: External
external:
metric:
name: queue_messages_visible
target:
type: Value
value: "0"
实践建议：
- 首次启用时，Deployment 建议从至少 1 个副本启动，让 HPA 记录初始状态后再缩至 0（KEP 对 scale-from-zero 触发条件有说明）。
- 默认 5 分钟 scale-down 稳定窗口 会抑制抖动；突发流量场景可在
spec.behavior中按需调整。 - KEDA 在事件源连接器生态上仍有优势；但若你的需求仅是「队列空了就不占机器」，1.37 的原生 HPA 已值得在预发环境验证。
DRA 设备污点容忍 GA：GPU 集群运维的关键拼图¶
DRA 与设备污点是什么¶
Dynamic Resource Allocation（DRA） 是 Kubernetes 面向 GPU、FPGA、SR-IOV 等专用硬件的新一代资源分配模型。驱动通过 ResourceSlice 上报设备清单，用户通过 ResourceClaim 申请设备，调度器在分配阶段完成选型。
在 GPU 集群里，一个长期痛点是：某张卡出现 ECC 错误、驱动超时或需要维护下线时，怎么阻止新 Pod 调度上去，并安全驱逐已在跑的 workload？ 传统 Device Plugin 模型缺少与 Node Taint 对等的设备级隔离手段。
KEP-5055 引入 Device Taints and Tolerations，机制与节点污点类似：
| 效果 | 行为 |
|---|---|
NoSchedule |
禁止新 Pod 调度到该设备 |
NoExecute |
驱逐当前使用该设备、且未容忍污点的 Pod |
None |
仅作信息标记，不影响调度 |
DRA 驱动可在 ResourceSlice 中直接标记设备；集群管理员也可创建 DeviceTaintRule，按 driver、pool、device 名称等选择器批量打污点，无需改动驱动配置。
1.37 的 GA 意义¶
KEP-5055 的里程碑为：Alpha 1.33 → Beta 1.36 → Stable 1.37。对应 PR #138676 已合并，Device TaintRule 通过 resource.k8s.io/v1 API 正式可用。
对 GPU 集群调度而言，这意味着：
- 故障 GPU 可被标记为
NoSchedule，新训练 Job 不会踩坑 - 维护窗口可对特定 pool 打
NoExecute，配合 Pod 容忍策略滚动迁出 - 结合 1.37 同步推进的 DRA 增强（如 KEP-5304 Device Attributes Downward API、KEP-6072 标准
numaNode属性 Alpha），分布式训练获取拓扑信息、做 NUMA/PCIe 亲和调度会更顺畅
若你已在 1.35+ 集群试点 DRA GPU Driver，1.37 是把污点容忍纳入生产 SOP 的合适版本。
kube-proxy IPVS 退场，nftables 接棒¶
为何要弃用 IPVS¶
kube-proxy 的 IPVS 模式自 1.8 引入，初衷是缓解 iptables 规则膨胀带来的性能问题。但 Kubernetes 社区在 KEP-3866 中已明确指出：内核 IPVS API alone 无法完整实现 Service 语义，IPVS 模式底层仍依赖 iptables 做兜底，维护成本高、行为难统一。
1.37 起，运行 IPVS 模式的集群在 kube-proxy 启动时会收到 弃用警告。官方 Sneak Peek 给出的时间线（KEP-5495）：
| 版本 | 变化 |
|---|---|
| 1.37 | 启动时记录 deprecation warning |
| 1.40 | IPVS 模式预计默认禁用（仍可通过特性门控手动开启） |
| 1.43 | 完全移除 IPVS 支持 |
如何确认当前模式¶
kubectl -n kube-system get configmap kube-proxy -o jsonpath='{.data.config\.conf}' | grep 'mode:'
若输出 mode: ipvs，应开始规划迁移。社区普遍建议的目标后端是 nftables——Kubernetes 自 1.31 起 nftables 模式 Beta，2025 年 2 月官方博客 已有专题介绍。
1.37 还新增了 KEP-5343（Alpha）：为尚未切换默认后端的集群打预防针——仍使用 iptables 默认值的节点会收到日志警告，提醒在 1.40 默认切换 nftables 之前完成显式配置或迁移。同版本的 KEP-6032 则为 nftables 补齐 localhost NodePort 用户态代理能力（Alpha）。
迁移前请确认节点内核 ≥ 5.13（nftables kube-proxy 要求），并在预发环境验证 Service、NodePort、externalTrafficPolicy: Local 等关键路径。
metrics.k8s.io 正式 GA¶
HPA、kubectl top、各类监控集成背后，都依赖 Metrics API（metrics.k8s.io）。该 API 自早期版本起长期处于 Beta，1.37 计划将其毕业至 Stable（GA）（KEP-5207）。
官方说明：功能层面无预期变更，v1 与 v1beta1 在过渡期内均可使用。这更像是一次「稳定性盖章」，让依赖 Metrics Server 的平台团队少一层「Beta API 随时变」的心理负担。
升级前检查清单¶
在 8 月 26 日正式发布前，建议按下面顺序做摸底（部分项来自官方 Sneak Peek，部分来自社区升级指南，正式升级请以 Release Notes 为准）：
1. 检查 kube-proxy 模式
见上文 grep 命令。IPVS 用户请排期迁移至 iptables 或 nftables。
2. 确认 containerd 版本
Kubernetes 自 1.34 弃用 containerd 1.6/1.7，1.35 为最后支持 containerd 1.x 的版本；1.37 继续移除 kubelet 遗留配置项，KubeletCgroupDriverFromCRI（1.36 GA）成为 cgroup driver 检测的唯一路径。节点若仍运行 containerd 1.x，应在升级 1.37 之前迁移至 containerd 2.0+：
containerd --version
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.nodeInfo.containerRuntimeVersion}{"\n"}{end}'
迁移前可在 1.7.21+ 上执行 ctr deprecations list 排查不兼容项；直接访问 containerd socket 的监控/运维工具需确认使用 CRI v1（containerd 2.0 已移除 CRI v1alpha2）。
3. 确认 cgroup 版本
自 1.35 起 failCgroupV1 默认为 true，1.37 仍可通过 failCgroupV1: false 临时 override，但 cgroup v1 支持将在后续版本移除（KEP-5573）。In-Place Pod Resize、分层内存保护等能力依赖 cgroup v2：
stat -fc %T /sys/fs/cgroup/
4. 在预发验证 HPAScaleToZero
队列/事件驱动类 Deployment，用 External 或 Object 指标配置 minReplicas: 0，观察缩容、扩容与 ScaledToZero 条件是否符合预期。
5. GPU 集群评估 DRA 污点规则
若已启用 DRA，在 staging 创建 DeviceTaintRule，验证 NoSchedule / NoExecute 与 ResourceClaim 容忍策略是否按预期工作。
小结¶
Kubernetes 1.37 把几条「说了很久」的演进线同时推到了可行动阶段：HPA 缩容至零让闲时成本可控，DRA 设备污点让 GPU 集群故障隔离有了原生语义，IPVS 退场则倒逼 kube-proxy 向 nftables 统一。86 项增强里或许没有单一「杀手特性」，但对负责集群生命周期的人来说，这恰好是制定 Q3–Q4 升级路线图的正确时间点。
正式发布还有约三周。建议现在就用上面的命令摸清 kube-proxy 模式、containerd 版本和 cgroup 状态；8 月 26 日 CHANGELOG 出炉后，再对照 diff 做最终 Go/No-Go 决策。
