Kubernetes is spring cleaning: kube-dns, IPVS, and cgroup v1 removed—what this means for your clusters

Kubernetes has just announced the deprecation of three historical components: kube-dns, the IPVS proxy mode, and cgroup v1 support. Decisions long anticipated, but which will require concrete migrations in many clusters. Kaito takes stock of what is disappearing, why, and how to prepare.

The context: Kubernetes cleans up its technical debt

Kubernetes (K8s for short) has been accumulating "deprecated" components for years—officially discouraged but still maintained for compatibility. The latest release changes the game: three components are making their final exit. No "deprecated" this time—just removed.

Let’s see what’s leaving, why, and what it means in practice.

kube-dns: replaced by CoreDNS long ago

What it is. kube-dns was Kubernetes’ historical DNS server, responsible for resolving service names within the cluster (myservice.mynamespace.svc.cluster.local). It has existed since the early days of K8s.

Why it’s leaving. CoreDNS has replaced kube-dns as the default DNS component since Kubernetes 1.13 (December 2018—nearly 8 years ago). CoreDNS is more extensible (plugins), more performant under load, and actively maintained by the CNCF. kube-dns hasn’t received meaningful updates in years.

What you need to do. If your cluster still runs kube-dns (check with kubectl get pods -n kube-system | grep dns), you must migrate to CoreDNS before upgrading K8s. The migration is well-documented and widely tested—it’s a standard procedure, not a major project.

# Check which DNS is running in your cluster
kubectl get pods -n kube-system -l k8s-app=kube-dns
kubectl get pods -n kube-system -l k8s-app=coredns

IPVS: the high-performance proxy mode that complicates detection

What it is. kube-proxy, the component that manages network routing in K8s, supports multiple modes: iptables (the historical default) and IPVS (IP Virtual Server, a high-performance Linux kernel module for load balancing).

Why it’s leaving. IPVS offers better performance at scale (lower latency, better scalability with many services), but its complexity has caused recurring debugging and interoperability issues with third-party CNI (Container Network Interface) solutions. The community has decided: modern networking solutions like Cilium or Calico handle load balancing at scale better without relying on IPVS.

What you need to do. If you’re using IPVS (visible in the kube-proxy config or via kubectl get configmap kube-proxy -n kube-system -o yaml), migrate to iptables mode or, better, adopt a modern CNI like Cilium, which handles load balancing in eBPF—more performant than IPVS and without its complications.

cgroup v1: the end of an era

What it is. cgroup (control groups) is the Linux kernel mechanism that isolates and limits resources (CPU, memory, I/O) allocated to processes—it’s the technical foundation of containers. Version 1 has existed since 2008; version 2 (cgroup v2, also called cgroupv2) has been available since Linux 4.5 (2016) and is the default in most modern distributions since 2021–2022.

Why it’s leaving. cgroup v2 offers a unified hierarchy (instead of v1’s multiple parallel hierarchies), better memory pressure management, and a more consistent interface for monitoring tools. Kubernetes has supported cgroupv2 since 1.25 (2022). The vast majority of modern clusters already run it.

What you need to do. Check your cgroup version with stat -fc %T /sys/fs/cgroup/. If the output is tmpfs, you’re on cgroup v1—migration is required. If it’s cgroup2fs, you’re already up to date.

# Check the active cgroup version
stat -fc %T /sys/fs/cgroup/
# cgroup2fs → v2 (OK)
# tmpfs → v1 (migration needed)

Migrating to cgroupv2 is typically done at the OS level (kernel boot option), not within Kubernetes itself. Consult your distribution’s documentation.

Key takeaways

These removals aren’t surprises—they’ve been announced for months. Kubernetes follows its classic deprecation policy: deprecated → removed over several releases. But “announced for months” doesn’t mean everyone has migrated.

Take inventory of your clusters now. A cluster running kube-dns, IPVS, or cgroup v1 won’t be able to upgrade to this Kubernetes version without prior migration. Better to know before the next maintenance window.