Currently external-mdns is working farily well in my home lab for which I used metallb as a LoadBalancer so it's closer to the Cloud Environments I actually work with.
A limitation struck me early on, Istio Gateways use a Service Type (I know they are transitioning to Gateway resource but this is the model I've been used to). If I setup the Service for the Gateway as LoadBalancer external-mdns will advertise that on the address that the service binds to, however, it won't have any direct means of using any Istio Gateway definitions that are bound to that particular Ingress Gateway deployment - We can track host names from Gateway Resources to an actual Ingress Gateway mapping but this only identifies the Gateway Deployment/Pods and not the service feeding them so correlating the service IP that way is not practical unless we annotate the Deployment or something similar..
A second limitation comes when using something like nginx-ingress for TCP based services. They are actually not controlled by Ingress resources at all but need to come from a --tcp-services-configmap which has mappings for incoming ports to destination namespace/service:port which look like this..
8080: "default/proxy:8080"
Since these naturally have no Ingress resource and the service if any is named after the ingress Gateway and not the target this also produces a predicament.
One can workaround the nginx-ingres issue by creating a dummy ingress object just for external-mdns to find.
One may be able to do a similar thing with Istio, however, with a pure Istio install one probably would not even have a default Ingress class because Istio does not use them.
I would rather not consume a lot of addresses on metallb using Service directly so I was thinking it might be useful to be able to decorate ClusterIP services with a hostname and IP address if one knows that they will be serviced either by a TCP config on an ingress that does not use an Ingress object or if they are to be serviced by something like Istio.
I'm happy to create a pull request for this if you like the idea and take on any specification that you may have over naming etc. to keep the feel of your project.
Currently external-mdns is working farily well in my home lab for which I used metallb as a LoadBalancer so it's closer to the Cloud Environments I actually work with.
A limitation struck me early on, Istio Gateways use a Service Type (I know they are transitioning to Gateway resource but this is the model I've been used to). If I setup the Service for the Gateway as LoadBalancer external-mdns will advertise that on the address that the service binds to, however, it won't have any direct means of using any Istio Gateway definitions that are bound to that particular Ingress Gateway deployment - We can track host names from Gateway Resources to an actual Ingress Gateway mapping but this only identifies the Gateway Deployment/Pods and not the service feeding them so correlating the service IP that way is not practical unless we annotate the Deployment or something similar..
A second limitation comes when using something like nginx-ingress for TCP based services. They are actually not controlled by Ingress resources at all but need to come from a --tcp-services-configmap which has mappings for incoming ports to destination namespace/service:port which look like this..
Since these naturally have no Ingress resource and the service if any is named after the ingress Gateway and not the target this also produces a predicament.
One can workaround the nginx-ingres issue by creating a dummy ingress object just for external-mdns to find.
One may be able to do a similar thing with Istio, however, with a pure Istio install one probably would not even have a default Ingress class because Istio does not use them.
I would rather not consume a lot of addresses on metallb using Service directly so I was thinking it might be useful to be able to decorate ClusterIP services with a hostname and IP address if one knows that they will be serviced either by a TCP config on an ingress that does not use an Ingress object or if they are to be serviced by something like Istio.
I'm happy to create a pull request for this if you like the idea and take on any specification that you may have over naming etc. to keep the feel of your project.