Kubernetes 1.35: The Great Filter

I call Kubernetes 1.35 "The Great Filter."

Usually, a Kubernetes release is about what you get. This release is about what you lose.

The maintainers have finally pulled the plug on technical debt that has been lingering for a decade. If you are running a modern, well-maintained platform, you won't notice a thing. But if you are nursing old CentOS 7 nodes or relying on legacy networking hacks, this release will break your cluster. (This is why Platform Engineering is a full-time job).

Here is the damage report.

1. Cgroup v1 is Dead. Truly.

We knew it was coming. It's been deprecated forever. But in 1.35, the kubelet will refuse to start if it detects cgroup v1 — unless you explicitly set failCgroupV1: false in the kubelet config to opt out of the enforcement (a temporary escape hatch, not a long-term solution).

The Impact:

• If you are running older Linux distributions (Amazon Linux 2, CentOS 7, older Ubuntu), you cannot upgrade to 1.35 without either migrating to cgroup v2 or setting the override flag.
• Java applications that rely on old JDK versions might struggle to read memory limits correctly on cgroup v2.

The Fix: You don't patch this. You replace your nodes. Move to a modern OS (Amazon Linux 2023, Bottlerocket, Ubuntu 22.04+) immediately. The failCgroupV1: false flag buys you time but doesn't change the end state.

2. IPVS is Deprecated

For years, we used kube-proxy in IPVS mode because iptables was too slow at scale. But IPVS involved complex kernel module management and was a nightmare to debug.

Kubernetes 1.35 deprecates kube-proxy's IPVS mode under KEP-5495 — it still works and is still supported, but kube-proxy now logs a warning on startup when configured for it, and removal is targeted for a later release (currently v1.43). The direction is clear: new work is going into nftables (alpha in 1.29, GA and the recommended Linux mode since 1.33), and the longer-term path is bypassing kube-proxy entirely with eBPF (Cilium, Calico).

My Advice: Don't try to migrate to nftables unless you love pain. Just switch to Cilium (or a similar eBPF CNI) and replace kube-proxy entirely. It's 2026; you shouldn't be managing iptables rules.

3. The "AI" Stuff is Actually Good

It's not all doom and gloom. 1.35 introduces Dynamic Resource Allocation (DRA) for real this time.

Previously, if you wanted to attach a GPU to a pod, it was a hacky process. With DRA, resource drivers are first-class citizens. You can request "A slice of an A100" or "Any GPU with at least 24GB VRAM," and the scheduler actually understands it.

If you are building an AI platform, this is the feature that makes Kubernetes viable against Slurm.

4. In-Place Pod Resize (Finally GA)

This is the sleeper hit. You can now change CPU/Memory resources on a running pod without restarting it.

Why this is huge for Java apps:

• Java apps hate restarts (cold starts kill performance).
• Now, a Vertical Pod Autoscaler (VPA) can nudge the memory up during a traffic spike without killing the JVM.

The Verdict

Kubernetes 1.35 is a maturity test.

• Failing Grade: You spend 3 months fighting cgroup v1 migrations and fixing custom hacking scripts.
• Passing Grade: You update your node groups to the latest OS, flip a Terraform flag to update the control plane, and go get coffee.

Which one are you going to be?

Stuck on an old version? Contact us at Coding Protocols. We specialize in "un-breaking" legacy Kubernetes clusters.

Frequently Asked Questions

How do I know if my nodes still run cgroup v1?

Check the cgroup filesystem on a node — a v2 host mounts a unified hierarchy, a v1 host mounts separate controllers. Most distributions shipped in the last few years default to v2, but long-lived nodes built from an older image and never replaced are exactly the ones that will not upgrade. Replace the node image rather than trying to convert in place.

What changes for IPVS users in 1.35?

Nothing breaks yet. 1.35 deprecates the mode rather than removing it — IPVS still works, and kube-proxy simply logs a warning on startup when configured for it. Removal is targeted at a later release, so treat 1.35 as the signal to plan a migration to nftables or an eBPF dataplane on your own schedule. Check the kube-proxy ConfigMap now so you know whether this applies to you.

Is in-place pod resize safe to rely on now that it is GA?

For raising limits on a running workload, yes, and it removes a restart that used to be unavoidable. Two caveats: not every resource can be resized without a restart, and your application still has to cope with limits changing underneath it. Test the shrink direction specifically — that is where surprises live.

Should I upgrade straight to 1.35?

Only from a supported skew. Kubernetes permits a limited version gap between control plane and nodes, so a cluster several releases behind needs sequential upgrades rather than one jump. Read the deprecation notes for every version you pass through, since the removal that breaks you may be in an intermediate release rather than the target.

Official References

• Kubernetes v1.35 release announcement — the official feature roundup for the release
• Virtual IPs and Service Proxies — how kube-proxy's iptables, IPVS and nftables modes actually differ
• CHANGELOG-1.35 — the full changelog, including every API removal