Kubernetes is now explicit: the cgroup v1 fallback is being removed as part of the v1.38 cycle. v1.38.0-alpha.2 is the public marker — the code and changelog are up, and the roadmap no longer treats cgroup v1 as a supported operating mode to fall back to. If any production nodes in your fleet still boot with cgroup v1, an upgrade to Kubernetes 1.38 will not be a soft nudge — it will be a hard stop.
This isn't theoretical. The Kubernetes blog and release stream lay out the move toward cgroup v2; recent release lines still accepted a v1 fallback, but the upcoming cycle schedules its removal. That aligns with upstream runtime work and what container runtimes and tooling have been shipping: runc and containerd builds with cgroup v2 support are the safe target. Docker Desktop and runtime releases have signaled the direction; your cluster's node image, kernel command line, and runtime all need to be on the same page before you flip the kubelet into a v1-free world.
The operational impact is blunt: kubelet startup will fail on nodes that only support cgroup v1 when the fallback is disabled or removed. Pods can get stuck Pending, nodes can show NotReady, and you will see pager cycles. This is not a "best practice" advisory — it's an upgrade-time fatality if you don't test.
The checklist you should have on your radar right now
- Confirm kernel and distro support for unified cgroup v2 (systemd.unified_cgroup_hierarchy=1 or distro defaults). Some older kernels/distributions still default to v1.
- Verify your container runtime chain (containerd + runc). Ensure your runtime and runc builds include cgroup v2 support; older runtimes may fail or produce incorrect resource accounting.
- Exercise the kubelet behavior under cgroup v2 locally and in a staging pool. The community has warned about kubelet fail-on-v1 behavior; if you haven't seen that test fail, you haven't tested hard enough.
If you need a short pointer, our previous coverage on kubelet fail-on-cgroup-v1 explains the failure mode and where teams trip up: if the kubelet is configured (or defaults) to fail on cgroup v1, node boot and kubelet registration will not succeed. Treat that as your canary.
Pod Certificates and Cluster Trust Bundles — not another CSR problem
Parallel to the cgroup story, recent documentation has pushed Pod Certificates and ClusterTrustBundle features toward GA. These built-in X.509 mechanisms provide workload identity and cluster-wide trust distribution. For teams still gluing cert issuance into init containers or sidecar workflows, this is the right kind of platform-level capability: short-lived certs injected by the kubelet and a cluster-scoped trust bundle that simplifies mTLS trust stitching across control planes. This reduces bespoke cert plumbing — fewer fragile scripts and more platform primitives.
Meshery enters CNCF incubation — the management plane gets a seat
Separately, Meshery moved into CNCF incubation this week. It's not a control plane; it's a management plane — lifecycle, performance, and configuration management for cloud-native stacks. I think this is overdue and the right call: we have too many specialized control planes and not enough standards or tooling to manage them consistently. Meshery's CNCF berth gives the ecosystem a place to iterate on how we test, configure, and measure mesh and platform behaviors across distributions.
The housekeeping: the release stream also lists concurrent patch releases for older minor branches. Kubernetes continues to maintain several older minors in parallel — which is good news if you're juggling staggered upgrades, but it won't save you from the hard migration work on node cgroups.
Final take: the cgroup v2 deadline is not a suggestion. If your nodes aren't on unified cgroup v2 and your runtime doesn't support it, an upgrade to v1.38 will cause real outages. Treat the next few weeks like a compliance sprint: inventory kernels, validate runtimes, and run kubelet start-up tests under v2. Meanwhile, Meshery joining CNCF signals a sensible shift in priorities — the ecosystem finally admits that operating multiple control planes consistently is a platform problem, not a set of vendor features. If you want to avoid being paged on upgrade night, do the node-level work now; if you want fewer bespoke cert scripts, try the new Pod Certificates and ClusterTrustBundle features in your staging clusters.