Answers: <p>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.</p>
  <p>To my knowledge, that could be fixed with the rolling of <a href="https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.17.md" rel="nofollow noreferrer">Kubernetes 1.17</a> and the Loadbalancer Finalizer feature, <a href="https://github.com/kubernetes/kubernetes/pull/78262" rel="nofollow noreferrer">through this pull</a>.</p>
  <p>please update the question if that showed up with the new cluster version.</p>
  
Answers: CC BY-SA 4.0
Answers: 2020-08-06T08:02:59.143Z
Answers: 2020-08-06T08:14:09.877Z
Answers: 2020-08-06T08:14:09.877Z
Answers: weshouman
Body: <p>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 <a href="https://github.com/NickGraham101/dfc-devops/blob/58925ca008b4a80946840dec95d09b2d6d958327/ArmTemplates/aks.json" rel="nofollow noreferrer">ARM template</a> that uses version 2019-06-01 of the resource manager API.  As per the <a href="https://docs.microsoft.com/en-us/azure/aks/use-system-pools#delete-a-system-node-pool" rel="nofollow noreferrer">Microsoft documentation</a> I should be able to add a new System node pool and delete the original, default node pool.</p>
  
  <p>I can successfully deploy an additional node pool that has it's mode set to System using <a href="https://github.com/NickGraham101/dfc-devops/blob/e0a896afdbc6dbf1447986078930a4f391cac931/ArmTemplates/aks.json" rel="nofollow noreferrer">this template</a>, that template uses version 2020-03-01 of the resource manager API so that I can set the mode of the new pool.</p>
  
  <p>When I attempt to delete the original, default node pool using <code>az aks nodepool delete -g gandt-testshared-rg --cluster-name gandt-testshared-aks -n agentpool</code> I get an error saying <code>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.</code>.  </p>
  
  <p>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?</p>
  
  <p><strong>Update</strong></p>
  
  <p>I've deleted the cluster and redeployed using the original ARM template then added the 2nd node pool using az cli command <code>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</code> and got the same result when deleting the default node pool</p>
  
Comments: CC BY-SA 4.0
Comments: 2020-08-06T03:29:37.223Z
Comments: did you try to create a loadbalancer service before trying to delete the bakend nodepool? and what version of k8s cluster do you use?
Comments: weshouman
Comments: CC BY-SA 4.0
Comments: 2020-08-06T07:15:56.840Z
Comments: 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
Comments: Nick Graham
Tags: <kubernetes><azure><azure-kubernetes-service>
Title: How do I delete a default AKS node pool when I get an error saying it's the "backend address pool of the basic load balancer"
UserDisplayName: Nick Graham
ThreadText: # How do I delete a default AKS node pool when I get an error saying it's the "backend address pool of the basic load balancer"
  
  (Asked by: username_0 on 2020-06-04)
  
  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](https://github.com/NickGraham101/dfc-devops/blob/58925ca008b4a80946840dec95d09b2d6d958327/ArmTemplates/aks.json) that uses version 2019-06-01 of the resource manager API. As per the [Microsoft documentation](https://docs.microsoft.com/en-us/azure/aks/use-system-pools#delete-a-system-node-pool) 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](https://github.com/NickGraham101/dfc-devops/blob/e0a896afdbc6dbf1447986078930a4f391cac931/ArmTemplates/aks.json), 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?
  
  **Update**
  
  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
  
  **Tags:** kubernetes, azure, azure-kubernetes-service
  
  > **Comments:**
  > **username_1**: did you try to create a loadbalancer service before trying to delete the bakend nodepool? and what version of k8s cluster do you use?  
  > **username_0**: 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  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2020-08-06. Score: 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](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.17.md) and the Loadbalancer Finalizer feature, [through this pull](https://github.com/kubernetes/kubernetes/pull/78262).
  
  please update the question if that showed up with the new cluster version.
  
  
  ---
  
  