Puncte:0

Kubernetes gestionează multe servere UDP distincte pe GKE

drapel au

Încerc să configurez un sistem care poate rula automat în sus și în jos serverele de jocuri video ca imagini docker. În acest caz, factoriotools/factorio-docker. Fiecare joc este o implementare diferită, distinctă, cu un singur pod a acelui container și, prin urmare (în cazul simplificat) are nevoie de propria sa adresă IP care poate asculta pe un anumit port UDP. Echilibratoarele de încărcare sunt redundante și irelevante, iar Cloud NAT nu pare să permită traficul de intrare cu ușurință.

Există câteva moduri pe care le cunosc pentru a face acest lucru să funcționeze, ambele cu compromisuri destul de importante:

  • Pot folosi un serviciu NodePort și pot pierde controlul asupra portului la care trebuie să se conecteze clientul. Aceasta este o problemă deoarece serverul se înregistrează pe o listă de servere.
  • Pot folosi rețelele gazdă. Dacă informațiile mele sunt corecte, asta necesită containere privilegiate, ceea ce cu siguranță nu este bine.
  • Aș putea folosi un echilibrator de încărcare UDP, dar chiar dacă acesta există și funcționează, este scump.

Probabil că există modalități de a rezolva limitările oricărei abordări (pentru a doua, păstrați gazdele de scurtă durată și mențineți firewall-ul strict și ar trebui să fie în mare parte OK?), dar nu pot să nu cred că există o opțiune mai bună pe care nu le găsesc descrise în documentele oficiale kubernetes. Traefik are vreun truc despre care nu știu? Există vreo modalitate de a obține o variantă de MetalLB care poate aloca în mod dinamic adrese IP publice după cum am nevoie de ele?

Cum fac ca fiecare server-container să asculte pe o adresă IP publică diferită cu un anumit port UDP, fără a face securitatea imposibilă în acest proces?

Editări:

  • Portul poate fi configurat, atâta timp cât știu pe ce port trebuie să ruleze serverul înainte ca podul să pornească.
  • Dacă nu înțeleg greșit documentele serverului, clientul trebuie să se poată conecta la același port pe care îl ascultă serverul. Diferența pe care o face k8s între portul de ascultare a aplicației și portul de conectare a clientului nu este de ajutor în cazul meu.
  • Adresarea această întrebare , nu vreau un echilibrator de încărcare pentru că nu face nimic pentru mine. Schimbarea adreselor IP nu contează, sistemul este proiectat să se ocupe de asta. Dacă serverul se blochează timp de 15 secunde, oricum toată lumea va trebui să se reconnecteze și atunci vor găsi noua adresă IP. Serverul nu poate gestiona mai multe poduri în același joc, așa că nu va exista niciodată mai mult de o replică.
  • Tocmai am incercat a NodePort serviciu cu un port public randomizat (nu văzusem încă că pot alege portul extern) și am obținut conexiuni directe pentru a funcționa, dar nu și conexiuni de listă de server.Procesul de listare a serverului detectează mai întâi modul de conectare la server, făcând ca serverul să trimită trafic UDP de ieșire către un punct final dat. Deci, nu numai că trebuie să controlez la ce port se conectează traficul de intrare, trebuie să controlez și modul în care este rutat traficul de ieșire, inclusiv orice NAT care ar putea fi utilizat.
Dawid Kruk avatar
drapel cn
Aș socoti că modalitatea recomandată de a face acest lucru ar fi crearea unui „Deployment” cu un „Service” de tip „LoadBalancer” pentru fiecare joc. Acest lucru ar implica costuri în consecință pentru: https://cloud.google.com/vpc/network-pricing.În plus, nu sunt sigur că Traefik este capabil să „routeze” pachetele UDP: [sursa](https://doc.traefik.io/traefik/routing/routers/#configuring-udp-routers). În această configurare aveți 2 porturi care ar trebui configurate (`port` (clientul se conectează la acesta) și `targetPort` (ascultarea aplicației)). „Portul” poate fi schimbat sau ar trebui să fie același în fiecare joc?
xenrelay avatar
drapel au
Ajută acele editări?
Dawid Kruk avatar
drapel cn
da, cei de fapt ajuta. Nu am prea multe cunoștințe despre `Factorio`, dar cred că ați putea seta `Deployment` pentru fiecare joc care ar fi susținut cu `Service` de tip `nodePort` [cu un anumit port nodePort](https:/ /stackoverflow.com/a/60116792/12257134). Recunoscând celelalte puncte ale dumneavoastră (omițând „Serviciul” de tip „LoadBalancer”), nu pot spune altă soluție care ar funcționa în acest caz. Vă rugăm să spuneți dacă vi se potrivește sau dacă aveți alte preocupări.
xenrelay avatar
drapel au
Va trebui să testez pentru a vedea dacă NodePort funcționează așa cum descrie linkul, dar dacă o face, asta ar ajuta foarte mult. Totuși, situația în care traficul de ieșire este redirecționat către un alt port și impactul pe care îl are asupra listei de servere este probabil demn de o nouă întrebare.
Puncte:1
drapel cn

