Kubernetes versions age out on a schedule, and AKS only supports a rolling window. Fall off the back of it and you're running unsupported infrastructure under production, usually discovered at the worst moment.
Kubernetes ships a new minor version every few months, and AKS supports only a rolling window of the most recent ones. Your cluster's version is therefore a slowly-expiring asset. Ignore it long enough and one day you're running a version Azure no longer supports: no security backports, no help on the path you care about, under your production traffic. Nobody decides to be there. Everyone who's there got there by not deciding.
The cruelty is in how it compounds. Stay current and each upgrade is one small, boring hop. Fall three versions behind and you can't leap straight to current. You must walk the hops in sequence, each with its own deprecations and surprises, and you're now doing all of them under time pressure because support already lapsed. One deferred upgrade quietly becomes a forced multi-upgrade weekend.
The fix isn't heroic, just deliberate:
This is the most preventable incident in all of AKS. It announces itself months in advance, on a public schedule, with plenty of warning. The teams who get caught aren't unlucky. They just treated "upgrade the cluster" as something with no deadline, right up until it had a very urgent one.
Want this distilled for your stack? Ask the assistant for the key takeaways or related reading.
Keep reading
Most AKS upgrade outages aren't upgrade bugs. They're a missing PodDisruptionBudget: five lines of YAML standing between a rolling node drain and all your replicas dying at once.
Sathpal-OS