<p>I want setup Traefik backend health check via Kubernetes annotation, but looks like <a href="https://docs.traefik.io/v1.7/configuration/backends/kubernetes/" rel="nofollow noreferrer">Kubernetes Ingress</a> does not support that functionality according to official documentation.</p>

<p>Is any particular reason why Traefik does not support that functionality for Kubernetes Ingress? I'm wondering because <a href="https://docs.traefik.io/v1.7/configuration/backends/mesos/" rel="nofollow noreferrer">Mesos</a> support health checks for a backend.</p>

<p>I know that in Kubernetes you can configure readiness/liveness probe for the pods, but I have leader/follower fashion service, so Traefik should route the traffic only to the leader.</p>

<p><strong>UPD:</strong> </p>

<ul>
<li>The only leader can accept the connection from Traefik; a follower will refuse the connection. </li>
<li>I have two readiness checks in my mind:

<ul>
<li>Service is up and running, and ready to be elected as a leader (kubernetes readiness probe)</li>
<li>Service is up and running and promoted as a leader (traefik health check)</li>
</ul></li>
</ul>

<p>Traefik relies on Kubernetes to provide an indication of the health of the underlying pods to ascertain whether they are ready to provide service. Kubernetes exposes two mechanisms in a pod to communicate information to the orchestration layer:</p>

<ul>
<li><strong>Liveness checks</strong> to provide an indication to Kubernetes when the process(es) running in the pod have transitioned to a broken state. A failing liveness check will cause Kubernetes to destroy the pod and recreate it.</li>
<li><strong>Readiness checks</strong> to determine when a pod is ready to provide service. A failing readiness check will cause the Endpoint Controller to remove the pod from the list of endpoints of any services it provides. However, it will remain running.</li>
</ul>

<p>In this instance, you would expose information to Traefik via a readiness check. Configure your pods with a readiness check which fails if they are in a state in which they should not receive any traffic. When the readiness state changes, Kubernetes will update the list of endpoints against any services which route traffic to the pod to add or remove the pod. Traefik will accordingly update its view of the world to add or remove the pod from the list of endpoints backing the Ingress.</p>

<p>There is no reason for this model to be incompatible with your master/follower architecture, provided each pod can ascertain whether it is the master or follower and provide an appropriate indication in its readiness check. However, without taking special care, there <strong>will</strong> be races between the master/follower state changing and Kubernetes updating its endpoints, as readiness probes are only made periodically. I recommend assuming this will be the case and building-in logic to reject requests received by non-master pods.</p>

<hr>

<p>As a future consideration to increase robustness, you might split the ingress layer of your service from the business logic implementing the master/follower system, allowing all instances to communicate with Traefik and enqueue work for consideration by whatever is the "master" node at this point.</p>