Postarea acestui răspuns wiki comunității pentru a stabili o abordare de bază pentru această întrebare, mai degrabă decât pentru a oferi o soluție definitivă.

Simțiți-vă liber să editați și să extindeți.


Vă puteți expune aplicațiile cu Servicii. Există câteva opțiuni în care fiecare este diferită într-un fel de alta:

  • ClusterIP: Expune Serviciul pe un IP intern al clusterului. Alegerea acestei valori face ca Serviciul să fie accesibil doar din cadrul clusterului. Aceasta este valoarea implicită ServiceType.
  • NodePort: Expune Serviciul pe IP-ul fiecărui Nod la un port static (the NodePort). A ClusterIP Serviciul, la care NodePort Rute de serviciu, este creat automat. Veți putea contacta NodePort Service, din afara clusterului, prin solicitare <NodeIP>:<NodePort>.
  • Echilibrarea greutății: Expune Serviciul în exterior utilizând echilibrul de încărcare al unui furnizor de cloud. NodePort și ClusterIP Serviciile către care se îndreaptă echilibrul de încărcare extern sunt create automat.
  • ExternalName: Mapează Serviciul la conținutul externalName domeniu (de ex. foo.bar.example.com), prin returnarea a CNAME înregistrarea cu valoarea sa. Nu este configurată niciun fel de proxy.

-- Kubernetes.io: Documente: Concepte: Servicii de rețea: Serviciu: Tipuri de servicii de servicii de publicare

Documentația specifică expunerii aplicațiilor pe Google Kubernetes Engine poate fi gasit aici:


Concentrându-ne în mod specific pe unele dintre punctele incluse în întrebare:


Pot folosi un serviciu NodePort și pot pierde controlul asupra portului la care trebuie să se conecteze clientul. Aceasta este o problemă deoarece serverul se înregistrează pe o listă de servere.

Puteți specifica NodePort port în Serviciu YAML (cum ar fi nodePort: 32137 sau nodePort: 30911).

Puteți configura aplicația pentru a asculta pe același port ca nodePort:

  • Aplicația este ascultată pe port 30000
  • Serviciul folosește un nodePort cu port:30000 (clientul/utilizatorul ar trebui să se conecteze la acest port) și targetPort:30000. În acest caz, nu ar exista modificări de port.

O notă secundară!

În mod implicit, nodePort intervalul de porturi este blocat de GCP Firewall. Va trebui să creați o regulă (sau un set de reguli) care să permită acest lucru.


Pot folosi rețelele gazdă. Dacă informațiile mele sunt corecte, asta necesită containere privilegiate, ceea ce cu siguranță nu este bine.

Aș sfătui să nu folosiți containere privilegiate dacă nu există un motiv întemeiat în spate. Citând documentația oficială:

Politica Privilegiată este deschisă intenționat și complet nerestricționată. Acest tip de politică vizează, de obicei, sarcinile de lucru la nivel de sistem și infrastructură gestionate de utilizatori privilegiați și de încredere.

-- Kubernetes.io: Documente: Concepte: Securitate: Standard de securitate pentru pod: Privilegiat


Portul poate fi configurat, atâta timp cât știu pe ce port trebuie să ruleze serverul înainte ca podul să pornească.

Cum vei avea o multitudine de single Păstăi (fiecare cu câte un Implementare) ai putea parametriza fiecare dintre ele. Ceea ce vreau să spun este că poți crea un șablon și modifica doar părțile manifestelor tale (cum ar fi porturile, variabilele env etc.).

Puteți trece variabila de mediu către dvs Pod astfel încât să poată fi folosit ca parametru în comenzile dvs. De asemenea, puteți modifica comanda pe care Pod începe cu

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.