I'm attempting to replace a node pool in Azure Kubernetes Service with a new pool (that has a larger VM size). The current pool was deployed using an ARM template that uses version 2019-06-01 of the resource manager API. As per the Microsoft documentation I should be able to add a new System node pool and delete the original, default node pool.

I can successfully deploy an additional node pool that has it's mode set to System using this template, that template uses version 2020-03-01 of the resource manager API so that I can set the mode of the new pool.

When I attempt to delete the original, default node pool using az aks nodepool delete -g gandt-testshared-rg --cluster-name gandt-testshared-aks -n agentpool I get an error saying Operation failed with status: 'Bad Request'. Details: The agent pool cannot be deleted because it is used as the backend address pool of the basic load balancer..

Why am I getting this error and what can I do to get the backend address pool of the basic load balancer to use the new node pool?


I've deleted the cluster and redeployed using the original ARM template then added the 2nd node pool using az cli command az aks nodepool add -g gandt-testshared-rg --cluster-name gandt-testshared-aks --name poolb2ms01 --node-count 1 --node-vm-size Standard_B2ms --mode System and got the same result when deleting the default node pool

  • did you try to create a loadbalancer service before trying to delete the bakend nodepool? and what version of k8s cluster do you use?
    – weshouman
    Commented Aug 6, 2020 at 3:29
  • The cluster has a couple of loadbalancer services. The Kubernetes version at the time was 1.15.7. I've since had to just delete my cluster, accept the downtime and redeploy a fresh cluster with the latest version of the resource manager API and the larger VM size Commented Aug 6, 2020 at 7:15

1 Answer 1


If my assumption is correct that's related to having a loadbalancer that wasn't correctly deleted. Which could be resulted by redeploying a service (of type: load balancer) in a short time before Azure cleans up the previously associated loadbalancer resource.

To my knowledge, that could be fixed with the rolling of Kubernetes 1.17 and the Loadbalancer Finalizer feature, through this pull.

please update the question if that showed up with the new cluster version.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.