Kubernetes 1.35 ships with choices you can’t dodge: the project is removing cgroup v1 support, deprecating kube‑proxy’s ipvs backend, and signaling the end of the line for containerd 1.x after this release. There’s upside too—image volumes (OCI Volume Source) are poised to become a default‑on building block for quicker, slimmer deployments. Here’s what’s actually changing, what breaks, and the shortest path to a safe upgrade.
What’s shipping when? Your short timeline
The Kubernetes release team’s calendar is locked: docs freeze happened on December 2 (Anywhere on Earth) / December 3, 12:00 UTC; release candidates land December 2 and December 9; final 1.35.0 is planned for Wednesday, December 17, 2025. If you like to test RCs before flipping prod, this is your window. (k8s.dev)
Separately, the project’s monthly patch cadence targets a December patch on December 9 (for supported branches), useful for teams aligning maintenance windows the week prior to 1.35 GA. It’s not the 1.35 cut, but it helps sequence staging and prod changes. (kubernetes.io)
The three changes that will bite if you ignore them
1) cgroup v1 is out—move to cgroup v2 or your kubelet won’t start
Kubernetes has supported cgroup v2 for years, and 1.35 removes support for cgroup v1 entirely. Practically, nodes on older Linux distros without cgroup v2 will fail to start the kubelet. If you’ve been postponing that kernel/distro upgrade, this is the hard stop. Track the work in KEP‑5573 and the official sneak peek. (kubernetes.io)
Reality check: some enterprise images still boot with cgroup v1 for legacy reasons, and older container runtimes or custom tooling assume v1 paths. Inventory your nodes and flip them to the unified hierarchy now; test workload QoS and eviction behavior under cgroup v2 because pressure signals and limits differ.
2) kube‑proxy ipvs deprecation—nftables is the path forward
Maintaining feature parity between ipvs and other backends has dragged for several releases. In 1.35, ipvs mode is being deprecated to reduce technical debt; the recommended backend on Linux is nftables. There’s a KEP for the deprecation, and there’s an in‑depth post on nftables mode you can use to validate performance and compatibility. (kep.k8s.io)
Operationally, that means you should standardize on nftables going forward. Expect subtle differences around conntrack behavior and rules inspection workflows; update your runbooks and cluster build scripts accordingly.
3) containerd 1.x: last release with support
Kubernetes 1.35 is the final release that supports containerd 1.x (aligned with containerd 1.7’s support timeline). If you’re still on 1.7, plan your move to the 2.x series—2.2.0 is current as of November 2025—with enough bake time to catch CSI and CNI plugin edge cases. The containerd project’s releases page documents 1.7’s end of life and the 2.x cadence. (containerd.io)
What breaks? Mostly nodes that rely on older shims or custom hooks. Verify CRI settings, pause image handling, and snapshot/restore flows with your chosen runtime class before promoting 2.x in production.
What’s new that’s worth adopting?
Image volumes (OCI Volume Source) will likely be enabled by default
Image volumes let you mount OCI artifacts directly as read‑only volumes without bundling content into your container image or hacking it in via init containers. The feature started alpha in 1.31, graduated to beta in 1.33, and the 1.35 sneak peek signals it will likely be enabled by default in this release. It’s a clean pattern for shipping shared configs, binaries, or models. (kubernetes.io)
Why it matters: faster rollouts and smaller base images. In multi‑container pods, you can share an artifact across containers and keep the app image minimal, which reduces CVE surface and improves cache hit rates in your registry.
Production readiness: a 7‑day pre‑GA rollout plan
This is the playbook we’ve used on real clusters with low risk and high signal. Shift days to match your maintenance windows.
Day 1: Inventory and risk map
Pull a cluster‑wide report: node OS/kernels, cgroup version, kube‑proxy backend, container runtime versions, CNI/CSI versions. Flag anything on cgroup v1, ipvs, or containerd 1.7. If you manage multi‑cloud, align this across providers. If you’d rather not build this from scratch, consider our cloud architecture and platform services—we maintain a hardened discovery script that dumps the exact deltas you need.
Day 2: Stand up a 1.35 RC test environment
Spin a small non‑prod cluster on the same OS images you’ll run in prod. Install the latest RC (rc.0 is scheduled around December 2; rc.1 around December 9). Mirror your ingress, CNI, CSI, and two or three representative apps. (k8s.dev)
Day 3: Flip the hard switches
Enable cgroup v2 on test nodes (kernel boot params/systemd changes), switch kube‑proxy to nftables, and upgrade containerd to 2.2.x. Validate node pressure/evictions, service routing, and image pulls. Keep canary pods hammering service discovery and internal DNS. Reference the nftables article for backend specifics and troubleshooting cues. (kubernetes.io)
Day 4: Storage and registry moments
Test OCI image volumes against your registry (consider immutability and access rules). Check that your CSI drivers behave correctly with containerd 2.x and cgroup v2. Stage an artifact (config tarball or model) and mount it in a multi‑container pod to prove the pattern. (kubernetes.io)
Day 5: Security and policy
Run your admission policies and PodSecurity profiles against the new defaults. Double‑check any rules that referenced ipvs. Validate node‑level security agents and eBPF probes for compatibility with cgroup v2.
Day 6: Ingress strategy
If you’re still on ingress‑nginx, be aware the project announced retirement—use this moment to move to Gateway API (1.4 brings meaningful features). Deploy Gateway API in the test cluster and map a couple of key routes and retries. (kubernetes.io)
Day 7: Dry run the upgrade runbook
Time your cordons, drains, and rolling node upgrades. Track SLO impact during each phase and confirm rollback steps (snapshot etcd, keep an AMI or image with the previous runtime, and a kube‑proxy iptables fallback if you must). At the end of the day, write the change ticket with measured blast radius and a “stop” condition everyone understands.
Will my nodes really fail if they boot cgroup v1?
Yes—kubelet will fail to start on nodes that don’t support cgroup v2 once you move to 1.35. The project explicitly calls out removal of v1 support; plan distro and kernel upgrades before touching the control plane. (kubernetes.io)
Is ipvs truly dead? What do I need to change?
ipvs is being deprecated in 1.35; migration to nftables is the recommended path. Update bootstrap configs to set kube‑proxy’s mode to nftables, and refresh your runbooks—listing and debugging rules differs from iptables/ipvs habits. The nftables primer from the Kubernetes blog is the fastest way to retool your team. (kep.k8s.io)
Do I need containerd 2.0 or can I jump to 2.2?
Go straight to a current 2.x minor (2.2.0 as of November 2025). containerd maintains clear lifecycle tables: 1.7 exits active support ahead of March 2026; 2.0 reached EOL November 2025; 2.2 is active. Test CSI/CNI plugins for compatibility and pin versions accordingly. (containerd.io)
Field checklist: pre‑upgrade, during, after
Pre‑upgrade
- Confirm all nodes run cgroup v2; rebuild images if needed.
- Set kube‑proxy mode to nftables in cluster manifests.
- Upgrade containerd to 2.2.x and lock the package in your base image.
- Verify CSI/CNI compatibility matrices with your vendors.
- If applicable, stand up Gateway API while ingress‑nginx sunsets. (kubernetes.io)
During upgrade
- Cordon and drain in small batches. Watch node pressure signals under cgroup v2.
- Validate Service, EndpointSlice, and NetworkPolicy behavior under nftables.
- Smoke test image volumes: mount an OCI artifact and hit it from multiple containers.
After
- Run chaos tests against a few services (requests with retries, connection churn).
- Audit new cluster defaults and ensure admission/policy rules aren’t silently failing.
- Update SRE docs with nftables commands and cgroup v2 troubleshooting.
Data points worth bookmarking
Key dates: docs freeze for 1.35 was December 2 (AoE) / December 3, 12:00 UTC; rc.0 was planned for December 2; rc.1 for December 9; GA is planned for December 17, 2025. These schedules are public and are reliable guides for your change calendar. (k8s.dev)
Key lifecycle facts: containerd 1.7 support extends to March 10, 2026 (with extended nuances), 2.0 ended November 7, 2025, and 2.2 is the current active minor. Expect your OS repos and cloud images to start defaulting to 2.x. (containerd.io)
Edge cases and gotchas we’ve seen
Older CNIs with ipvs‑specific assumptions can misbehave under nftables. Do a controlled rollout and verify kube‑proxy logs for missing features. If you use eBPF‑based CNIs (Cilium, etc.), ensure kube‑proxy settings match your dataplane mode.
Security agents with kernel hooks sometimes flag different cgroup paths under v2, which can cascade into noisy alerts or blocked execs. Pre‑warm your SOC with the change so they don’t escalate false positives.
On air‑gapped clusters, containerd 2.x pulls and image volume mounts may need updated registry mirrors and CA bundles. Bake these into your node AMIs; don’t rely on day‑2 scripting to patch certificates.
Why image volumes matter beyond convenience
Decoupling app images from shared assets reduces rebuild pressure and mitigates CVE blast radius. For example, shipping a new model or config no longer requires a full container rebuild—just publish an OCI artifact and roll. The feature’s alpha (1.31) and beta (1.33) history means it’s battle‑tested, and the 1.35 signal is that the community believes it’s ready for prime time. (kubernetes.io)
Ingress next steps: moving off ingress‑nginx
The ingress‑nginx project has announced retirement guidance. Don’t wait for surprises—Gateway API 1.4 delivers features teams used to depend on in ingress controllers (mature routing, retries, and more). Plan your transition well before your next LTS cycle. (kubernetes.io)
What to do next (developers and platform leads)
- Platform: Freeze new node group rollouts on cgroup v1 now. Reimage with cgroup v2 and containerd 2.2.x.
- Networking: Flip kube‑proxy to nftables in non‑prod this week; validate observability and rule inspection.
- App teams: Adopt image volumes for shared assets; remove init‑container hacks that copy files around.
- Security: Re‑baseline admission and PodSecurity policies under new defaults.
- Leads: Book a two‑hour game day to practice canarying the control plane and draining nodes.
Need a second pair of hands?
If you want a pragmatic partner who’s done this across AWS, GCP, and hybrid, our team can run the readiness assessment, flight test RCs, and co‑pilot the cutover. Start with our what we do overview, browse relevant work in the portfolio, or reach out via contact us—we’ll bring a clear plan and hold the pager with you.
Zooming out
Here’s the thing: 1.35 isn’t chasing shiny objects; it’s consolidating the platform so clusters are simpler to operate in 2026. That means less legacy surface, fewer divergent paths, and a more consistent runtime story. Make the moves now and your 2026 on-call will thank you.
If you want more on multicloud routing, networking, and service design choices, our AWS interconnect guide is a solid companion read for platform teams juggling multiple providers. (kubernetes.io)
Related read: our latest pieces on cloud and AI operations on the Bybowu blog continue to track the practical changes that matter to engineering leaders.
