Kubernetes 1.35发布，提供了Pod原地扩缩容和AI优化调度功能

云原生计算基金会（CNCF）发布了Kubernetes 1.35，代号为“Timbernetes”，重点强调其对可变性（mutability）的支持以及对高性能AI/ML工作负载的优化。

1.35版本的一项关键特性是Pod原地扩缩容（In-Place Pod Resize）正式进入通用可用（GA）阶段。该功能允许集群运维人员在不触发容器重启的情况下，动态调整运行中Pod的CPU和内存资源。

Red Hat解决方案架构师Piotr Mińkowski近日在X.com上发文指出，这一特性对Java开发者尤为重要：

为何对Java至关重要呢？你可以在启动时为Pod分配额外的CPU，启动完成后立即缩减。这样应用启动更快，而Pod始终使用恰好数量的资源。

本次发布的Alpha特性包括调度器内建的组调度（Gang Scheduling）原生支持。Gang调度确保一组相互关联的Pod（例如AI/ML训练任务）要么全部同时被调度，要么一个都不调度。

Kubernetes 1.35引入了新的PodGroup API资源，允许用户直接在核心API中定义调度需求。在Kubernetes的早期版本中，类似需求通常依赖Volcano或Kueue等外部项目来实现。

另一个进入Alpha阶段的特性是对Kubernetes组件的/flagz和/statusz 等端点的增强。这些改进为授权用户提供机器可解析的输出格式，使自动化排障和可观测性工具能够通过HTTP协议轻松监控所有核心组件，而无需复杂的文本解析。

在Kubernetes 1.35中，Horizontal Pod Autoscaler（HPA）的可配置容差（tolerance）功能已升级至Beta阶段并成为默认启用的特性。在此前的版本中，HPA使用固定的10%容差进行扩缩容决策，难以满足某些需要不同阈值的工作负载。现在，用户可为每种资源单独定义容差窗口，而无需修改集群的全局配置。

此外，用于简化和自动化Pod证书获取流程的PodCertificateRequests API对象集合也在本次发布中晋升为Beta。PodCertificateRequest的目标是在Pod级别管理证书生成，并将证书直接写入Pod的文件系统中，从而简化mTLS流程，无需使用Bearer Token或人工干预。

尽管不属于1.35版本的内容，但是社区决定逐步淘汰Ingress NGINX控制器，反映了向更加集成化解决方案演进的趋势，鼓励用户考虑现代化的替代方案，如Gateway API。

在2026年3月前，Ingress NGINX仅接受尽力维护（best-effort maintenance）。官方推荐迁移至Gateway API，这是一个专注于L4/L7路由的官方Kubernetes项目，或采用其他第三方Ingress控制器。

Kubernetes 1.35共包含60项增强功能，其中22项为Alpha特性，19项晋升为Beta，17项达到通用可用或稳定状态，同时还包含若干弃用和移除内容。

用户可查阅官方的发布说明和文档，全面了解Kubernetes 1.35的各项增强、弃用及移除的内容。

此外，用户还可于2026年1月14日（星期三）参加发布团队举办的在线直播研讨会。

下一个版本Kubernetes 1.36预计将于2026年4月发布。

原文链接：

Kubernetes 1.35 Released with In-Place Pod Resize and AI-Optimized Scheduling