This is more of a proof of concept implementation (no tests included or documentation is currently included) than anything and I'd mostly like to get some feedback on how we can proceed with this, if at all.

1. This cannot replicate 1:1 functionality of failover on file provider without, I believe, making major and possibly breaking changes to how services are currently created in Traefik for Kubernetes provider. Without NativeLB enabled, failover will not work at all when endpoints are not available for the main service (for example in case main service pods cannot be created). It does work generally ok with NativeLB enabled, although still with some limitations compared to the file provider (e.g. won't work if wrong port is specified for main service).
2. Implementation depends on healthcheck being available for use on services. Healtcheck was implemented here Support HealthCheck for ExternalName services #10467 although for ExternalName services only. This PR enables it for all other service types, although perhaps this should be another PR instead? Are there any considerations when enabling it?

If I could get some input on this or any other related feedback before I would be grateful.

Hello @jjsiv and thanks for your contribution,

We have reviewed the pull request and would like to share our concerns. Kubernetes (k8s) already includes a built-in health-check mechanism that manages service endpoints by adding or removing them based on pod readiness. Given this functionality, we believe extending the health-check mechanism to all service types is unnecessary. The health-check feature was originally introduced specifically for ExternalName services, as Kubernetes does not provide a native health-check mechanism for them.

We would like to leverage Kubernetes health-check information to design the Failover service. At first glance, we have identified two potential approaches.

1. Modify the dynamic configuration process: Incorporate health-check information into the configuration, allowing Traefik to automatically remove services that are down.
2. Enhance the Kubernetes provider: Add intelligence to the provider to construct the service tree based on Kubernetes health-check status.

Personally, I would vote for the first option, as it ensures that the health-check intelligence is not duplicated in the Kubernetes CRD provider.

Does it make sense? wdyt?

Thanks for your feedback @kevinpollet. I agree, to rely on built-in Kubernetes mechanisms would be ideal and the first approach sounds good. I will see what I can come up with.

Hello @jjsiv,

Have you made any progress on the subject?

If you want we can move forward on it and push some commits to your pull request or open a new one.