☰

Vermeiden Sie Konflikte von Pod-Umgebungsvariablen mit Links im Docker-Stil

tag-icon • tag-icon kubernetes environment-variables
Vermeiden Sie Konflikte von Pod-Umgebungsvariablen mit Links im Docker-Stil

Wir führen unsere Komponenten in Kubernetes mit Docker als Container-Laufzeitumgebung aus. Ein Problem dabei ist, dass die Pod-Umgebung mit Linkvariablen im Docker-Stil verunreinigt ist, wie

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

für jeden sichtbaren Dienst (die im selben Namespace). In dieser Situation können automatisch erstellte Variablen recht leicht mit explizit deklarierten Umgebungen in Konflikt geraten. Dies führt manchmal zu schwer zu diagnostizierenden Problemen. Ich möchte mich auch nicht auf diese automatischen Variablen verlassen, da ich es vorziehen würde, wenn Container nicht von Details der Kubernetes-Dienstkonfiguration abhängen. Derzeit füge ich expliziten Variablen eindeutige Namenspräfixe hinzu, um solche Konflikte zu vermeiden.

Gibt es eine Möglichkeit, den Cluster so zu konfigurieren, dass diese automatischen Variablen nicht für jeden sichtbaren Dienst hinzugefügt werden? Könnte die Verwendung anderer Laufzeiten containerddieses Problem alternativ lösen? Ich bin überrascht, dass es hierfür keine leicht zu googelnden Lösungen gibt, da die Konfiguration über Umgebungsvariablen als bewährte Vorgehensweise gilt. Wie verwende ich im Allgemeinen eine Umgebung, ohne auf solche Namenskonflikte zu stoßen? Oder werden Dienstnamen als Teil des Vertrags mit Containern betrachtet und ich sollte sie nicht beliebig ändern?

Antwort1

Gibt es eine Möglichkeit, den Cluster so zu konfigurieren, dass diese automatischen Variablen nicht für jeden sichtbaren Dienst hinzugefügt werden?

Ja und nein: nicht clusterweit, soweit ich weiß, aber dieenableServiceLinks: falseFeld inspec:ist so konzipiert, dass Sie sie ausschalten können

Würde alternativ die Verwendung anderer Laufzeiten wie Containerd dieses Problem lösen?

Nein, diese Namen wurden im Sinne der Kompatibilität mit Docker hinzugefügt, haben aber überhaupt nichts mit Docker zu tun - sie sindinjiziert von kubelet

Wie verwende ich im Allgemeinen eine Umgebung, ohne auf solche Namenskonflikte zu stoßen? Oder werden Dienstnamen als Teil des Vertrags mit Containern betrachtet und ich sollte sie nicht beliebig ändern?

Eine andere Möglichkeit ist, sie nicht pauschal zu verbieten, sondern sie einfach abzudecken.Spezifischdiejenigen, die Ihre App stören; diejenigen, die auf enden, _HTTPsind besonders problematisch bei Spring Boot, wo es ein gibt, Servicedessen metadata: { name:ein supergenerischer Name ist wie serviceoderserver

Sie können dies pro Bereitstellung tun:

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

oder Sie können eine ConfigMap deklarieren, die die anstößigen enthält und diese dann komplett überschreiben envFrom:(um nicht jedes betroffene Deployment patchen zu müssen)

verwandte Informationen