TrafficSplit zero-healthy-endpoint ambiguity in Traefik Mesh controller

Answer to the core question

In Traefik Mesh, if a TrafficSplit has one backend with zero healthy endpoints, the remaining healthy backend receives 100 % of the traffic. The controller removes the unhealthy backend from the internal load‑balancer, so the weighted distribution collapses to the single healthy target.

How the mesh controller emits health‑check configuration

The controller translates each TrafficSplit into a Traefik dynamic configuration that looks roughly like this:

services:
  my-service:
    loadBalancer:
      servers:
        - url: "http://backend-a:80"
          healthCheck:
            path: "/healthz"
            interval: 10s
            timeout: 5s
        - url: "http://backend-b:80"
          healthCheck:
            path: "/healthz"
            interval: 10s
            timeout: 5s

Each backend receives a healthCheck block that Traefik uses to mark the server as unhealthy when the check fails. When all servers for a given backend are unhealthy, Traefik drops the entire backend from the pool.

Version context that defines the current semantics

These semantics are baked into the following releases:

• Traefik Mesh 0.9.x and newer (the 0.9 series introduced stable health‑check injection for split targets).
• Traefik 2.8.x and newer (the load‑balancer logic that discards fully unhealthy backends was stabilized in 2.8).

Earlier combinations (e.g., Mesh 0.8.x with Traefik 2.6.x) may still forward a fraction of requests to an unhealthy backend or return errors, because the health‑check logic was not fully integrated then.

How to verify the behavior in your cluster

1. Check the dynamic config:

   Retrieve the generated Traefik configuration and confirm that each split target has a healthCheck block.

   kubectl -n traefik-mesh get configmap traefik-dynamic-config -o yaml | grep -A3 "healthCheck"
   

2. Observe request distribution:

   Scale one backend to zero replicas and send traffic to the split service. Use Traefik metrics or application logs to confirm that all requests hit the remaining backend.

   # Scale backend A to 0 replicas
   kubectl scale deployment backend-a --replicas=0
   # Send traffic and watch logs
   kubectl logs -n traefik-mesh -l app=traefik -c traefik | grep "backend-a"
   

3. Check controller logs:

   Traefik Mesh emits warnings when a backend becomes fully unhealthy. Look for entries such as “backend-b removed from TrafficSplit my-service”.

   kubectl logs -n traefik-mesh deployment/traefik-mesh-controller | grep "removed from TrafficSplit"
   

Missing diagnostic detail

If your cluster uses a version older than Mesh 0.9.x or Traefik 2.8.x, the redistribution rule might differ. Please confirm the exact traefik-mesh-controller and traefik image tags you are running, and we can adjust the guidance accordingly.