Home / server / Questions / 1077270
Accepted
Petr Gladkikh
Asked: 2021-09-12 03:36:25 +0800 CST

Avoid pod environment variables' conflicts with Docker-style links

  • 772

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?

environment-variables kubernetes

1 Answers

  1. Best Answer

    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

    • 2