blake
commented
8 months ago @iamasmith I believe I understand the situation the problem you're describing. Does #22 directly address this, or is additional work needed?
Open iamasmith opened 8 months ago
blake
commented
8 months ago @iamasmith I believe I understand the situation the problem you're describing. Does #22 directly address this, or is additional work needed?
iamasmith
commented
8 months ago wrt PTR records? no, as I mentioned I didn’t tackle that one directly so it’s no worse than before but could probably be improved upon.
The change would require something that assembles all records prior to advertising them and picking one particular one to advertise rather than as a whole, this would make a concrete assertion for the name to be associated with the address record that possibly may change behaviour but I doubt that many would feel the impact of it.
It could be done earily by assembling candidate PTR names into a list, sorting and picking the first and possibly adding another annotation for direct control.
As it stands, as I said, the product should be no better or worse in this respect for this change at this point.
-Andy
On 10 Mar 2024, at 20:57, Blake Covarrubias @.***> wrote:
@iamasmith https://github.com/iamasmith I believe I understand the situation the problem you're describing. Does #22 https://github.com/blake/external-mdns/pull/22 directly address this, or is additional work needed?
— Reply to this email directly, view it on GitHub https://github.com/blake/external-mdns/issues/21#issuecomment-1987359612, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKFBLWUPHDC2LHCLH6POWDYXTJL3AVCNFSM6AAAAABEJFP3YOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBXGM2TSNRRGI. You are receiving this because you were mentioned.
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.