Support for multiple (traefik) ingress controllers
Closed this issue · 4 comments
Hi!
This looks like a great project, potentially solving both nuisances that I currently have in order to migrate to Traefik with IngressRoutes.
One use case that seems missing is support for multiple ingress controllers. A common use case is to use two separate ingress controllers - one for internal-only services and other for public services - where each would be attached to a different service of LoadBalancer type (many cloud providers offer distinctive "public" or "internal-only" load balancer resources).
As I understand, currently we can only define either one specific traefik-controller service to extract the address for DNS record, or manually specify the IP addresses, but in both cases the resulting DNS records would point to the same addresses.
An implementation I imagine would be that the Switchboard operator would differentiate the IngressRoute resources by their associated ingressclass, and based on that, determine the correct Traefik service to extract the DNS target(s) from.
I guess a workaround with the current implementation could be to provision two Switchboard instances, and limit each to a different kubernetes.io/ingress.class value.
Yes, exactly! Sorry for the late reply. I've used this pattern myself. Since Switchboard is super lightweight, I don't think it's a huge pain to run more than one instance (unless, of course, you would have a couple dozen ingress classes...).
Let me know if you think it has significant benefits to integrate the functionality for different ingresses into a single Switchboard instance.
I can't right now think of any other benefits apart from consolidation, at least not if the sources have to be manually defined (either as IPs, or as traefik service resource). A substantial ease-of-use benefit would be if Switchboard would be able to determine dynamically the Traefik controller service object - either based on ingressclass annotation, or the default one if the annotation is absent. But that is probably much trickier to implement (I think a single Traefik deployment can even have multiple services attached for different entrypoints).
I don't think it is feasible to automatically derive the service that should be targeted. Even if the official Traefik deployment (e.g. via Helm) only created a singled service, nothing would prevent the user from creating another service that points to the Traefik instance. Knowing which service's addresses should actually be used to create DNS records is not possible without user input.
Closing this for now as using multiple Switchboard instances fixes your issue.