What's new in Kubernetes, and what I'm upgrading for

Kubernetes releases a new minor version roughly three times a year. Every release comes with a long changelog, a blog post full of enhancement numbers, and a list of features moving from alpha to beta to stable. It's easy to skim it and move on.

But a few changes in each release really do affect how we run clusters. And some of them, the removals, can break things on upgrade day. Here's how I read a release, and the recent changes I think matter most.

How I read a Kubernetes release

I look at four things, in this order:

1. Removals and deprecations. What will break if I upgrade? This is the only section that can hurt you.
2. Features going stable (GA). These are safe to rely on and usually mean I can drop a workaround or an add-on.
3. Features going beta. Often enabled by default now, worth testing.
4. Everything else. Interesting, but rarely urgent.

Recent highlights worth knowing

Over the last few releases, several long-awaited features have become stable. These are the ones I see making a real difference:

Native sidecar containers. Sidecars (log shippers, proxies, agents) used to be ordinary containers with no guaranteed start or stop order. Now you can declare them as init containers with restartPolicy: Always: they start before the main container and stop after it. That fixes a whole family of annoying bugs, like jobs that never finish because the sidecar keeps running.

In-place Pod resource resize. You can change a running pod's CPU and memory requests and limits without restarting it. Great for workloads that need more resources at startup, or for vertical autoscaling without disruption.

Dynamic Resource Allocation (DRA). A flexible way to request specialised hardware, especially GPUs, with more detail than a simple count. Important for anyone running AI workloads.

Gateway API maturity. Not part of core Kubernetes releases, but tied to them in practice. With ingress-nginx retired, Gateway API is now the default way to get traffic into a cluster. I wrote about that migration in Goodbye ingress-nginx, hello Gateway API.

Removal of old foundations. The move away from cgroup v1 and older container runtime versions has continued. If your nodes run an old Linux distribution or an old containerd, check the release notes carefully before upgrading.

A Kubernetes upgrade rarely breaks because of new features. It breaks because of the old thing you forgot you were still using.

My upgrade checklist

Whatever the release, my routine is the same:

1. Read the deprecations and removals. All of them, even if it's boring.
2. Scan for deprecated APIs in the cluster and in your manifests with tools like Pluto or kubent:

pluto detect-all-in-cluster
pluto detect-files -d ./manifests

3. Check your add-ons. Ingress or Gateway controllers, CNI, CSI drivers, cert-manager, monitoring agents, service mesh. Each one has its own supported Kubernetes versions.
4. Upgrade a non-production cluster first and let it run for a while.
5. Upgrade the control plane, then node pools, one minor version at a time. Kubernetes doesn't support skipping minor versions for the control plane.
6. Watch PodDisruptionBudgets. A PDB that allows zero disruptions will block node drains.
7. Have a rollback plan for nodes. Control planes usually can't be downgraded, but node pools can be recreated.

How often to upgrade

Each Kubernetes minor version gets about a year of patch support upstream. Managed services like EKS, AKS and GKE have their own windows, and some charge extra for extended support of old versions.

My rule: stay within one or two versions of the latest. Upgrading regularly in small steps is much less painful than a big jump every two years, when everything is deprecated at once.

Worth upgrading now?

Usually yes, once the first patch release (x.y.1 or x.y.2) is out and your managed provider supports it. Stable features like native sidecars and in-place resize are worth having, and staying current means security fixes keep coming.

My take: read the removals first, test on a cluster you don't love, and upgrade often enough that it never becomes a project.

— Desly