/sig node

I like the idea of making those environment variables optional. I think it could be managed by a flag provided to kubelet (--enable-service-env?).

I like the idea about exposing information about services in downward API as well, but that sounds like a very complicated feature, which would need to involve teaching downward API to select external resources by label selectors. IMO it definitely needs a separate issue and feature request in the community repo.

I would imaging this being nicer to have at the pod-definition, or maybe as an attribute? I can see this being useful some times, but I rather want it default off.

I don't know the inner details so say either way, nor have I ever used those variables to say if really when they are useful. Do people even use kubernetes without a dns controller of some sort (in other words, is this needed at all)?

I would imaging this being nicer to have at the pod-definition, or maybe as an attribute?

An attribute seems to be better, at least for the first implementation - it will not require any API changes.

/sig network

@xeor what is the use case for disabling these environment variables, security ?

@krmayankk I wouldn't say that there is any specific usecase. They're just not needed. I'd say that currently Kubernetes users should access services by using DNS and there is no need for keeping IP addresses and ports in environment variables.

The pattern of having those variables is an old behavior of Docker (--link option, which is deprecated FWIK) and docker-compose.

Service env variables shouldn't bring any security issues though, they're limited by the namespace. So I think it's fine to leave them optionally for legacy app users who are used to accessing services by variables, not by DNS.

@krmayankk there is not really a specific usecase as @mrostecki said.. It is more or less the reason that they are not needed. Even tho not really security related, it also exposed a lot of info about whats in it's namespace.
Felt like it was bloating up my pods env as well. everything from 0 to 6-8 entries per other pod in the namespace.

IMO if there is no real use case we shouldnt yet remove these environment variables. The primary reason being they are an excellent way for primitive service discovery for pods untill we have some other better way which is available in the default configuration . DNS is not available to kubernetes users by default and i would think by default we want to make it easy for our customers to use kubernetes. @thockin might have some thoughts here .

@krmayankk #18219 is one reason to allow them to be disabled.

I came here after hours of debugging why a node app using Swagger library was generating his own URI as mydomain.tld:tcp://10.97.1.1:8082
These environment variables can clash with variables of own program or libraries, mainly SERVICENAME_PORT kind, generating unexpected problems and wasting operator time.
Being a broke (because ordering) discovery mechanism, my opinion is that this feature should be optional. Being able to disable it in the Service kind will resolve the situation still providing backwards compatibility.

@eroldan, I am having a similar issue. My app uses REDIS_PORT to connect to a redis database. Since the variable set by docker uses the tcp://IP:PORT format, i get the following error:

"unable to connect to tcp://redis:tcp://10.0.151.188:6379"

I believe having an option to disable the env variables would be a good solution to this problem.

We have use case, some apps (libs) try to pass all available environment variables further downstream via arguments, and when we get to a certain number of containers in the cluster, it'd start to crash with E2BIG and we're unable to start any new container. So ability to disable it will go a long way. Thank you.

@alexindigo I had a similar issue with fcgi/php-fom and the workaround has been to unset all env variables before running it :-/

for i in $(set | grep "_SERVICE_\|_PORT" | cut -f1 -d=); do unset $i; done

Thanks @dynek, looks like this what I'd have to resort to. Hope there won't be naming conflicts. :)

I would like to +1 this, and validate the use case that they can cause code that runs perfectly fine locally to fail on k8s, due to env variables being quite commonly named they end up clashing with many scripts.

We need to be able to either turn them off, or have them prefixed with K8S_

Same issue as @alkin. Just spent quite a while working out why I was getting an error for my redis.port property in my Java containers when I wasn't setting it. I guess I'll rename my redis service to something other than "redis". 😞

same issue, when using zeppelin for docker, because zeppelin search for server port from environment variable named "port", which is integer value from ZeppelinConfiguration.java, but from k8s, it's value is tcp://10.43.210.57:8080, this will cause NumberFormatException

oof, finally found this after hours of debugging, i am running a docker registry and the auth service is called "registry-auth" therefore creates a bunch of env vars that the container things are config values, super annoying to debug and since the advent of kube-dns it seems a bit superfluous

I'm confused that this is closed. I don't expect environment variables in my container that I didn't explicitly set. Has this feature request been implemented in k8s now? Thanks.

@vincentjorgensen totally agree with you.

I have to use various namespaces to reduce impact of this feature.

The issue was fixed in new versions of kube. See #68754

The issue was fixed in new versions of kube. See #68754

Awesome @huggsboson. It doesn't seem to be in v1.12.0. Is is staged for a future release?

It looks like it was merged 14 days ago, so I'd expect it to be in the next release unless someone back ports it.

@bradhoekstra Does it make sense / is it possible to back port this feature to previous releases given the number of people wanting the new behavior?

@huggsboson My understanding is that new features are limited to minor releases; patch releases should be bug fix only. Since this didn't make it into 1.12 it will wait until 1.13.

@bradhoekstra Based on the comments, one could argue this is a "bug fix" (for a bug that has existed since the beginning of time).

I'm curious if it would be easy to backport or if code changes landing in the 1.13 timeframe made it easier to accomplish.

AFAIK, it would be easy to backport.

@bradhoekstra Is there a chance this could be reported back as a bug and the change backported as a bug fix to previous releases?
It is actually easy to backport but other than a mere PR what steps should be made?

@nrvnrvn IMO, this change does not meet the criteria for being cherry-picked into a patch release as they are laid out: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md

For reference, the process for requesting a cherry pick is documented here: https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md

What's really frustrating is the only service vars that seem to be documented are $service_SERVICE_HOST and $service_SERVICE_PORT, when in fact there are lots of others that look like $service_PORT*. Can someone explain these or point to some docs that I was unable to find?

@twbecker https://kubernetes.io/docs/concepts/services-networking/service/#environment-variables

@bradhoekstra thanks! Not sure how I missed this. Will definitely be nice when we can disable exposing those vars.