<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>

CC BY-SA 4.0
2020-08-06T08:02:59.143Z
2020-08-06T08:14:09.877Z
2020-08-06T08:14:09.877Z
weshouman
<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>

CC BY-SA 4.0
2020-08-06T03:29:37.223Z
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
CC BY-SA 4.0
2020-08-06T07:15:56.840Z
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
Nick Graham
<kubernetes><azure><azure-kubernetes-service>
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"
Nick Graham
# 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.


---

