Not able to add "Node Pool with VMSS" in AKS cluster due to version mismatch

Manjunath8 K (Consultant) 0 Reputation points
2026-07-23T05:59:22.4666667+00:00

We were using AKS cluster with version 1.31.xx, when we were trying add "node pool" for AKS cluster it was giving below message:
This cluster is using a Kubernetes version no longer supported by the Azure Kubernetes Service. In order to add a node pool, the cluster must first be upgraded to a supported Kubernetes version.

Then we tried to upgrade cluster from 1.31.xx to 1.33.xx still we are facing same issue while trying to add node pool. If i upgrade from 1.33.xx to 1.34.xx does it fix ?

Azure Kubernetes Service
Azure Kubernetes Service

An Azure service that provides serverless Kubernetes, an integrated continuous integration and continuous delivery experience, and enterprise-grade security and governance.


2 answers

Sort by: Most helpful
  1. SUNOJ KUMAR YELURU 18,416 Reputation points MVP Volunteer Moderator
    2026-07-23T16:13:27.2866667+00:00

    Hello @Manjunath8 K (Consultant),

    Thank you for using Q & A forum.

    To resolve this issue, ensure that you upgrade your AKS cluster to a version that is still supported. You can check the available upgrades for your cluster using the command:

    Azure CLI

    az aks get-upgrades --resource-group <myResourceGroup> --name <myAKSCluster>
    

    After confirming the available versions, you can upgrade your cluster using:

    Azure CLI

    az aks upgrade --resource-group <myResourceGroup> --name <myAKSCluster> --kubernetes-version <desired_version>
    

    Make sure that the desired version is within the supported range for AKS. Once the upgrade is complete, you should be able to add the node pool without encountering the version mismatch error.


    If this answers your query, do click Accept Answer and Up-Vote for the same. And, if you have any further query do let us know.

    Was this answer helpful?

    0 comments No comments

  2. AI answer

    2026-07-23T05:59:44.4466667+00:00

    Upgrading to 1.34.xx is not the recommended fix based on the supported guidance.

    What to check first:

    1. Run:
         az aks get-upgrades --resource-group <resource-group-name> --name <cluster-name>
      
      This shows the supported upgrade targets for the cluster.
    2. If the version needed to add a node pool is not listed there, the cluster is still on a version path that AKS doesn't allow for that operation in the region.
    3. Check which versions are supported in the region:
         az aks get-versions --location <region> --output table
      

    Important version rules that affect this scenario:

    • A node pool version can't be greater than the control plane version.
    • A node pool version must be within two minor versions of the control plane version.
    • AKS doesn't allow downgrades.
    • You generally can't skip minor versions during upgrades unless the current version is unsupported.

    If the cluster was upgraded to 1.33.xx and adding a node pool still fails, the likely issue is that the target/addable versions available in the region and the cluster's supported upgrade path still don't permit the operation.

    The supported next step is:

    1. Verify the exact available upgrade target by using az aks get-upgrades.
    2. If AKS offers a supported full cluster upgrade target, upgrade the control plane and node pools together:
         az aks upgrade --resource-group <RG> --name <ClusterName> --kubernetes-version <available upgrade version> --yes
      
    3. After the cluster is on a supported version, try adding the node pool again.

    If az aks get-upgrades shows only newer supported versions and intermediate versions are missing, those missing versions are deprecated in that region.

    If the cluster is already in an outdated or skewed state, the recommended best practice is to create a new AKS cluster on a supported Kubernetes version and migrate workloads, instead of trying to step through multiple minor versions.

    So, upgrading from 1.33.xx to 1.34.xx only helps if az aks get-upgrades explicitly shows 1.34.xx as a supported target for that cluster and region. Otherwise, the correct action is to follow the supported upgrade targets shown by AKS, or recreate the cluster on a supported version.


    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.