înregistrare Logare
Puncte:1
avatar Server

Evitați conflictele variabilelor de mediu ale podului cu linkurile în stil Docker

drapel in
Petr Gladkikh

Rulăm sau componentele în Kubernetes cu Docker ca timp de rulare a containerului. O problemă cu acesta este că mediul pod este poluat cu variabile de legătură în stil Docker, cum ar fi

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

pentru fiecare serviciu vizibil (cele din același spațiu de nume). În această situație, este destul de ușor ca variabilele create automat să aibă conflicte cu mediul declarat explicit. Acest lucru duce uneori la probleme greu de diagnosticat. De asemenea, nu aș dori să mă bazez pe acele variabile automate, deoarece aș prefera ca containerele să nu depindă de detaliile configurației serviciului Kubernetes. În prezent, adaug prefixe de nume unice la variabilele explicite pentru a evita astfel de conflicte.

Există o modalitate de a configura clusterul pentru a nu adăuga acele variabile automate pentru fiecare serviciu vizibil? Alternativ, ar folosi alte runtime, cum ar fi containerd rezolva problema asta? Sunt surprins că nu există soluții ușor de căutat pe google pentru aceasta, deoarece configurarea prin variabile de mediu este considerată o practică bună. Cum, în general, folosesc mediul fără a intra în astfel de conflicte de denumire? Sau numele de servicii sunt considerate parte a contractului cu containerele și nu ar trebui să le schimb liber?

98
0 + 0
Puncte:2
avatar Server
drapel in
mdaniel

Există o modalitate de a configura clusterul pentru a nu adăuga acele variabile automate pentru fiecare serviciu vizibil?

Da și nu: nu la nivel de cluster, AFAIK, ci enableServiceLinks: false câmp în specificație: este conceput pentru a vă permite să le opriți

În mod alternativ, utilizarea altor runtime precum containerd ar rezolva această problemă?

Nu, acele nume au fost adăugate în spiritul compatibilității cu docker, dar nu sunt deloc legate de docker -- sunt injectat de kubelet

Cum, în general, folosesc mediul fără a intra în astfel de conflicte de denumire? Sau numele de servicii sunt considerate parte a contractului cu containerele și nu ar trebui să le schimb liber?

O altă opțiune este mai degrabă decât interzicerea lor cu ridicata, de asemenea, puteți doar masca specific cele care deranjează aplicația dvs.; cele care se termină în _HTTP sunt mai ales problematice cu Spring Boot unde există o Serviciu a caror metadate: { nume: este un nume super generic ca serviciu sau Server

Puteți face asta pentru fiecare implementare:

env:
- nume: SERVICENAME_PORT_HTTP
  # omiterea valorii: o setează doar la șirul gol din container
# si restul

sau puteți declara un ConfigMap care le conține pe cele ofensive și le suprascrieți în gros cu envFrom: (pentru a nu fi nevoit să corecteze fiecare implementare afectată

0 + 0
drapel in
Petr Gladkikh
Mulțumiri! Îmi place `enableServiceLinks: false`. Ultima opțiune, mascarea explicit a variabilelor, nu pare a fi practică, deoarece ar trebui să știți deja că acestea ies în cale, ceea ce în sine poate să nu fie evident (aceasta este o problemă cu care am început) și numele s-ar schimba dacă cineva ar redenumit serviciile. sau creați altele noi.
0
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.