AKS just promoted Kubernetes 1.36 to GA and attached commercial long‑term support through June 30, 2028 — a concrete service-level for platform teams that removes one of the foggiest parts of running Kubernetes on Azure. The practical upshot: you can plan migration windows against a real LTS date, but you also have to start treating node images, auto‑upgrade channels, and add‑on patching as first‑class operational inputs, not optional hygiene.
This isn’t a marketing tick-box. Microsoft updated the AKS release tracker and supported-versions docs to show regional rollouts, node image updates, and core add‑on fixes more transparently. That matters because AKS is now an ecosystem of timed artifacts you must consume in order: control plane → system node pools → user node pools, with node-image channel alignment across pools. The operator guidance recommends regular node-image updates and stepwise Day‑2 upgrades; treat those sequencing recommendations as defaults.
Why the 2028 LTS date matters
Long support windows change behavior. With Kubernetes 1.36 on commercial LTS until mid-2028, teams get breathing room for large migrations and testing major platform changes (CNI, runtime updates, etc.). But the breathing room is asymmetric: the LTS buys you time for version-level compatibility, not for ignoring kernel, runtime, or distro end-of-life schedules. Microsoft has also published distro and node-image retirement timelines that may require node image migrations ahead of Kubernetes version EOL.
The simplest operational consequence: track two clocks. One is Kubernetes LTS/EOL (1.36 → June 30, 2028). The other is node image and distro lifecycles, which often require earlier action. If you treat Kubernetes upgrade scheduling as the only deadline, you will get surprised.
What to change in your pipelines
Azure's operator guidance codifies sequencing and gives clear recommendations: use auto-upgrade channels (stable is recommended for production; rapid for early testing; patch for security-only fixes), attach node-image channels to node pools, size maintenance windows conservatively, and run upgrades in a control-plane → system → user order. In practice that means:
- Prefer channeled upgrades over manual one-off minors; they reduce blast radius and align you with tested node images.
- Automate regular node-image refreshes and treat them like security patch windows — not optional maintenance events.
- Use staged node pool rollouts (canaries) and validate CRDs, CSI drivers, and network plugins before rolling across regions.
If you haven't dug into the node-image channel concept yet, make time this week. The node image contains the kernel, container runtime, and distro bits — and Microsoft publishes those updates in the release tracker so you can automate consumption rather than react to post-upgrade breakages. If you want a quick refresh on the operational pieces Azure expects you to adopt, read the AKS auto-upgrade channel recommendations and the node-image guidance in the operator guide — they are prescriptive for a reason. See also our previous note on AKS auto-upgrade channels and maintenance windows: AKS auto-upgrade-channel: node-image channel, stable/rapid/patch, and a 4-hour maintenance window and the node image update guidance: AKS node image v20260619: guidance for weekly kernel, kubelet, and runtime updates.
A blunt opinion
This is the right call from Azure. Platform teams needed precise SLAs and a machine‑readable release surface to stop firefighting. What’s overdue is that some teams will still treat AKS like a managed black box and ignore node-image channels, regular refreshes, and distro EOLs. That will cause late nights when older Kubernetes or node-image lifecycles cross their EOL dates.
Final bit: the signal here is consistency. Azure is turning upgrade cadence and node-image churn into predictable, consumable artifacts. If your CI/CD and chaos-testing processes aren’t ready for frequent node-image shifts and staged control-plane upgrades, now is the time to build them. Otherwise you’ll be planning one big migration instead of a steady, automated drift — and steady is always cheaper.