[Launched] Generally Available: Azure Firewall integration in Security Copilot
April 30, 2025[In preview] Public Preview: Azure Virtual Network Manager high-scale connected group
April 30, 2025When you support Azure Kubernetes Service (AKS) clusters, keeping up with new versions of Kubernetes being released, and ensuring that your clusters are on a supported version can be difficult. If you have one or two clusters it might be OK, but as your estate grows it can be difficult to keep on top of which clusters have which version of Kubernetes and which needs updates.
One way of dealing with this could be to implement Azure Kubernetes Fleet Manager (Fleet). Fleet provides a comprehensive solution for monitoring Kubernetes and Node Image versions in your clusters, and rolling out updates across your estate. You can read more details on Fleet for update management here.
However, if you’re not ready to implement Fleet, or your AKS estate isn’t large enough to warrant it, we can build a solution using resource graph and Azure workbooks that can provide an overview of all your current AKS clusters Kubernetes versions, and which have pending upgrades.
Collecting Data
To be able to create our report, we need two pieces of information:
- The version of Kubernetes deployed on each AKS cluster
- The currently supported versions of Kubernetes in AKS
The first piece of information we can get using a Resource Graph Query.
Resource Graph allows you to query and explore your Azure resources using the Kusto Query Language (KQL).
We can query for any AKS clusters in our subscriptions and get the Kubernetes Version property.
resources
| where type =~ ‘microsoft.containerservice/managedclusters’
| extend currentVersion = tostring(properties.kubernetesVersion)
| project id, name, currentVersion
Running that in Resource Graph Explorer confirms that we get the data we need.
The second piece of information, the supported versions of Kubernetes, is not available through the Resource Graph. We can get this information from an Azure CLI command:
az aks get-versions –location eastus –output table
The location should be set to wherever your clusters are, to get versions specific to your location. Version updates roll out to different regions at different times. You can track which releases are in which regions using the AKS Release Tracker.
This command outputs a table of versions of Kubernetes that are supported on AKS, along with more details about the support plan (standard or LTS) and patch versions.
We could manually compare the two values, but that’s not going to scale, so we now need to bring these two pieces of data together create an automated report.
Azure Workbook
We need to build a report that will allow us to show all clusters that have upgrades available based on the data we saw above. Azure Workbooks allow us to query data from various different places in Azure to build our report.
Create a Workbook
To build our report we will be using Azure Monitor Workbooks, which allow us to bring multiple different Azure data sources into a single report and visualise the data. We need to create a new workbook and open it for editing.
- In the Azure Portal, search for “Azure Workbooks” and click to open the workbooks page
- Click “create” to create a new workbook, and then select the empty workbook option from the quick start list
You should now have an empty workbook, ready for you to add content.
Supported Versions
Getting the supported versions of Kubernetes into our report is probably the trickiest part of creating this report. We can’t just run an Azure CLI command in an Azure workbook, so we can’t replicate what we did above. However, the CLI is calling an Azure Resource Manager API, and we can call those from our workbook using an Azure Resource Manager query.
- In our workbook, go to the Add button and click Add Query
- In the Data Source drop down select “Azure Resource Manager”
- Leave the method set as “GET”
- In the “Path” box enter a path with a value similar to below” but replacing “SubscriptionId” with your own subscription. This can be any subscription you have access to, it does not need to contain the AKS clusters, but the region selected should be correct to ensure the versions returned are appropriate for your clusters.
/subscriptions/{SubscriptionID}/providers/Microsoft.ContainerService/locations/westeurope/kubernetesVersions?api-version=2025-02-01
Your query should look similar to this:
If you click “Run Query” you should get a JSON document back with details of supported AKS versions.
Whilst this provides us with enough information to get the data we need, it’s not going to look great on your report. We also want to allow the user to select which version they want to query against, so let’s clean it up.
- Select the “Results Settings” tab
- Switch the format from “Content” to “JSON Path”
- Configure the JSON Path settings as in the image below to give as a nice table that shows the version and the support plan.
If we now run the query we should have a nice table:
The last thing we want to do is allow the user to select the version of Kubernetes they are interested in, and set this is a parameter so we can use it in our Resource Graph query.
- Click on the “Advanced Settings” button
- Check the “When items are selected, export parameters” box
- Click the “Add Parameter” button
- Set the “Field to Export” to “version” and then set “Parameter Name” to any name you wish
Your advanced settings page should look like this, feel free to set some of the other fields like titles and no data messages if you wish.
Click done editing to commit your changes.
Resource Graph
Now we have our supported versions, we can create a Resource Graph query which will find the clusters that have a version of Kubernetes older than our selected supported version.
- We’ll once again click and and go to query
- In the Data Source dropdown select “Azure Resource Graph”
- keep the resource type as “subscriptions” and then set the subscriptions drop down to either the subscriptions you are interested in, or all subscriptions
- In the query box, enter the query below. We’ll break down what this is doing in a moment.
resources |
where type =~ ‘microsoft.containerservice/managedclusters’
| extend currentVersion = tostring(properties.kubernetesVersion)
| extend orchestratorVersion = “{k8VersionNum}”
| extend parsedClusterVersion = parse_version(currentVersion), parsedOrchestratorVersion = parse_version(orchestratorVersion)
| where parsedClusterVersion < parsedOrchestratorVersion
| project id, name, location, currentVersion, orchestratorVersion
If you select a version in the supported versions list we created earlier, then click “Run Query” you should get a list of AKS clusters back, assuming you have clusters running older versions.
Here’s what this query is doing:
- Finding all resources with a type of “microsoft.containerservice/managedclusters”, which is the resource type for AKS clusters
- Getting the Kubernetes version from the cluster and assigning it to a variable called “currentVersion”
- Get the “k8VersionNum” variable that we set in the previous step and putting it in a variable called “orchestratorVersion”.
- Using the parse_version function to parse these two strings into version numbers that can then be numerically compared
- Checking if the cluster version is lower than the selected Kubernetes version
- Projecting the values we want to see on the report.
The final step we’re going to add is to hide this section when no Kubernetes version is selected in the top table. This avoids the page showing an error when the parameter is empty.
- Click on the “Advanced Settings” tab
- Check the “Make this item conditionally visible” box
- Click add condition, and then enter the name of your parameter, in my case k8VersionNum. Set the drop down to be “is not equal” and leave the value empty, so it shows “not set”
You can also optionally update the “No Data” message so that it shows a success message indicating there are no clusters with pending updates, when the query is empty.
Completed Workbook
After adding a few Markdown text fields to make the report more usable, and then saving the workbook, we can publish our solution.
You can also find the full workbook definition code here, you just need to update the subscription ID.
Alternative Workbook
If you would like to reverse the approach we took, and be able to select an AKS cluster and see what upgrades are available for that cluster you can use this code to create the workbook.