BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

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

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

Listen to this article -  0:00

The Cloud Native Computing Foundation (CNCF) announced the release of Kubernetes 1.35, named "Timbernetes" , emphasizing its focus on mutability and the optimization of high-performance AI/ML workloads.

A key feature in version 1.35 is the general availability of In-Place Pod Resize. This feature allows cluster operators to adjust CPU and memory resources for running pods without triggering a container restart.

Piotr Mińkowski, a Solutions Architect at Red Hat, highlighted the importance of this to Java developers in his recent post on X.com.

Why is it essential for Java? You can give the pod extra CPU only for startup, then shrink it after. App starts fast, the Pod uses the right amount of resources always.

Alpha features in this release include native support for Gang Scheduling within the scheduler. Gang scheduling ensures that a group of interrelated pods, for example, AI/ML training jobs, are scheduled simultaneously or not at all.

The new PodGroup API resource in version 1.35 allows users to define scheduling requirements directly in the core API. In prior releases of Kubernetes, projects such as Volcano or Kueue were used to handle similar challenges.

Another feature entering alpha is the enhancements made to the /flagz &  /statusz endpoints for Kubernetes components. Such changes provide machine-parsable output to authorized users, making it easier for automated troubleshooting and observability tools to monitor all core components over HTTP without sophisticated text parsing.

In Kubernetes 1.35, a configurable tolerance for the Horizontal Pod Autoscaler (HPA) graduated to beta and became a default feature. In previous versions, HPA used a fixed 10% tolerance for scaling actions, which made it challenging to accommodate workloads that may require a different threshold. This move enables users to define a per-resource tolerance window without requiring cluster-wide configuration changes.

Also, PodCertificateRequests, a collection of API objects to streamline and automate how Kubernetes pods obtain certificates, graduated to beta in this release. A PodCertificateRequest is designed to manage certificate generation at the pod level and writes the certificate directly to the pod’s filesystem, simplifying mTLS flow with no bearer tokens or human interactions.

Although it’s not part of 1.35, the community's decision to sunset the Ingress NGINX controller reflects a move toward more integrated solutions, encouraging users to consider modern alternatives such as the Gateway API.

Ingress NGINX will receive only best-effort maintenance until March 2026. The recommended approach is to migrate to the Gateway API, an official Kubernetes project focused on L4 and L7 routing, or to use an alternative third-party ingress controller.

Kubernetes version 1.35 includes 60 enhancements, 22 alpha features, 19 graduating to beta, 17 becoming generally available or stable, along with a few deprecations and removals.

For more information on the Kubernetes 1.35 release, users can refer to the official release notes and documentation for a comprehensive overview of the enhancements, deprecations, and removals.

In addition, Users can also join the release team on Wednesday, January 14, 2026, at 11:00 AM (CST) for a live webinar.

The next release, version 1.36, is expected by April 2026.

About the Author

Rate this Article

Adoption
Style

BT