Microsoft just made it explicit: AKS is operationalizing continuous maintenance. Kubernetes 1.36 is GA on AKS with commercial long‑term support to June 30, 2028, and the docs now push weekly node‑image refreshes, structured three‑phase upgrades, and automated auto‑upgrade channels. If your platform team still treats node images like a quarterly checkbox, this release should make you change the way you run clusters.
What changed, concretely
- AKS 1.36 is GA and backed by a commercial LTS window that aligns with a formal cadence: a roughly 11‑month standard support period plus a two‑year LTS option that can extend support timelines through June 30, 2028 for qualifying releases. That gives enterprises a predictable timeline for compliance and EOL planning.
- The AKS release tracker and docs now show region‑by‑region availability and per‑image change notes for Azure Linux, Ubuntu, and Windows node images, removing ambiguity about when control‑plane or image updates arrive in a specific region.
- Operational guidance emphasizes more frequent node‑image updates (the docs recommend treating node images on a weekly refresh cadence where possible) and a three‑phase upgrade flow: control plane first, then system node pools, then user node pools. The guidance illustrates CLI flows with az aks get-upgrades and az aks nodepool upgrade to standardize day‑2 operations.
- Auto‑upgrade channels (rapid, stable, patch, and NodeImage) are promoted as the recommended mechanism to reduce manual churn and noisy, last‑minute support incidents.
Why platform engineers should care
This is not just versioning theater. Weekly node‑image patching plus automated channels change the operational model in two ways:
-
The failure surface moves from rare major upgrades to constant, small maintenance events. Weekly node‑image pushes will trigger reboots, kubelet restarts, or driver updates more frequently. If your CI/CD, alerting, and SLOs assume cluster immutability for months, they won't survive the new normal.
-
Predictability improves — if you accept automation. The regionized release tracker removes ambiguity about when new images and control‑plane versions hit each region, which enables scheduling and compliance windows. If you continue to run manual, ad‑hoc upgrades you lose the benefit and inherit the risk: cascading upgrades, surprise downtime, and higher support costs.
How to adapt (what actually changes in your runbooks)
Adopt the three‑phase flow and tie it into automation. Examples in the guidance use the az CLI to inspect and advance versions:
# Check available upgrades for a cluster
az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster
# Upgrade a node pool to a specific Kubernetes version
az aks nodepool upgrade --resource-group myResourceGroup --cluster-name myAKSCluster --name nodepool1 --kubernetes-version 1.36.1Don't stop at manual scripting. Use the NodeImage auto‑upgrade channel for routine OS and packaging patches and reserve the other channels (stable/patch/rapid) for control‑plane or feature timing you want to control. Ensure maintenance windows (many teams set at least four hours) for production rolling upgrades and align GitOps pipelines so they respect channel expectations.
Governance and cost implications
Formal LTS makes vendor support timelines predictable — useful for procurement and auditors — and lets you schedule migrations on a known horizon. The tradeoff is a higher cadence of small maintenance events, which can increase observed downtime if you lack automated draining, readiness probes, and rolling strategies that tolerate node churn. That's a people + tooling problem, not a vendor problem.
A blunt take
This is the right call from Microsoft. The previous AKS model rewarded inertia: teams could delay node image updates until something broke. Pushing regular image refreshes and making auto‑upgrade channels first‑class forces platform engineering to do the one thing that actually reduces operational toil — automate maintenance. If you ignore it, expect audit failures, surprise reboot storms, and expensive emergency upgrades.
A closing thought
AKS 1.36 isn't just a version bump; it signals a shift toward continual, predictable maintenance in managed Kubernetes. Platform teams that treat this as another release and automate their node‑image and upgrade channels will sleep better — everyone else will learn the hard way. For a deeper look at the AKS 1.36 rollout and node image decisions, see the earlier note on AKS 1.36 GA: Weekly node-image refreshes, kubelet cert rotation, and LTS options.