Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Service discovery via environment variables should be available for all namespaces #87366

Closed
dudicoco opened this issue Jan 19, 2020 · 9 comments
Closed

Service discovery via environment variables should be available for all namespaces #87366

dudicoco opened this issue Jan 19, 2020 · 9 comments
Labels
kind/feature Categorizes issue or PR as related to a new feature. priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done. sig/network Categorizes an issue or PR as relevant to SIG Network. triage/unresolved Indicates an issue that can not or will not be resolved.

Comments

@dudicoco
Copy link

What would you like to be added:
Environment variables for services in all namespaces within the cluster should be available within a container.
This can be achieved by adding the namespace to the environment variables:
MYAPP_KUBE-SYSTEM_SERVICE_PORT_HTTP=8080

Why is this needed:
Currently service discovery for ports using environment variables is available only for the services within the same namespace.
Using DNS service discovery for ports with SRV records requires either modifying the application to perform DNS SRV lookup or having different process such as an init container or a dedicated controller to perform the lookup which isn't ideal.
@dudicoco dudicoco added the kind/feature Categorizes issue or PR as related to a new feature. label Jan 19, 2020
@k8s-ci-robot k8s-ci-robot added the needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. label Jan 19, 2020
@dudicoco
Copy link
Author

/sig network

@k8s-ci-robot k8s-ci-robot added sig/network Categorizes an issue or PR as relevant to SIG Network. and removed needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. labels Jan 19, 2020
@athenabot
Copy link

/triage unresolved

Comment /remove-triage unresolved when the issue is assessed and confirmed.

🤖 I am a bot run by vllry. 👩‍🔬

@k8s-ci-robot k8s-ci-robot added the triage/unresolved Indicates an issue that can not or will not be resolved. label Jan 19, 2020
@liggitt
Copy link
Member

liggitt commented Jan 19, 2020

There is a lot of overlap/duplication with the discussion in #1768

Injecting all service info from all namespaces is not scalable. Use of DNS largely eliminates the need to know specific IPs of services in other namespaces.

/priority awaiting-more-evidence

@k8s-ci-robot k8s-ci-robot added the priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done. label Jan 19, 2020
@dudicoco
Copy link
Author

@liggitt there is indeed an overlap in the discussion.
DNS for IP resolution does not solve this issue, as I am referring specifically to ports discovery, which can not be used without modifying the application

@danwinship
Copy link
Contributor

Environment variables for services are already problematic (in that a pod can only have environment variables for the services that existed before it was created). And extending them to cover all namespaces would be a performance problem in large clusters. There is a proposal to deprecate service environment variables altogether.

DNS for IP resolution does not solve this issue, as I am referring specifically to ports discovery, which can not be used without modifying the application

CoreDNS should serve SRV records which contain the port; if your app doesn't natively support SRV records you could just wrap it in a shell script that manually resolves the record and then passes the port to the app.

/close

@k8s-ci-robot
Copy link
Contributor

@danwinship: Closing this issue.

In response to this:

Environment variables for services are already problematic (in that a pod can only have environment variables for the services that existed before it was created). And extending them to cover all namespaces would be a performance problem in large clusters. There is a proposal to deprecate service environment variables altogether.

DNS for IP resolution does not solve this issue, as I am referring specifically to ports discovery, which can not be used without modifying the application

CoreDNS should serve SRV records which contain the port; if your app doesn't natively support SRV records you could just wrap it in a shell script that manually resolves the record and then passes the port to the app.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@dudicoco
Copy link
Author

dudicoco commented Feb 9, 2020

@danwinship what is the suggested way to perform port DNS lookup when there is no appropriate tool (dig/host/nslookup) available in the docker image?

@danwinship
Copy link
Contributor

"add an appropriate tool to the image"?

Alternatively, use something like the operator pattern, where both the client and server Pod resources would be created by some other pod, which can then fill in an environment variable in the client Pod's spec pointing to the appropriate port in the server pod.

@dudicoco
Copy link
Author

@danwinship modifying an image is not really viable for third party applications.

As I wrote in the first comment, the alternative would indeed be an init container or a dedicated controller to perform the lookup but it seems like an overkill.

@thiagoelg thiagoelg mentioned this issue Oct 10, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
kind/feature Categorizes issue or PR as related to a new feature. priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done. sig/network Categorizes an issue or PR as relevant to SIG Network. triage/unresolved Indicates an issue that can not or will not be resolved.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@danwinship @liggitt @k8s-ci-robot @athenabot @dudicoco