kubernetes: ExternalName service doesn't generate Environment Variables for service discovery
Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see http://kubernetes.io/docs/troubleshooting/.): No
What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): externalname service environment
Is this a BUG REPORT or FEATURE REQUEST? (choose one): FEATURE REQUEST
(though it seems like a bug to me)
The externalName of ExternalName services should appear under the SERVICENAME_SERVICE_HOST environment variable in created containers.
Kubernetes version (use kubectl version):
Client Version: version.Info{Major:“1”, Minor:“9”, GitVersion:“v1.9.3”, GitCommit:“d2835416544f298c919e2ead3be3d0864b52323b”, GitTreeState:“clean”, BuildDate:“2018-02-09T21:51:06Z”, GoVersion:“go1.9.4”, Compiler:“gc”, Platform:“darwin/amd64”} Server Version: version.Info{Major:“1”, Minor:“8”, GitVersion:“v1.8.5”, GitCommit:“cce11c6a185279d037023e02ac5249e14daa22bf”, GitTreeState:“clean”, BuildDate:“2017-12-07T16:05:18Z”, GoVersion:“go1.8.3”, Compiler:“gc”, Platform:“linux/amd64”}
Environment: (presuming irrelevant)
What happened:
root@debug-f95f68697-2cx2d:/# printenv HOSTNAME=debug-f95f68697-2cx2d KUBERNETES_PORT_443_TCP_PROTO=tcp KUBERNETES_PORT_443_TCP_ADDR=10.0.0.1 KUBERNETES_PORT=tcp://10.0.0.1:443 PWD=/ HOME=/root KUBERNETES_SERVICE_PORT_HTTPS=443 KUBERNETES_PORT_443_TCP_PORT=443 KUBERNETES_PORT_443_TCP=tcp://10.0.0.1:443 TERM=xterm SHLVL=1 KUBERNETES_SERVICE_PORT=443 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin KUBERNETES_SERVICE_HOST=10.0.0.1 _=/usr/bin/printenv
What you expected to happen:
Above should have additionally contained at least:
AUTHSERVICE_SERVICE_HOST=example.com
How to reproduce it (as minimally and precisely as possible):
kubectl create service externalname authservice --external-name example.com kubectl run -it debug --image debian:stretch
Anything else do we need to know:
Previously reported as #39356
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 4
- Comments: 37 (17 by maintainers)
@aojea I haven’t tried Pod Presets for my use case. I’ll give them a spin and see how it goes.
As I see it, the point of the env-vars interface is to get data into simple programs without having to put complicated logic inside the image. As the current implicit API appears to be problematic, perhaps an explicit API, for example adding a
serviceReffield toEnvFromSource, would suit.The DNS record is not useful when it is a TLS service because the service will almost never have a matching SAN in its certificate. The code in the pod needs to dereference and use the underlying external domain
The documentation at https://kubernetes.io/docs/concepts/services-networking/service/ clearly states that the kubelet adds these environment variables “for each active Service”. If ExternalName services are supposed to be excluded from this, then the documentation needs to be updated to specifically state this.
In general, I’d reallllllly rather get rid of the env-var service exposure logic. It’s kind of a mess and a scalability problem.
ExternalName does produce a DNS record, which is more powerful than env var anyway.
If there’s a good reason that doesn’t work – reopen?