An Azure internal load balancer was created when the first Kubernetes Service was deployed, and the other Services now use the same load balancer. I need to recreate or replace it with minimal disruption. What is the recommended AKS approach, especially if I cannot attach the existing Services to a second load balancer without using the preview multiple-load-balancer feature?
3 Answers
If a second load balancer is available and stable enough for your environment, a blue-green cutover is the cleanest option: create the replacement, move Services or consumers over gradually, verify traffic and health checks, then remove the old load balancer. However, with the multi-load-balancer feature still in preview, I would avoid depending on it for a production migration without confirming its current limitations.
Before recreating anything, audit every consumer for the existing private IP. Hardcoded IPs can fail silently when Azure assigns a new address; DNS names and Kubernetes Service names are safer. Pin the replacement to the current private IP with the appropriate annotation if the address is available and supported for your load-balancer configuration, then validate all backend health probes and connectivity before completing the cutover.
Let AKS manage the load balancer through the Service manifests rather than rebuilding backend pools, rules, and health probes manually. If the private IP must remain unchanged, configure it with the supported Azure load-balancer IPv4 annotation instead of relying on spec.loadBalancerIP, which is deprecated in current AKS guidance. Test the replacement path first, schedule the cutover during a maintenance window, and keep the old setup available until rollback is no longer needed.
The difficulty is that all of the Services currently attach to one internal load balancer. I cannot point them at a second one unless I use the preview multi-load-balancer capability.