An Azure Kubernetes Service cluster has an internal load balancer that was created by the first LoadBalancer-type Service, and the other services now rely on that shared load balancer. I need to recreate or replace it, but I'm concerned about changing the private IP and about the fact that configuring a second load balancer may require a preview feature. What is the safest migration approach, and which Azure-managed resources should be left for AKS to reconcile?
3 Answers
Treat this as a blue-green migration if your cluster and AKS feature set support it: create the replacement path, move services or consumers over in stages, verify traffic with a controlled test, and remove the old load balancer only after the cutover is confirmed. If a second load balancer cannot be used, schedule a maintenance window and accept that the services may need to be reconciled together.
The biggest hidden risk is the private IP changing during recreation. Audit applications, firewall rules, allowlists, monitoring, and external integrations for anything that hardcodes the current address. Prefer service names or DNS wherever possible, and pin the internal IP with the appropriate Azure annotation if the address must remain unchanged.
Avoid manually rebuilding Azure backend pools, load-balancing rules, and health probes. Manage the replacement through Kubernetes Service manifests and let AKS reconcile the Azure resources. If the private IP must remain stable, use the supported Azure load balancer IPv4 annotation rather than relying on the deprecated `spec.loadBalancerIP` field. Since multiple load balancers may still be preview functionality, test the replacement path carefully and keep the existing setup available until rollback is no longer needed.
The difficulty is that all of the services currently resolve through the same internal load balancer. I can’t point them at a second one without using the preview multi-load-balancer capability.