Load balancer (ingress + health checks)
A load balancer gives the customer one stable address -- a public IP and hostname that never changes -- and quietly spreads the incoming traffic across a pool of their backend VMs. Visitors hit the front door; the balancer decides which room they end up in. The customer can add or remove backends behind it without anyone outside ever noticing.
The balancer keeps checking that each backend is still alive. The moment one stops answering, it stops sending traffic there and quietly leans on the survivors -- so one crashed VM is a shrug instead of an outage. That's why load balancers are the front of almost every web app and the ingress for Kubernetes clusters.
Detailed explanation
A LoadBalancer hands the tenant a stable VIP/hostname and fronts a pool of backend VMs (the customer's own, or a k8s node set). Per-backend health checks gate traffic: an unhealthy backend is pulled from rotation and restored when it recovers. The LB is the ingress surface -- it consumes egress/ingress capacity and is the single point every external request passes through, so its reachability is load-bearing for the whole tenant.
The two tenant-visible failures are IP flapping (the stable address isn't stable) and pool exhaustion (every backend unhealthy at once -- the LB has nowhere to send traffic and returns errors). Spread backends across hosts with anti-affinity so a single host loss can't empty the pool; a k8s ingress LB's backend count tracks the worker node count.