If you have been following along with my blog, you may have come across some previous posts about updating Azure Kubernetes Service (AKS). One (https://pixelrobots.co.uk/2019/05/apply-os-updates-to-aks-nodes-without-an-upgrade/) talked about kured (KUbernetes REboot Daemon) by weaveworks https://github.com/weaveworks/kured. The issue with this method is it only supported Linux Kubernetes nodes. So, your windows Kubernetes nodes were left unpatched till a full cluster version upgrade. Not good. Recently Microsoft implemented a way to manually update the Kubernetes node image, which they update roughly once a week. You can read my post about it when it was in preview at https://pixelrobots.co.uk/2020/06/azure-kubernetes-service-aks-node-image-upgrade-preview/. Since then, Microsoft have made more improvements and now you can finally automate the node image updates. Below I will show you how.
Auto upgrade channels
You actually have a few options here:
Channel | Action | Example |
none | disables auto-upgrades and keeps the cluster at its current version of Kubernetes | Default setting if left unchanged |
patch | automatically upgrade the cluster to the latest supported patch version when it becomes available while keeping the minor version the same. | For example, if a cluster is running version 1.17.7 and versions 1.17.9, 1.18.4, 1.18.6, and 1.19.1 are available, your cluster is upgraded to 1.17.9 |
stable | automatically upgrade the cluster to the latest supported patch release on minor version N-1, where N is the latest supported minor version. | For example, if a cluster is running version 1.17.7 and versions 1.17.9, 1.18.4, 1.18.6, and 1.19.1 are available, your cluster is upgraded to 1.18.6. |
rapid | automatically upgrade the cluster to the latest supported patch release on the latest supported minor version. | In cases where the cluster is at a version of Kubernetes that is at an N-2 minor version where N is the latest supported minor version, the cluster first upgrades to the latest supported patch version on N-1 minor version. For example, if a cluster is running version 1.17.7 and versions 1.17.9, 1.18.4, 1.18.6, and 1.19.1 are available, your cluster first is upgraded to 1.18.6, then is upgraded to 1.19.1. |
node-image | automatically upgrade the node image to the latest version available. | Microsoft provides patches and new images for image nodes frequently (usually weekly), but your running nodes won’t get the new images unless you do a node image upgrade. Turning on the node-image channel will automatically update your node images whenever a new version is available. |
We are going to focus on the last option, which is new, node-image.
Register the preview feature
First, you need to register the preview feature. To do that use the following command.

After some time, the feature should be registered. You can verify by using the following command.

When the above shows registered you need to refresh the Microsoft.ContainerService resource provider. To do this just use the following.

To enable the node image to automatically update you can use the following command: Just make sure you change the resource group and cluster name to match yours.

This will now set the cluster to automatically update the node images. This could cause your application some down time depending on how you have set up your application. But it’s ok. Microsoft have your back with another new preview feature called Planned Maintenance. The auto updates will only happen during your maintenance window. So, check out my previous blog post on maintenance windows https://pixelrobots.co.uk/2021/03/first-look-at-maintenance-windows-on-azure-kubernetes-service-aks/. If you use both together you are going to have one happy secure cluster.
All in All
You can now automatically update your AKS node images, this means that you will always be up to date with security patches on both Windows and Linux. This is a big improvement over the older methods and one I will be implementing to my clusters wants it goes GA.
I hope you found this post helpful. If you have any questions, please reach out.
1 Comment
Ryan · May 26, 2022 at 5:06 pm
Thanks a lot for this article. This made this easy to implement and I guess I’ll see if my nodes upgrade the OS version during my maintenance schedule 🙂