Keeping it current, watched, and affordable

Every cluster has two surfaces that age, and confusing them is a common early mistake. The first is the Kubernetes version — the control plane and the kubelet on each node, moving together from 1.29 to 1.30 to 1.31. The second is the node image — the operating system on the node VMs, which needs security patches for the same reason any Linux box does, whether or not Kubernetes itself moves. You can patch the node image on Tuesday without touching the Kubernetes version, and you often should. They are two different clocks, and a mature team watches both.

The reason this is ongoing rather than a one-off is the release train. Kubernetes ships roughly three minor versions a year, and each version is supported for only a window before it falls off the back — AKS will eventually stop giving you security fixes for a version that has aged out, and can force an upgrade to keep the cluster in a supported state.¹ So "we upgraded last year" is not a finished task; it is a lap. Plan for upgrading as a standing rhythm, not an event, and the day a version goes end-of-support arrives as a calendar entry you already knew about rather than a surprise.

Doing every upgrade by hand does not scale past one cluster, so AKS gives you auto-upgrade channels — one per surface, because the two clocks tick at different rates. The cluster autoupgrade channel governs the Kubernetes version: patch takes the newest patch release inside your current minor version, and stable and rapid carry you across minor versions on different appetites for newness. A separate node OS autoupgrade channel governs the node image: NodeImage takes a freshly patched, AKS-tested VHD — security fixes and bug fixes together — on a weekly cadence. Subscribe both channels, each at the cadence it can tolerate, and the cluster stops being a thing you must remember to feed.

Pair an auto-upgrade channel with a planned maintenance window, such as Sunday 02:00–06:00, so routine disruptive upgrades are scheduled for a known low-traffic period. AKS recommends at least four hours for a Standard-cluster upgrade window. A window is not an absolute promise: urgent or reactive platform maintenance can occur outside it. Schedule a period when engineers can respond, not simply when everyone is asleep. The channel selects eligible updates; the window constrains when planned changes begin. You still need a tested workload and an alert if it stops serving.

The channel picks what. The window picks when.

An upgrade replaces nodes: each old node is cordoned, its pods are evicted, and a node on the new version takes its place. If the pool is nearly full, removing a node before replacement capacity is ready may leave pods Pending. With max surge, AKS provisions temporary extra nodes before draining old ones. That gives the scheduler somewhere to place evicted pods and reduces the risk of lost capacity. It does not guarantee availability: the surge node must actually provision, the subnet and quota must have room, and applications need enough replicas, readiness checks, and workable PodDisruptionBudgets.

max surge limits the extra nodes, as a count or percentage of the pool. More surge can shorten an upgrade but requires additional VM quota and IP capacity, briefly increases compute cost, and can increase simultaneous disruption. Before raising it, check the node pool's quota and subnet, set an appropriate PodDisruptionBudget, and test the upgrade in non-production. Watch node and pod readiness through the window. A configured surge is a capacity plan, not proof that each app remains available.

az aks get-upgrades -g "$RG" -n "$CLUSTER" -o table     # versions you may move to
az aks nodepool show -g "$RG" --cluster-name "$CLUSTER" -n nodepool1 \
  --query "{version:orchestratorVersion, surge:upgradeSettings.maxSurge, count:count}" -o table
kubectl get pdb -A                                          # budgets that may block a drain
kubectl get deploy -A -o custom-columns=NAME:.metadata.name,READY:.status.readyReplicas,WANT:.spec.replicas

You need to see logs, metrics, and dashboards, and the old reflex is to self-host that stack — run your own Prometheus, nurse your own Grafana, keep the log pipeline alive. On AKS you do not have to, and mostly should not. Azure gives you a managed trio that plugs into the cluster and is operated for you, so the observability layer is not one more thing on your pager. You wire it on at cluster create or after, and the pods, nodes, and control plane start reporting into tools you did not have to keep alive.

The division of labour is worth learning. Container Insights can collect container logs and inventory into Azure Monitor and Log Analytics. Azure Monitor managed service for Prometheus collects Prometheus-format metrics when configured. Azure Managed Grafana visualizes connected data sources; it does not replace the metric store. Each service needs setup, access control, retention choices, and a cost check. Start with the signals needed for one useful alert rather than turning on everything without a question to answer.

On the AKS Free tier, there is no paid control-plane tier charge, but the cluster still uses billable Azure resources. Node VMs are often a major line; managed disks, load balancers, public IPs, log ingestion, metrics, and network traffic can matter too. Open Cost Management or AKS cost analysis and identify the actual resource groups, services, and trend before changing capacity. Cutting a node does little if the unexpected line is telemetry or storage.

If compute is the problem, compare pod requests with measured use and right-size the pool. The cluster autoscaler adds nodes for unschedulable pods and can remove unneeded nodes within its configured bounds; it does not reduce Deployment replicas just because customer traffic stops. Spot pools may fit jobs that tolerate eviction. A user pool can scale to zero when it has no required pods, but the system pool remains and non-compute costs continue.² To be ready at 06:00, arrange a tested trigger or schedule that creates the pods and nodes early enough to warm up. A request arriving at 06:00 is not a reliable wake-up plan for a synchronous partner API.