Kubernetes v1.34 Sneak Peek

Explore what's new in Kubernetes v1.35- Pod Certificates, in-place updates, taint operators, OCI volumes, and more.
Tania Duggal
December 3, 2025
Subscribe to our newsletter
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Kubernetes v1.35 is just around the corner, with the official release planned for December 2025. This version introduces a number of exciting enhancements and feature updates that continue to make Kubernetes more powerful, flexible, and easier to operate.

In this sneak peek, we’ll walk through some of the key improvements you can expect in v1.35. Keep in mind that these features are still under active development, so things may change slightly by the time the release goes GA.

Featured Enhancements

1. Pod Certificates


Alpha to Beta

Pod Certificates add a mechanism for workloads to prove securely their identity when communicating with each other, natively. Service account tokens on Kubernetes today is more often used to talk to the API server than for workload-to-workload authentication. Due to this limitation, most teams rely on external tools such as SPIFFE/SPIRE or cert-manager to  issue, rotate, and manage certificates which increases the complexity in managing cluster.

With Pod Certificates, Kubernetes will now be able to automatically generate and mount short-lived certificates directly into Pods using a projected volume. For every Pod, the kubelet asks for a certificate, and takes care of rotation out of the box with nothing more than an API server in hand and no operations or external infrastructure!

This makes it a lot easier to turn on mTLS between services, build zero trust networking and ultimately be in the position where you can run secure microservice architectures without a ong list of custom components.

This is a significant security improvement as well as a simplification for certificate management for any cluster that runs distributed systems or service mesh patterns.

2. Numeric Values for Taints

New Scheduling Capability

Prior to this enhancements, taints and tolerations could be matched only on equality. Kubernetes v1. 35 adds numerical comparison operators like Greater Than (Gt) and Less Than (Lt) and it really makes scheduling decisions much more expressive such as a Pod can schedule only onto nodes where sla=950 or higher (operator: Gt, value: "950").

It allows quality-based workload placement, it also works with NoExecute taints to evict workloads if a node’s score falls too low, and it is more flexible than node affinity in many real scenarios.

This enhancement is great for production use cases targeting performance SLAs or SLO-based scheduling.

3. User Namespaces

Continuing Beta

Normally, containers run processes as root inside the container, which maps to the host root.  This is a security risk if a container breaks out. User Namespaces allow Kubernetes to remap the container’s root user to an unprivileged user on the host which greatly lowers the risk.

This means that containers can seem to have root access inside, but from the host's point of view, they are not root at all. It also provides stronger isolation and protection from escalation attacks.

4. Support for Mounting OCI Images as Volumes

Beta - By Default

Workloads need configuration files, binaries, ML models, or data that comes with them. In the past, teams would either bake that data into container images or use init containers to download files.

Kubernetes now supports using an OCI artifact directly as a volume source. It can pull in content like a data-only image and unpacking it into a volume.

It has a lot of benefits: it doesn't need custom init containers, it separates app images from large datasets, it works with existing registry workflows, and it starts pods up faster and cleaner.

5. Node Declared Features

Targeting Alpha

Node labels, taints, and tolerations are very important for scheduling pods in Kubernetes because they help match workloads with the right nodes. When you upgrade a cluster, though, nodes with different versions can cause features to not match up, and workloads can sometimes be scheduled on nodes that don't support the features they need, which can cause failures.

This is what the new Node Declared Features framework is trying to fix. With this update, each node will automatically publish the Kubernetes features it supports in a new .status.declaredFeatures field. The scheduler, admission controllers, and other components can then check these capabilities before placing a Pod.

This result in fewer manual labels, less configuration work, better placement of Pods, better protection against unexpected runtime failures, and smarter autoscaling decisions.

In the end, this system makes scheduling more reliable, especially when nodes are running different versions of Kubernetes.

6. In-Place Update of Pod Resources

Graduation to Stable

Today, if you want to increase or decrease a Pod’s CPU or memory requests/limits, Kubernetes has to recreate the Pod. This can cause workloads to stop. With version 1.35, in-place resource updates become available to everyone. This means you can resize running Pods without restarting them.

This is very useful for stateful services where restarts are expensive, AI/ML and batch workloads that change size over time, and platforms that practice real-time resource right-sizing.

The underlying Container Runtime Interface has also been improved so that it can report the status of resources in real time and let updates happen across different runtimes, including Windows.

This improvement makes vertical scaling easier, faster, and less disruptive.

What to Look Out For: Deprecations and Removals 

 For v1.35, some older features will also be removed, and users will slowly be pushed towards newer defaults:

The kube-proxy IPVS mode will no longer be supported. This is part of a bigger change (like moving to nftables or other networking backends), and it means that people who use IPVS should move or make plans.

The Kubernetes Team is still phasing out support for cgroup v1, and clusters that use older container runtimes (like containerd v1.x) should pay attention because compatibility windows are getting narrowing. As always, you should look over deprecated features as part of your upgrade planning to avoid any surprises after the upgrade.

To dive deeper into the release, make sure to check the official Release Notes and CHANGELOG for the most accurate details on what ships with Kubernetes v1.35. If you’d like to get involved or keep up with ongoing discussions, consider joining the Kubernetes community through SIGs, community meetings, or forums. They’re a great way to both contribute and stay informed. 

Reduce your cloud bill and improve application performance today

Install in minutes and instantly receive actionable intelligence.
Explore what's new in Kubernetes v1.35- Pod Certificates, in-place updates, taint operators, OCI volumes, and more.
This is some text inside of a div block.
This is some text inside of a div block.

About the author

This is some text inside of a div block.
more from this author
Reduce your cloud bill and improve application performance today

Install in minutes and instantly receive actionable intelligence.

By clicking “Accept”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.