Kubernetes 1.35: what you can already see coming

Actualizado: 2026-05-03

Kubernetes 1.34 landed in August 2025 with important changes in native sidecars, init containers, and the first stabilization wave for WaitForFirstConsumer in generic-volume mode. The 1.35 cycle has entered feature freeze, preliminary release notes are in the repository, and the stable three-releases-per-year pattern keeps working like clockwork. Time to look at what’s coming, what deserves real attention, and what can safely be left for another day.

Key takeaways

• CEL-based admission policies land stable in 1.35: they replace admission webhooks with expressions evaluated inside the control plane, eliminating an external failure point.
• DRA (Dynamic Resource Allocation) lands stable for several accelerator types: GPU, NPU, and specific accelerators with a richer API model than device plugins.
• The new KubeletConfigSource API allows pushing kubelet configuration without node restart.
• Several expected features stay in beta: zone-based PodAffinity/PodAntiAffinity and in-place pod resize.
• The healthy operational pattern is staying one version behind the latest stable and reading the full release notes before planning the upgrade.

Context: where we come from in the 1.3x cycle

Since 1.30, the project has prioritized stabilization over novelty. The cultural key is that the project has accepted that for most users Kubernetes is infrastructure, not product. Big philosophy changes are rare; what dominates are incremental improvements in robustness, operator experience, and edge-case coverage. 1.35 continues that line.

The news that actually matters

CEL admission policies (stable). The operational difference is significant: an admission webhook that goes down blocks the cluster; a CEL expression evaluated inside the control plane has no such risk. For small clusters where every external dependency is one more piece that can fail at 3 AM, replacing webhooks with CEL reduces incidents.

General DRA for accelerators (stable). DRA replaces the old device-plugin model with something richer and more expressive: accelerators can declare detailed capabilities (not just count), Pods can request accelerators with more granular criteria, and accelerator sharing between Pods is facilitated when hardware allows. For teams running GPU or NPU workloads, DRA is the way forward. If you don’t have accelerators, DRA is transparent.

KubeletConfigSource API. Previously, changing kubelet configuration meant rotating the node or manipulating system files and restarting the service. With the new API, the control plane can push fresh configuration to the kubelet without restart. For teams with many nodes, this significantly changes how configuration updates are operated.

What stays in beta

Zone-based PodAffinity/PodAntiAffinity: been in beta since 1.32 with edge cases under scheduler load. Not a blocker for production use if already configured, but worth waiting for 1.36 stabilization before refactoring placement policies.

In-place pod resize: CPU and memory request changes without pod restart. Subtle kernel and runtime implications in practice. Beta with explicit feature gate. For stable workloads not a priority; for dynamic workloads validate in test environments first.

How to plan the upgrade

The recommendation for a small or medium production cluster is to always stay one version behind the latest stable: right now that means 1.33 in production, 1.34 in test environments, with 1.35 under observation once the release candidate ships. This one-version lag gives time for first-hour bugs to be found and fixed in minor patches, but not so far back as to lose official support (only the last three versions are supported).

This upgrade discipline is analogous to what’s applied in PostgreSQL 18 and any critical infrastructure: test first, controlled propagation, don’t update everything at once.

Serious upgrade problems rarely come from the control-plane binary; they come from custom resources, admission webhooks, volumes with exotic CSI, or networking with CNIs that didn’t keep up. That’s where to invest test time: not in running the upgrade itself, but in verifying the full environment works correctly afterward. For teams running Kubernetes with AI systems on top, upgrade tests must include that Wasm workloads and observability components keep working correctly with the new version.

My reading

Kubernetes 1.35 is one more incremental release in a series of incremental releases, and that’s fine. CEL for admission, general DRA for accelerators, and the kubelet-configuration API are useful and cover real cases without breaking anything. Those staying in beta deserve attention but not rushed adoption. The healthy operational pattern: upgrade with discipline, one version behind the latest, read the release notes seriously, and let others discover the first-day bugs.