-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for ExternalName's used for cross-namespace Services #262
Comments
@r4j4h ExternalName services is a valid use case that we don't currently support. I think a simple implementation would involve changing getEndpointsForIngressBackend method: if a service has an external name, instead of trying to fetch its endpoints, which it doesn't have, add an endpoint manually in the form of DNS-name:port. In the end, for such a service, Configurator will generate an upstream with one server: upstream some-service {
server DNS-name:port;
} Caveats:
A different approach would involve resolving a DNS name inside a location (note that the resolver must be defined as well -- http://nginx.org/en/docs/http/ngx_http_core_module.html?#resolver): location / {
set $backend_servers backends.example.com;
proxy_pass http://$backend_servers:8080;
} However, it has a drawback that you cannot configure things like http://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive. More info about DNS in NGINX -- https://www.nginx.com/blog/dns-service-discovery-nginx-plus/ Mergeable Ingress Types allows splitting an Ingress resource into multiple Ingress resources across a single or multiple namespaces. |
That is a beautiful response @pleshakov! I appreciate the summary of caveats with those approaches. Mergeable Ingress Types sounds like the best way forward for our use case. Regarding the status of this Issue, I am not sure if I should close it with this comment or not. I want to leave the choice of keeping it open to you as it sounds like one one hand we could establish support for ExternalName Services even with the drawbacks and that may be desirable, but on the other hand because Mergeable Ingress Types offer the benefits without the drawbacks, and even obviates the need for the ExternalName Service itself, pointing everyone to them instead may be cleaner and result in a smoother, more full-featured experience for everyone. |
thanks. I think it is better to keep the issue open. |
Does your ingress resource and svc in different namespace? |
If I need to point some ingress to an AWS S3 bucket how do I do that? I have tried pointing it to an externalname service like the author of this issue did, but that led me to this issue. Is there any known, easy workaround? |
@calicoderco external services are not supported in this Ingress Controller. However, we'll be adding this features early next year. |
I've overcome the issue with this workaround:
It works as I expected, however will be fine to have a more native way to implement configurations like this. |
@sombralibre Can you elaborate on your answer? I am specifically trying to set up Ingress to route to services in separate namespaces. I have everything (pod+service) working in a namespace and I create main ingress + service of type ExternalName, however ingress complains that: I really trying to wrap my head around but feels as if I keep beating the dead horse. I have multiple applications that needs similar resources, for ex. Laravel and Magento uses redis. Namespaces solves it perfectly and keeps it organized. But then I wanna use single and simple Ingress to serve them over magento.example.com and laravel.example.com etc. |
Hi there,
Summary
ExternalName services do not get endpoints created, and as far as I can tell the Ingress controller depends exclusively on the Endpoints created from Services, so ExternalName services cannot currently be used to reach a Service across namespaces using the Nginx Ingress Controller.
Background
Today we tried including a surrogate Service in the local namespace referencing a service in another namespace via an ExternalName pointed to its in-cluster DNS:
When resolving that service within a pod, the appropriate Pod IP from the other namespace is returned.
When nginx comes to handle the service, however, it logs "no endpoints found" for the service and
NewUpstreamWithDefaultServer()
marks the upstream as127.0.0.1:8181
. When accessing the path through nginx, an error is given.This is to be expected, as externalName Services do not get endpoints created, but the Ingress controller depends exclusively on the Endpoints created from Services. This latter part was surprising to me.
Proposal
This issue is to bring up this point and see what thoughts are around the idea of having the nginx Ingress Controller behave differently when no Endpoints can be found to support this case.
My thought is that there are two locations we could try to resolve the name using DNS before falling back to the current behavior:
A similar discussion on the contrib nginx Ingress controller has led me to think modifying the proxy_pass directive directly is more correct by convention for pointing to DNS. If so, then the changes needed would affect here (and in the respective Nginx Plus-variant template)
https://github.com/nginxinc/kubernetes-ingress/blob/8aca003ee5f94b1d874cd786b8be5d6d87136fd0/nginx-controller/nginx/templates/nginx.ingress.tmpl#L92-L96
For reference on ExternalName Services, see kubernetes/website#5822.
P.S. While researching this I learned about the newly added Mergeable Ingress Types support which may allow working around this issue without using ExternalName Services. I will update this with my findings after trying it.
The text was updated successfully, but these errors were encountered: