云原生计算基金会（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
