Why Does Kubernetes Deprecate So Much? The Removal List Is a Payment Schedule

When Kubernetes release notes drop, I read the deprecation list before the feature list.

New features are optional. Deprecations aren't. A deprecation stamps an expiry date on a cluster that's running fine right now.

v1.37 (Garhwal) landed on August 26, 2026 with 16 stable, 23 beta, and 27 alpha items. One deprecation. By the numbers it looks like nothing. But that one entry bundles three things together, and all three were the defaults in older clusters.

What just got an expiry date

kube-dns is on its way out. CoreDNS became the default back in v1.13, which is ancient history, but a cluster built around that time and kept alive ever since may still be running kube-dns. The deadline is 1.40.

kube-proxy's IPVS mode is deprecated too. The replacement is nftables, and support ends in 1.43. IPVS showed up to solve iptables getting slower as rule counts grew. It never delivered the way people hoped, and that's the reasoning behind this decision.

cgroup v1 is a different situation. This isn't a warning about the future — it already happened. As of v1.35, a node that depends on cgroup v1 simply won't initialize. The replacement is cgroup v2.

In table form:

항목	대체	마감
kube-dns	CoreDNS	1.40까지
IPVS (kube-proxy)	nftables	1.43부터 중단
cgroup v1	cgroup v2	1.35부터 이미 노드 초기화 실패

These three don't carry the same weight

The deadlines aren't close to each other.

cgroup v1 is already past due. If you haven't been bitten yet, you either got lucky or you haven't upgraded that far. It fails as a node that won't come up.

kube-dns gives you until 1.40. Releases land roughly quarterly, so that's somewhere around nine months. Plenty of room to plan a migration and execute it.

IPVS gives you until 1.43, so more runway. But I'd argue the nftables migration is a heavier lift than swapping out DNS. You're changing the traffic path, and there's a lot to verify.

Three items under one "deprecation" heading: one is a failure you've already shipped, one is something you can schedule, and the last one gives you a long runway precisely because the prep is heavy. Release notes flatten all of that into a single line. The reader has to pull it apart.

Start with where your cluster actually stands

The thing to do after reading an article like this isn't reading more docs. It's finding out which of the three you're exposed to.

DNS first.

kubectl -n kube-system get deploy -l k8s-app=kube-dns
kubectl -n kube-system get deploy coredns -o jsonpath='{.spec.template.spec.containers[0].image}'

The k8s-app=kube-dns label is a trap. CoreDNS carries the same label for compatibility. Look at the image name if you want to know what's actually running.

Then the kube-proxy mode.

kubectl -n kube-system get cm kube-proxy -o yaml | grep -i "mode:"

Empty means iptables. If it says ipvs, start planning the move before 1.43.

Then the cgroup version on your nodes.

kubectl get nodes -o wide
# 노드에 접속해서
stat -fc %T /sys/fs/cgroup/

cgroup2fs is v2. tmpfs is v1, which means that node won't come up on your next upgrade.

Three commands and you know where you stand. Do this before you read another page of documentation.

Managed and self-run clusters are on different clocks

This is where it splits.

On EKS, GKE, or AKS, the provider handles control plane deprecations for you. In exchange, your upgrade schedule runs on their calendar. There's a fixed window in which you can defer, and once it passes you get upgraded whether you're ready or not.

Roll your own, or run a distribution like OpenShift or OKD, and it's a different story. Distributions don't track upstream directly — they trail it by a few versions while they validate. An upstream deprecation announcement doesn't hit your cluster right away.

That's a reprieve, not an exemption. No distribution can carry a feature upstream has already removed, indefinitely. Everything you skipped arrives later, all at once, in proportion to the lag. It's also why upgrades that jump several versions hurt so much.

A deprecation is an invoice with a date on it

Kubernetes looks unusually eager to throw things away, but that's mostly a good sign. A platform that only accumulates backward compatibility eventually becomes a lump nobody can touch.

The catch is that the cost of a deprecation accrues to whoever defers. Migrate when it's announced and it's planned work. Migrate after the deadline and it's incident response. Same work, different name on the calendar.

Checking your cgroup version after a node fails to come up and checking it because you read the release notes are the exact same action. One line: stat -fc %T /sys/fs/cgroup/. The only difference is whether you're typing it in the middle of the night or in the middle of the afternoon.

So I read the deprecation list as a repayment schedule, not as news. It's a table of what's due and when.

What to do with the next release notes

Three things.

One, pick out the deprecated items you actually use. Deprecations of features you don't run aren't worth reading.

Two, count the distance between each item's deadline version and your cluster's version. The number of releases left is the amount of time you have.

Three, check whether any deadline has already passed. If one has, that isn't a warning — it's a mine you've already stepped on. It goes off on your next upgrade.

One piece of good news in this release, by the way: the Metrics API finally graduated from beta to v1 after nine years. That's the API that reports CPU and memory usage. Nine years.