AKS Node Count Increase Fails: Cluster Being Deleted Error

What You're Dealing With

I've seen this exact error crop up after a botched autoscaler update—someone tries to tweak min/max counts or scale a node pool, the operation rolls back or times out, and suddenly the cluster's provisioning state is stuck. Then any subsequent scale operation throws:

Code=Conflict, Message=Operation is not allowed on the cluster since it is currently being deleted

It looks like your cluster is being deleted, but it's not. That's the trap. The message is misleading—the cluster is stuck in a failed state, and AKS treats it as if a deletion is in progress. I had a client last month whose entire dev environment froze because of this. Their node count increase just wouldn't go through, and they were about to blow the cluster away and rebuild from scratch. Don't do that yet. There's a method to get out of this mess, and you can skip the worst of it if you follow these steps in order.

The 30-Second Fix: Check the Provisioning State

First, verify the cluster isn't actually deleting. Run this and look at the provisioningState:

az aks show -g <resource-group> -n <cluster-name> --query provisioningState -o tsv

If it returns Failed or Canceled, you're in the right place. If it says Deleting and has been that way for over an hour, that's a different beast—call support. But most times you'll see Failed. That tells you the last operation didn't complete, and the cluster is now locked.

Sometimes just waiting a few minutes clears it—the backend might finish cleaning up after the failed autoscaler update. I've seen clusters self-heal after ten minutes. So if you haven't waited, do that. But if you're reading this because it's been stuck for a while, move to the moderate fix.

The 5-Minute Fix: Force a Reconcile

The quickest way to break the deadlock is to trigger a reconcile operation that resets the provisioning state. You can do this by updating any innocuous property on the cluster. My go-to is the --enable-cluster-autoscaler flag, even if it's already enabled. Or you can toggle a label. The key is to send a PUT request that forces the Resource Manager to re-run a reconcile.

Here's the command that usually does the trick:

az aks update -g <resource-group> -n <cluster-name> --enable-cluster-autoscaler --update-ssh-key "$(cat ~/.ssh/id_rsa.pub)"

Yes, it's a hack, but it works. The update operation tells AKS to re-evaluate the cluster's state. After it completes, check the provisioning state again:

az aks show -g <resource-group> -n <cluster-name> --query provisioningState -o tsv

If it now shows Succeeded, try your node count increase again. If it still shows Failed or the conflict error persists, you need the advanced fix.

One thing to note: if the autoscaler update that failed was specifically on a node pool, you might need to target the node pool instead. Use this to trigger a reconcile on the pool:

az aks nodepool update -g <resource-group> --cluster-name <cluster-name> -n <nodepool-name> --enable-cluster-autoscaler --min-count 1 --max-count 5

Adjust the min/max to your values. The point is to send a valid update that forces the pool out of the failed state.

The 15+ Minute Fix: Manual Patch via ARM

If the update commands didn't clear it, you're dealing with a more stubborn lock. The next step is to bypass the CLI and patch the resource directly via Azure Resource Manager. This is what I do when the cluster is stuck in a weird state and the normal tools won't budge it.

First, get the current cluster JSON:

az aks show -g <resource-group> -n <cluster-name> > cluster.json

Open that file and look for the properties section. You'll likely see something like "provisioningState": "Failed". Change it to "Succeeded". Also check for any failureDetails or powerState that might be out of whack.

Now, send a PUT request with the corrected JSON. Using the Azure CLI with the az rest command is easiest:

az rest --method put --url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.ContainerService/managedClusters/<cluster-name>?api-version=2023-08-02" --body @cluster.json

This sends the full representation to ARM. It forces the resource provider to re-evaluate the cluster and clear the stuck deletion flag. Make sure you have the correct API version—check what your cluster uses by looking at the az aks show output or just use a recent one like above.

After the PUT completes, verify the state again. I've had to do this twice on a stubborn cluster—the first PUT didn't clear it because there was an internal operation still running. Wait five minutes and try again. Eventually, the provisioning state flips to Succeeded.

Then you can scale your node pool. But here's the thing—I always tell clients to watch the autoscaler settings after this. The root cause was a failed autoscaler update, and if you don't fix the underlying config, you'll be back here.

Why This Happens and How to Avoid It Next Time

The core issue is that AKS doesn't handle partial failures gracefully. When an autoscaler update fails—say, you set min-count higher than max-count or you hit a quota limit—the cluster's provisioning state gets stuck. The system thinks it's mid-deletion because the failed operation left a ghost.

To avoid this in the future, when you're changing autoscaler settings, always validate the values before applying. And if you hit an error, don't immediately retry. Wait a few minutes, check the state, then retry. I've also seen this happen when someone tries to scale a node pool while another operation is in progress—do one thing at a time.

If you're still stuck after all this, and you've waited over an hour, you might have to open a support ticket. That's rare, but it happens. In my experience, though, the manual ARM patch clears 90% of these cases. Keep that cluster.json file handy—you might need it again.

And if you do get it sorted, test your node count increase immediately to confirm it's fully unstuck. Better yet, take a snapshot of the cluster config so a similar failure doesn't leave you blind.