Kubernetes 1.35 Ships: What's Actually New for Platform Teams in July 2026

The headline: a boring release, in the best possible way

Kubernetes 1.35 was cut this week, and the release notes read the way platform teams have been asking them to read for years — fewer flashy alpha features, more graduations of the primitives that people already depend on in production. Sidecar containers, dynamic resource allocation, in-place pod resize, and structured authorization all move forward. The upgrade risk is low for most clusters, and the operational payoff for platform teams is meaningful.

This is the second release cycle in a row where the release team has visibly prioritised stability over surface area. That is a good thing. Every enterprise Kubernetes distribution — EKS, GKE, AKS, OpenShift, Rancher — will start rolling 1.35 into their supported channels over the next two to four months, and by the end of the year 1.35 will be the default for most new clusters.

Sidecar containers are finally stable

The single most requested feature in Kubernetes for the last five years graduates to stable in 1.35. A sidecar container is now a first-class concept: a container in a pod's initContainers list with restartPolicy Always. The kubelet starts it before the main containers, keeps it running for the pod's lifetime, and terminates it after the main containers exit.

For anyone who has hand-rolled ordering for Istio, Linkerd, Vault Agent, Fluent Bit, or an OpenTelemetry Collector, this is a real cleanup. The old pattern — a plain sidecar that could race the main container on start-up and refused to die cleanly on shutdown — is retired. Service meshes, log shippers, and secret-injection agents can now declare their intent explicitly.

Existing manifests keep working. The migration is a two-line change to the pod spec, and every major mesh and observability vendor has published updated Helm charts. Do the migration during a normal rollout window; it removes an entire class of pod-lifecycle bug reports from your on-call rotation.

Dynamic Resource Allocation reaches GA

Dynamic Resource Allocation (DRA) is the API that finally treats GPUs, TPUs, FPGAs, and other specialised hardware the way Kubernetes treats CPU and memory: as a scheduled resource with structured claims, driver-mediated allocation, and a proper lifecycle. It has been in alpha and beta for several releases; 1.35 ships it as GA.

For AI/ML platform teams this is the release that matters. The old device-plugin model was serviceable for a single GPU per pod but never handled shared, partitioned, or dynamically composed accelerators cleanly. DRA does. NVIDIA's driver, the AMD ROCm driver, and the Intel Gaudi driver all have GA-quality DRA implementations shipping alongside 1.35. If you are running Kubeflow, Ray on Kubernetes, or a home-grown training platform, plan a proof-of-concept against DRA in the next quarter.

The knock-on effect is scheduling quality. Because DRA claims are part of the scheduler's view of the world, bin-packing improves dramatically for mixed CPU-and-GPU workloads. Teams running fleets of A100, H100, and B200 nodes have reported five to fifteen per cent utilisation improvements in preview.

In-place vertical pod resize, beta by default

Vertical pod resize without restart moves to beta on by default in 1.35. The kubelet can now grow or shrink a running container's CPU and memory requests and limits without killing the pod. For stateful workloads — databases, in-memory caches, long-running batch jobs — this removes one of the last legitimate reasons to keep vertical pod autoscaling turned off.

There are caveats. Not every workload tolerates a live memory-limit change gracefully, and some CNI and CSI plugins still assume a pod lifecycle event on resource change. Test in staging before enabling on stateful sets in production. But for the majority of long-lived services, in-place resize meaningfully reduces the operational cost of right-sizing.

Security and policy: fewer feet, fewer bullets

Structured authorization configuration graduates to stable. Cluster admins can now express authorization as an ordered list of Webhook, RBAC, and Node authorizers via a config file, instead of a fragile stack of command-line flags on the API server. For anyone who has ever tried to add a webhook authorizer to an existing cluster without an outage, this is a real improvement.

Admission webhooks gain finer-grained match conditions using CEL expressions. That means you can write a validation rule that runs only on pods in a specific namespace with a specific label, rather than firing on every admission request in the cluster. The performance win is real, and the blast radius of a misbehaving webhook drops accordingly.

Two smaller but consequential changes: service account tokens now carry richer node and pod claims by default, which downstream tools like external-secrets and workload-identity providers can use for finer-grained authorization; and anonymous auth is now much easier to restrict to a narrow allowlist of endpoints instead of turning it off entirely.

What is being removed or deprecated

Every 1.x release retires something. In 1.35 the notable removals are the legacy in-tree cloud provider code paths for the smaller clouds — everyone should be on the out-of-tree cloud-controller-manager by now, but confirm before you upgrade. Several kube-proxy flags related to the older iptables implementation are deprecated in favour of the nftables backend, which is now the default on new clusters. And the last of the cgroup v1 fallback code has been removed from the kubelet for new nodes; if you are still running a distribution pinned to cgroup v1, that is a signal to plan the migration this quarter.

None of these are surprises. They have all been on the deprecation timeline for at least two releases. Read the release notes' removals section before you upgrade, not after.

Practical upgrade advice

For managed clusters, wait for your provider's supported track. EKS, GKE, and AKS typically publish 1.35 within eight to twelve weeks of upstream cut, and rushing ahead of that window buys nothing.

For self-managed clusters, the safe path is unchanged from previous cycles. Upgrade the control plane first, one minor version at a time. Confirm that every admission webhook, CSI driver, CNI plugin, and operator you depend on is certified for 1.35 before touching the nodes. Drain and upgrade nodes in small batches, monitor pod restart rates and API server latency, and keep an old node group around for at least a week so a rollback is a scale-up rather than a rebuild.

Two specific things to test in your staging cluster before promoting: any workload that uses vertical pod autoscaling, and any workload with a service mesh or logging sidecar. Those two areas absorb the most behavioural change in 1.35, and they are where subtle regressions have historically appeared.

The bigger picture

Kubernetes is now sixteen releases into what most platform engineers would call a maturity phase. The core API is stable, the extension points are well understood, and each release is measurably about polishing what is already there rather than expanding scope. That is exactly what you want from the substrate underneath your production platform.

If you have been putting off a 1.33 or 1.34 upgrade, 1.35 is a good target to jump to directly. Sidecars alone will pay for the migration in reduced pod-lifecycle bug reports, and DRA opens the door to running your AI workloads on the same clusters as everything else without a bespoke scheduler. This release does not change how you think about Kubernetes. It just makes the version you are already running better.