十多年前，开源云原生项目 Kubernetes 诞生之初，AI 并非其主要考量。如今，时代已然不同。
Kubernetes 1.37 正式发布，在越来越多组织将 AI 与机器学习工作负载迁移至该平台的背景下，新版本进一步扩展了网络与调度能力。此次发布是该平台 2026 年的第二次重大更新，延续了今年 4 月发布的 1.36 版本。新版本代号为"Garhwal"，取自印度北部一个地区的名称——这正是 Kubernetes 1.37 发布负责人 Dipesh Rawat 的家乡。
1.37 更新的一个核心方向，是始于 Kubernetes 1.35 的网络过渡：彼时 IPVS kube-proxy 模式被弃用，Pod 资源原地调整功能正式进入正式可用阶段。在网络层面，Kubernetes 1.37 继续将集群流量处理从 IPVS 迁移至 nftables；在调度层面，新版本引入了更具工作负载感知能力的特性，专门面向需要多个 Pod 同步启动与扩展的 AI 及机器学习训练任务。
Kubernetes 正越来越多地围绕其所承载的工作负载形态构建，而不仅仅是关注单个 Pod。
"以前只有 Pod，调度器单独处理每个 Pod 并进行调度，"Rawat 在接受 Network World 采访时表示，"现在，Kubernetes 整体上正在向工作负载感知的方向演进。"
工作负载感知调度
Kubernetes 历来以逐一方式调度和扩展 Pod，对 Pod 之间关系的感知十分有限。这种方式对无状态服务有效，但对 AI 工作负载却存在问题——多个 Pod 往往需要同步启动、共享加速器访问权限，并以整体而非个体的方式进行扩展。1.37 版本通过多项特性正面应对这一挑战，将工作负载感知调度引入平台。
HPA 缩容至零（KEP-2021）：HorizontalPodAutoscaler 缩容至零特性在 1.37 中升级为 Beta，并默认启用。当需求消失时，它可以将工作负载副本数降至零，待需求回升后再自动恢复，依赖对象或外部指标而非 CPU 或内存指标来触发。Rawat 表示，该特性依赖外部信号，是因为副本数为零时没有运行中的 Pod 可供采集 CPU 或内存数据。"简单来说，如果你在昂贵的 GPU 上运行高计算量工作负载，这个特性能为你节省一笔成本，"他补充道。
组调度（KEP-4671）：Red Hat OpenShift Node 团队首席工程师 Sascha Grunert 向 Network World 介绍，该特性为分布式训练任务带来了原生的"全部或全不"Pod 放置能力。
工作负载感知抢占（KEP-5710）：该特性同样在 1.37 中升级为 Beta，允许调度器在抢占低优先级工作负载时，以 PodGroup 为整体进行权衡，而非逐个评估 Pod。
DRA 设备污点与容忍（KEP-5055）：动态资源分配（DRA）是 Kubernetes 将 GPU 等硬件分配给工作负载的机制。该特性在 1.37 中达到稳定状态，允许 Kubernetes 将故障或性能下降的设备标记为不可分配，类似于现有的节点不可用标记机制。管理员还可以按驱动程序等条件将设备设为排除状态。Grunert 表示，该特性允许使用熟悉的节点污点模型对性能下降的硬件进行驱逐操作。
网络层：从 IPVS 迁移至 nftables
Kubernetes 1.37 继续推进集群网络从 IPVS 和 iptables 向 nftables 的过渡，后者是内置于 Linux 内核的新一代网络处理方案。
kube-proxy 组件自 Kubernetes 1.8 起便将 IPVS 作为 iptables 的替代选项，但 IPVS 底层仍依赖 iptables，这也是 Kubernetes 弃用 IPVS 模式、转向 nftables 的原因之一。
"核心故事就是从 iptables 到 nftables 的迁移，"Grunert 表示。
他解释称，未明确设置 kube-proxy 模式的集群现在将收到弃用警告（KEP-5343）；IPVS 后端也正式被弃用（KEP-5495），计划在 1.40 版本中禁用，在 1.43 版本中彻底移除。
"nftables 通过增量规则更新提供更好的性能，并与 Linux 内核网络栈的发展方向保持一致，"Grunert 说。
Grunert 还重点提及了另一项网络能力——基于标准化网络接口数据的 DRA 资源声明状态（KEP-4817）。他指出，该特性为 DRA 驱动程序提供了一种描述已附加网络接口的一致方式，对 GPU 和 RDMA 工作负载而言愈发重要。
安全性提升：原生工作负载 PKI 支持
Pod 证书（KEP-4317）和 ClusterTrustBundles（KEP-3257）特性为 Kubernetes 集群带来了更完善的安全保障。
"Pod 证书和集群信任证书已进入稳定状态，这本质上为你提供了一种在 Pod 之间共享私钥和 X.509 证书的一等公民方式，这是一个不错的特性，"Rawat 说。
Grunert 指出，这两项特性首次为 Kubernetes 构建了完整的原生工作负载 PKI 体系。"Pod 可以申请短期 X.509 证书，并通过投影卷接收集群级信任锚，无需 cert-manager 或 SPIFFE/SPIRE 等外部工具即可实现 mTLS，"他说。
发布流程调整与 AI 政策展望
除新特性外，Kubernetes 发布团队也在为未来版本调整自身流程。
Rawat 表示，每次发布中选择加入的 Kubernetes 增强提案（KEP）数量持续攀升，本次发布收到了大量来自贡献者的例外请求，要求延长截止时间。
为此，发布团队决定在下一次更新中缩短版本间通常两周的空窗期，以腾出更多时间用于清理流程和更新文档。"这实际上给了我们多出两周的有效开发和测试时间，"Rawat 说。
AI 未来或许也将在加速 Kubernetes 开发中发挥作用。
"在 Kubernetes 社区，我们有自己的 AI 政策——贡献者可以自由使用任何 AI 工具提交 PR，但需要在 PR 描述中注明使用了 AI，"Rawat 说。
发布团队在 1.37 版本的发布过程中并未使用 AI 工具，仍依靠人工操作和现有自动化流程完成工作。
"我希望未来随着采用率的提升、社区完善了相应流程之后，我们可以开始引入这些工具，"Rawat 说。
Q&A
Q1：Kubernetes 1.37 的组调度功能是什么？对 AI 训练有什么用？
A：组调度（KEP-4671）为分布式训练任务提供原生的"全部或全不"Pod 放置能力。AI 训练任务通常需要多个 Pod 同时启动并协同工作，传统的逐个调度方式容易导致部分 Pod 就绪而其他 Pod 无法启动的情况。组调度确保所有相关 Pod 要么一起被调度，要么一起等待，避免资源浪费和训练任务失败。
Q2：Kubernetes 1.37 为什么要从 IPVS 迁移到 nftables？
A：IPVS 底层依然依赖 iptables，存在架构上的历史包袱。nftables 是 Linux 内核内置的新一代网络处理框架，支持增量规则更新，性能更优，也与 Linux 内核网络栈的长期发展方向一致。Kubernetes 计划在 1.40 版本禁用 IPVS 后端，在 1.43 版本彻底移除，集群管理员应提前规划迁移。
Q3：Kubernetes 1.37 的 Pod 证书功能解决了什么问题？
A：Pod 证书（KEP-4317）和 ClusterTrustBundles（KEP-3257）让 Kubernetes 首次拥有完整的原生工作负载 PKI 体系。Pod 可以直接申请短期 X.509 证书，并通过投影卷获取集群级信任锚，从而实现 mTLS 通信，无需再依赖 cert-manager 或 SPIFFE/SPIRE 等第三方工具，降低了安全配置的复杂度。
