Kubernetes 1.37 发布：Metrics API 转正与无特权 Kubelet 开启稳定性与安全新纪元

一句话结论

Kubernetes 1.37 通过 Metrics API 转正及无特权 Kubelet 进入 Beta，显著提升了集群监控能力与安全性。

关键要点

• Kubernetes 1.37 中 metrics.k8s.io API 达到 GA 级别，统一了节点与 Pod 的资源监控和度量方式。
• KubeletInUserNamespace 功能门控在 1.37 中升级为 Beta 并默认启用，允许核心组件以非 root 身份运行。
• 该版本包含 67 项增强功能，其中 27 项为 Alpha 特性，23 项升级至 Beta，16 项正式发布或已稳定。
• StatefulSet 滚动更新的 Recreate 策略进入 Alpha，允许在更新过程中自动清理卡住或等待状态的 Pod。

背景与事实

云原生计算基金会（Cloud Native Computing Foundation，CNCF）近期发布了 Kubernetes 1.37 版本，代号“Garhwal”。这一版本明确将焦点置于系统稳定性、安全性增强以及面向 AI/ML 工作负载的性能优化。作为 Kubernetes 版本迭代中的重要节点，1.37 不仅巩固了基础监控能力的标准化，还在节点身份管理这一长期安全痛点上取得了实质性进展。该版本的发布意味着社区在应对大规模集群挑战时，提供了更多开箱即用的原生解决方案，减少了对第三方插件的依赖。

在监控与自动扩缩容领域，metrics.k8s.io API 的正式可用（General Availability，GA）是一个里程碑。此前该 API 主要用于支持水平 Pod 自动扩缩容器（Horizontal Pod Autoscaler，HPA）、垂直 Pod 自动扩缩容器（Vertical Pod Autoscaler，VPA）以及 kubectl top 等命令。随着其状态转为 GA，意味着该接口具备了生产环境使用的稳定性保障，用户无需再担忧接口变动带来的兼容性风险。此外，韧性 watchcache 初始化也在 1.37 中正式发布。此前，当 kube-apiserver 在大型集群中重启或失去缓存连接时，会向 etcd 发起大量请求，导致性能骤降甚至控制平面宕机。现在，启用该功能后，kube-apiserver 能够安全地委派限定请求，并对过剩请求返回 HTTP 429 状态码，实现了优雅的降级处理。

在安全性与节点管理方面，KubeletInUserNamespace 功能门控升级为 Beta 并默认启用。这允许 kubelet 等核心节点组件借助 Linux 用户命名空间，以非 root 身份在主机上运行。这一变化旨在降低容器逃逸攻击的影响面，即便攻击者突破了容器边界，其获得的也是受限的非特权用户权限，从而提升了整体安全性。与此同时，Pod 证书功能也升级为稳定版本，为 Pod 间通信提供了原生的 mTLS 支持，使得内部服务间的加密通信不再依赖外部工具链，简化了零信任架构的实施难度。

针对特定工作负载，1.37 引入了多项 Alpha 特性以增强调度灵活性。其中，工作负载感知调度通过 InPlacePodVerticalScalingSchedulerPreemption 门控，允许调度器抢占低优先级工作负载，为等待状态的高优先级应用腾出资源进行原地规格调整。新增的 Pod 级检查点与恢复特性，允许 kubelet 创建检查点并从中恢复 Pod，便于对运行中容器的内存和进程树进行快照，这对于调试复杂故障或进行安全分析具有极高价值。此外，StatefulSet 滚动更新的 Recreate 策略进入 Alpha，该功能默认关闭，允许用户在更新过程中自动删除卡住或处于等待状态的 Pod，无需手动干预即可实现干净恢复。

在 AI/ML 场景优化方面，HorizontalPodAutoscaler 的缩容至零支持升级为 Beta 并默认启用。对于使用 GPU 等昂贵计算资源的 AI 工作负载，这一特性使得非活跃期的资源成本大幅降低，尤其适用于云环境中按需计费的场景。Kubernetes 1.37 共包含 67 项增强，其中 1 项被弃用或移除。下一个版本 1.38 预计将于 2026 年 12 月发布，用户可通过官方发布说明获取完整的增强、弃用与移除列表。

影响分析

对于中文开发者与企业从业者而言，Kubernetes 1.37 的发布意味着生产环境的运维复杂度将显著降低，特别是在监控与安全两大维度。首先，Metrics API 的 GA 状态消除了长期使用该接口可能面临的合规与稳定性顾虑，企业可以更加放心地将 HPA 和 VPA 部署至核心生产集群，而无需自行开发或维护自定义的监控聚合器。这将直接提升资源利用率，降低云成本，尤其对于成本敏感型的中大型互联网公司具有直接的财务价值。其次，无特权 Kubelet 的默认启用标志着节点安全基线的提升。对于需要满足严格安全审计（如等保、PCI-DSS）的金融机构与政务云用户，这一特性减少了对底层操作系统加固配置的依赖，简化了安全合规流程，降低了因节点权限过大导致的安全漏洞风险。

然而，这些变化也带来了适配挑战。Pod 级检查点与 StatefulSet 的 Recreate 策略目前仍为 Alpha，不适合直接在生产环境的核心业务中使用。开发者在尝鲜这些新功能时，必须建立完善的回滚机制与隔离测试环境，以防检查点恢复失败或 Pod 删除策略导致的数据不一致问题。对于 AI 团队，缩容至零功能的启用需要在应用层做好会话保持与冷启动优化的工作，否则虽然节省了空闲成本，却可能导致突发流量下的响应延迟激增，影响用户体验。因此，技术团队在升级至 1.37 前，应全面评估监控链路对 429 响应的处理能力，以及应用对无特权节点的兼容性。

适用边界

Kubernetes 1.37 中的无特权 Kubelet（Rootless Kubelet）特性依赖于 Linux 用户命名空间的支持。这意味着该功能在 Windows 节点或非 Linux 操作系统上的节点上不可用，且要求内核版本具备必要的命名空间功能。如果用户的环境涉及跨平台节点管理，或使用了较老的内核版本，该特性可能无法默认启用或存在兼容性问题。此外，Pod 级检查点与恢复功能目前仅处于 Alpha 阶段，且主要适用于无状态或易于重新初始化的工作负载；对于具有强状态依赖（如本地磁盘持久化、复杂网络状态）的有状态应用，直接应用检查点恢复可能导致数据丢失或状态错乱，因此该功能不适用于所有生产级有状态服务。StatefulSet 的 Recreate 策略同样默认关闭，仅建议在测试环境或非关键业务的 StatefulSet 更新流程中谨慎试用，不适用于对高可用性要求极高的核心数据库或消息队列集群。

孤本观察

作为技术编辑，我观察到 Kubernetes 1.37 正在从“功能堆砌”转向“精细化运维与安全加固”，Metrics API 的转正与韧性 watchcache 的 GA 反映了社区对大规模集群稳定性的深层关切，而非单纯的功能增加。

来源：InfoQ 中文 AI