- One domain → the same service on several servers
- Round-robin, HTTPS-aware health checks, optional sticky sessions
- Members only expose the domain on :8099 to the balancer's IP
- Sticky sessions reach the exact container, not just the server
- Balancer tab probes every member and shows how real traffic was spread
- Any number of domains and redirects per balancer, Logs tab with Traefik health events
How it is wired
A load balancer (service kind lb) picks its members: the same service deployed on any of your servers. The balancer’s host gets a Host(domain) router on :443 pointing at each member server’s :8099, with health checks (the hostname set to the balanced domain) and an optional sticky cookie. Members expose the balanced domain only on the proxy’s :8099 entrypoint, protected by an IP allow-list that contains just the balancer, so the origin servers are never reachable directly.
shop.acme.com ─▶ lb (server A) ─┬─▶ server A :8099 ─▶ web
├─▶ server B :8099 ─▶ web
└─▶ server C :8099 ─▶ web (private)Health and traffic
The Balancer tab probes every member from the balancer host with the same request the health check sends and shows the answer, its latency, stopped containers, and how the last quarter hour of real traffic was spread over the members, read from the proxy’s access log. A member that stops answering leaves the rotation until it recovers.
Sticky sessions that actually stick
A server running several containers of the balanced service used to alternate between them on every request, because the balancer can only pin the server. The second hop now carries the balancer’s own stickiness (cookie dx_lbc) and health check, so a visitor stays on one container and a container that stops answering leaves the rotation.
Private members
Mark member servers as private and they get no DNS record, no free subdomain and no public name. Their IPs never appear in DNS or certificate-transparency logs; the only public entry point is the balancer.