Join Log in
Score:1
avatar Server

Avoid pod environment variables' conflicts with Docker-style links

in flag
Petr Gladkikh

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?

98
0 + 0
Score:2
avatar Server
in flag
mdaniel

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

0 + 0
in flag
Petr Gladkikh
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.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.