The latest Kubernetes release was published just in time for the end of 2025. We therefore kicked off the new year with the usual detailed release notes.
As with every Kubernetes version, the release team has once again chosen a name and a release motto. Kubernetes v1.35 is called Timbernetes, and the World Tree release adds another growth ring to the project tree. Timbernetes is dedicated to all maintainers and users who once again contributed to the development: In total, version 1.35 contains 17 stable, 19 beta and 22 alpha features.
We want to take a look at the most important and interesting ones in this release review.
Stable Features: In-place Resource Updates, Update Tracking for Pods, and New Service Routing
We already mentioned what is probably the most important feature in our article on Kubernetes v1.34. In-place updates of Pod resources achieve General Availability (GA) in this Kubernetes release. All users can now adjust the CPU and memory requirements or limits of Pods and containers during operation. This makes vertical scaling easier, especially for applications and jobs that cannot be restarted just like that.
You can find more information in KEP #1287.
Update tracking for Pods is another feature that will be introduced in this Kubernetes GA release. In the past, unlike Deployments, for example, Pod resources did not have a metadata.generation field. As a result, third-party applications and users could not reliably determine whether the Kubelet had processed initiated changes to Pods or not.
With v1.35, Pods now receive the new fields metadata.generation, which is incremented each time the Pod resource is changed, and metadata.observedGeneration, which contains the last generation seen and processed by the kubelet.
For more information, see KEP #5067.
The last stable feature we would like to mention at this point is the new trafficDistribution option PreferSameNode for Services. With this setting, Services prioritize Endpoints on the local node when routing network requests. At the same time, the option PreferClose has been renamed to PreferSameZone to make its meaning more explicit.
For more information, see KEP #3015.
Beta Features: mTLS for Pods, OCI Volumes and Queryable Node Topology
When reading the Kubernetes release notes, we had the feeling that Pods were the focus this time. Among the most important beta features, there are many innovations that directly benefit the “smallest” Kubernetes resources.
The kubelet can now create keys, request certificates as PodCertificateRequests and store the resulting credentials directly in the file systems of Pods. This way, Kubernetes will be able to natively establish workload identities and rotate certificates without having to rely on third-party tools such as cert-manager or SPIFFE/SPIRE.
You can find more information in KEP #4317.
In the past, information about the topology of Nodes, such as zone and region membership, had to be queried via the Kubernetes API. The so-called Downward APIwhich can be used to query certain information and make it available in containers as environment variables or volumes, did not support this information.
With the Kubernetes release Timbernetes, the kubelet can now make various topology labels available to Nodes via the Downward API for containers in Pods. This allows applications to be tailored more precisely to the topological conditions of the cluster and configured accordingly.
You can find more information in KEP #4742.
The third beta feature that we think is worth mentioning is OCI Volumes. Especially in times of machine learning and LLMs, it is becoming increasingly common that large amounts of data need to be downloaded and initialized by training jobs or applications. Traditionally, this has been solved in Kubernetes with sidecars and init containers.
With the latest Kubernetes release, it is now possible to download OCI container image artifacts, unpack them and mount them as Volumes in Pods. This means that data and configuration can now be completely separated from your containerized applications. Complicated init scripts and containers can thus be avoided. A compatible container runtime, e.g. containerd v2.1+, is required to use this feature.
You can find more information in KEP #4639.
Alpha Features: The Latest Features in the Kubernetes Release v1.35
As mentioned at the beginning, Alpha features are the largest group in the latest Kubernetes release. Of the 22 brand new features, we are most excited about Gang Scheduling and Constrained Impersonation.
Gang Scheduling introduces native support for an “all or nothing” behavior of the Kubernetes scheduler. This is particularly useful for AI/ML training or HPC applications, which often consist of multiple interdependent Pods.
Previously, it could happen that one part of these Pods was scheduled successfully while another part was “stuck” due to lack of resources, Node or Pod affinity. The result in such cases was a standstill of the entire application.
With the new Kubernetes release, such applications can now be scheduled in groups using the new Workload API and the PodGroup concept, which leads to more reliability in Deployments.
You can find more information in KEP #4671.
Thanks to constrained impersonation, it is possible from Kubernetes v1.35 onwards, for example, to give support staff the option of pretending to be a cluster admin exclusively in order to read logs of Pods. Previously, such granular permissions were not possible: If a user had the RBAC permissions for impersonate, this applied to all permissions of the user they were impersonating.
If the new Feature Gate ConstrainedImpersonation is activated, the Kubernetes API server now checks impersonate-on permissions in addition to impersonate permissions to enable constrained impersonation.
You can find more information in KEP #5284.
Good Bye Ingress NGINX: Deprecations in Kubernetes v1.35
In addition to the many new features, there are of course also some functions, sub-projects and settings that were discontinued with the Kubernetes release Timbernetes.
The most important thing here is probably the discontinuation of Ingress NGINX. The lights go out on the popular Ingress Controller managed by the Kubernetes project. Main reason for this is a lack of maintainers: Most recently, only two users had been developing the project in their private time.
The official recommendation is to switch from Ingress to the newer GatewayAPI, more information and the background to the discontinuation can also be found in this official blog post.
In addition to Ingress NGINX, cgroups v1 are also disappearing from the world of Kubernetes. Kubernetes has supported cgroups v2 since version 1.25. With the latest Kubernetes release, cgroups v1 are no longer supported. If you are still running cluster nodes that do not support the newer cgroups v2, the kubelet will no longer start after an upgrade to Kubernetes v1.35. An update would therefore be advisable.
You can find more information in KEP #5573.
Another discontinuation deep in the container fabric is announced with Kubernetes v1.35: The current Kubernetes release will be the last version with support for containerd 1.x . Here, too, it is therefore important to upgrade to a current, supported version as soon as possible.
You can find more information in KEP #4033.
Our Conclusion: Improved Security and Pod Management With a Need for Updates
In our opinion, the Kubernetes release Timbernetes again offers a good mix of features, with something for every user and administrator.
This time there was a certain focus on Pods. Resource updates without restarts, OCI volumes for the integration of data and configuration and more options in terms of scheduling and external control will certainly make the handling of complex applications a little easier in the future.
Security was also a major topic in this release. Constrained impersonation provides new opportunities for teams to better map their structures and processes in Kubernetes RBAC, discontinued support for cgroups v1 forces modernization of legacy environments, and native mTLS for Pods provides the ability to replace service meshes and other external solutions.
We will now make Kubernetes v1.35 available in NETWAYS Managed Kubernetes® as soon as possible so that you can also use it in MyNWS in the near future. In the meantime, if you have any questions about the new Kubernetes release, the upgrade, or Kubernetes in general, please feel free to contact us at any time.
0 Comments