Kubernetes v1.35: A Milestone Update
Kubernetes v1.35 has hit the scene with a captivating array of features and enhancements, signaling yet another stride forward for this cornerstone of cloud-native technology. With 60 enhancements rolled out—17 of which are now classified as stable, 19 in beta, and 22 still in alpha—the release exemplifies Kubernetes' commitment to evolving through community-driven development. What stands out isn’t just the number; it’s how those enhancements speak to the ongoing collaboration and support from a thriving ecosystem of developers and users. The energy surrounding this release echoes the diligence of Kubernetes’ contributors who endure the ebb and flow of lifecycle changes, personal commitments, and the open-source ethos. They maintain a robust suite of APIs and continually introduce new capabilities, reinforcing the platform's resilience as one of the largest open-source endeavors globally. You can see how this community spirit is encapsulated in this thoughtful World Tree logo, representing interconnected realms and growth through winding paths—a fitting theme that harks back to the ancient Yggdrasil, the fabled tree of life. The vibrant narrative of Kubernetes v1.35 culminates in the image of three squirrels, each symbolizing critical roles within the Kubernetes ecosystem: a wizard for reviewers, a warrior for the dedicated release teams, and a rogue shining light on complex issue queues. This imagery is both playful and profound, embodying the collaborative spirit that characterizes the project and showcases how community participation is vital for navigating technical challenges.Noteworthy Improvements in Kubernetes v1.35
In terms of what’s new and noteworthy, Kubernetes v1.35 prioritizes functionality that can significantly enhance user experience. For instance, the **in-place updates for Pod resources** have officially graduated to General Availability. This key capability allows users to modify CPU and memory allocations without the fuss of restarting Pods, avoiding disruptions—especially crucial for critical stateful applications. Historically, this would have meant significant rework for users. This upgrade transforms how users manage resources, ultimately leading to greater system efficiency and simplicity in development. Similarly, the **beta feature for Pod certificates** showcases a significant leap in security and workload identity management. The ability to automate certificate rotation directly within Pods minimizes the complexities associated with external controllers. This shift not only provides a seamless way for our services to communicate securely but also addresses key complications around the management of secret data in a zero-trust architecture. Another noteworthy alpha feature is the **node-declared features before scheduling**—a welcome addition meant to alleviate issues arising from mismatches between active control plane features and legacy node capabilities. By allowing nodes to articulate their supported features, it becomes easier to enforce best practices around scheduling compatibility, ultimately enhancing application deployment processes. Equally, the advancements aren’t limited to new features—several existing capabilities are graduating to stable status, ensuring that users can count on tried-and-tested functionality in their deployments. For example, the **traffic distribution enhancements** now enable more precise control over how services route traffic, allowing options that keep processing efficient while adhering to local resource optimizations. If you’re entrenched in working with Kubernetes, this latest version is not just a modest update—there’s real substance here that should resonate with your operational needs. This release doesn’t just add features; it fortifies Kubernetes’ foundation, promoting a more streamlined, user-friendly approach to building and managing cloud-native applications.Flexible Tolerance Settings for HorizontalPodAutoscalers
Traditionally, the Horizontal Pod Autoscaler (HPA) operated with a fixed 10% tolerance for scaling actions, which often led to complications. Workloads with tighter scaling needs, such as those that needed to adjust on a mere 5% increase in load, frequently found themselves hindered. Meanwhile, other workloads experienced unnecessary fluctuations due to the rigid nature of this tolerance.
With the rollout of Kubernetes v1.35, the ability to customize tolerance settings has moved into the beta phase and is automatically enabled. Users can now specify individualized tolerance levels for each resource in the HPA's behavior field. For instance, by setting a 0.05 tolerance for a 5% increase, operators can finely tune the autoscaling responsiveness. This update empowers them to react swiftly to small metric variations without the need for sweeping changes that affect the entire cluster.
This initiative was part of KEP #4951, which was spearheaded by SIG Autoscaling.
User Namespaces Support in Pods
Kubernetes is enhancing pod security by implementing user namespace support. This allows pods to run with their own isolated user and group IDs instead of using the host's user IDs directly. As a result, containers can function as root within their environment while being mapped to a non-privileged user on the host—this significantly mitigates the risk of privilege escalation if a container is compromised. Over time, this feature has been expanded to encompass both stateless and stateful Pods utilizing ID-mapped mounts.
This advancement is part of KEP #127, led by SIG Node.
VolumeSource Enhancements: OCI Artifacts and Images
When deploying a Pod, there often arises a need to incorporate various data, binaries, or configuration files. In the past, this meant integrating content directly into the primary container image or utilizing custom init containers to retrieve and unpack files. Kubernetes v1.31 has introduced an image volume type that allows Pods to declaratively pull OCI container image artifacts directly into a volume. This new feature enables the packaging and delivery of data-only artifacts—like configurations or machine learning models—using standard OCI registry tools.
The shift to an image volume type means users can now decouple data from container images, doing away with the need for additional init containers or startup scripts. Starting from v1.35, this feature has moved out of beta and is now enabled by default. Do note that using this feature requires a compatible container runtime, such as containerd v2.1 or higher.
This development was achieved through KEP #4639, led by SIG Node.
Mandatory Credential Verification for Cached Images in Kubelet
The setting imagePullPolicy: IfNotPresent allows Pods to utilize container images that are already cached on a node, even if the Pod doesn’t have the credentials to access those images. This scenario can lead to security vulnerabilities in multi-tenant Kubernetes clusters, where an authorized Pod could cache a sensitive image, allowing subsequent unauthorized Pods on the same node access to that image simply through local caching.
To combat this, the new KEP introduces a credential verification mechanism within the kubelet. It now checks whether a Pod has valid credentials before permitting the use of any locally cached images. This enhancement ensures that only authorized Pods can access private images, thereby bolstering overall security in shared environments. In Kubernetes v1.35, this feature is now in beta status and enabled by default, although users can opt to disable it by setting KubeletEnsureSecretPulledImages to false. Moreover, operators can configure the imagePullCredentialsVerificationPolicy flag to adjust the level of security, from backward-compatible modes to stringent enforcement options.
This work was part of KEP #2535, led by SIG Node.
Granular Restart Policies for Containers
In past versions, the restartPolicy field applied at the Pod level, meaning all containers within a Pod were bound to the same restart behavior. This rigid structure was problematic for complex tasks like AI/ML training, where a Pod might need restartPolicy: Never to manage job completion, while certain containers could benefit from specific restarts due to retriable errors, like network issues or GPU initialization problems.
Kubernetes v1.35 addresses this limitation by allowing distinct restartPolicy and restartPolicyRules settings for individual containers within the API. This granularity enables tailored recovery strategies; for example, a container can be set to restart only when it exits with a specific error code, hence avoiding the overhead of rescheduling the entire Pod for transient issues.
This enhancement is a result of KEP #5307, led by SIG Node.
