1

We running or components in Kubernetes with Docker as container runtime. A problem with it is that pod environment is polluted with Docker-style link variables like

  • SERVICENAME_PORT_8181_TCP
  • SERVICENAME_PORT_HTTP
  • .....
  • SERVICENAME_PORT

for each visible service (the ones in same namespace). In this situation it is rather easy for automatically created variables to have conflicts with explicitly declared environment. This sometimes leads to hard-to-diagnose problems. I would also not want to rely on those automatic variables as would prefer containers not to depend on details of Kubernetes service configuration. Currently I am adding unique name prefixes to explicit variables to avoid such conflicts.

Is there a way to configure cluster to not add those automatic variables for each visible service? Alternatively, would using other runtimes like containerd solve this problem? I am surprised that there are no readily googleable solutions for this since configuration through environment variables is considered a good practice. How in general do I use environment without running into such naming conflicts? Or service names are considered a part of contract with containers and I should not change them freely?

Petr Gladkikh
  • 173
  • 1
  • 1
  • 9

1 Answers1

2

Is there a way to configure cluster to not add those automatic variables for each visible service?

Yes and no: not cluster-wide, AFAIK, but the enableServiceLinks: false field in spec: is designed to allow you to switch them off

Alternatively, would using other runtimes like containerd solve this problem?

No, those names were adding in the spirit of compatibility with docker, but are not related to docker at all -- they're injected by kubelet

How in general do I use environment without running into such naming conflicts? Or service names are considered a part of contract with containers and I should not change them freely?

Another option is rather than wholesale banning them, you also can just masking off the specific ones that bother your app; the ones that end in _HTTP are especially problematic with Spring Boot where there is a Service whose metadata: { name: is some super generic name like service or server

You can do that per Deployment:

env:
- name: SERVICENAME_PORT_HTTP
  # omitting the value: just sets it to the empty string in the container
# and the rest

or you can declare a ConfigMap containing the offensive ones and wholesale overwrite them with envFrom: (in order to not have to patch each affected Deployment

mdaniel
  • 2,338
  • 1
  • 8
  • 13
  • Thanks! I like `enableServiceLinks: false`. The last option, masking variables explicitly, does not seem to be practical as one should know already that they are getting in the way, which itself may not obvious (that is a problem I started with) and the names would change had anyone renamed services or create new ones. – Petr Gladkikh Sep 11 '21 at 13:29