Aceasta este o continuare a o întrebare prealabilă pe care am pus-o, dar cu o altă întrebare/abordare. În cazul în care contează, sunt pe GKE, dar sper că există un răspuns independent de cloud.
Încerc să rulez containerul factoriotools/factorio, dar aplicația are anumite cerințe speciale datorită utilizării unei funcții de listare a serverelor publice specifice aplicației, așa cum se vede în multe jocuri video care folosesc servere găzduite de utilizator.
Până acum, am reușit să fac lucrurile să funcționeze cu rețelele gazdă și conexiuni directe pentru a lucra cu un serviciu NodePort.Cu toate acestea, funcția de listare a serverelor publice a aplicației rămâne o problemă pentru containerele neprivilegiate.
Iată cum Factorio își dă seama cum să gestioneze lista de servere publice:
- Containerul ascultă pe un soclu, să spunem portul UDP 34197.
- Serviciul NodePort direcționează public acest trafic către 20635.
- Containerul trimite un ping prin portul său de ascultare (34197) către un server de ping-pong, iar serverul de ping-pong răspunde cu adresa IP și portul de la care a primit ping-ul. În afara k8s, acesta ar fi încă portul 34197.
- Containerul folosește apoi aceste informații pentru a se înregistra în lista de server. Adresa IP, portul, numele serverului și alte informații.
- În GKE, ping-pong-ul este direcționat către un port arbitrar neutilizat (de exemplu, 40792).
- Containerul crede că ascultă pe un alt port decât cel pe care l-am configurat (20534), apoi se înregistrează pe lista serverului public folosind portul greșit (40792, deoarece serverul de ping-pong a spus așa).
- Orice încercare de conectare de la lista de servere publice eșuează; clientul crede că serverul ascultă pe portul la care a fost martor serverul de ping-pong (40792), dar containerul a interacționat cu portul său de ascultare (34197) tot timpul.
(Mi s-a spus că acest proces este o variație a modului în care funcționează ICE/STUN)
Deci, asta înseamnă că, dacă containerul ascultă pe 34197, dar Kubernetes îl direcționează către 20635 extern, atât traficul de intrare, cât și cel de ieșire trebuie să treacă prin 20635 din partea publică pentru ca funcția de listare a serverului încorporată a aplicației să funcționeze.
Dacă ocol listarea serverului public și mă conectez direct la adresa IP publică a nodului containerului cu portul 20635, funcționează impecabil. Dar acesta este un compromis destul de masiv pentru ceea ce fac.
Rețeaua gazdă ocolește întreaga problemă, permițând containerului să deschidă direct orice port dorește pe gazdă.Pentru gazdele care sunt deja expuse public, acest lucru înseamnă că nimic de pe gazdă (mai ales nu k8s) nu poate redirecționa traficul containerului prin straturi suplimentare și poate schimba numerele de port. Deci, când containerul deschide portul 34197, primește portul 34197. Când trimite pe portul 34197, acel trafic este trimis pe portul 34197. Serverul de ping-pong vede portul pe care ar trebui să-l vadă. Și pentru că este un port public UDP, nu contează cine a trimis primul trafic; traficul este trafic, portul este portul.
Cu toate acestea, dacă înțeleg documentele corect, rularea unui container pe stiva de rețea a gazdei necesită un container privilegiat, care este efectiv acces root pe gazdă, care este foarte prost în producție. Deci, pentru containerele neprivilegiate, trebuie să existe o altă soluție decât baza pe rețelele gazdă. Nu pot găsi acea „altă soluție”.
Nu găsesc nicăieri documentație despre cum să fac asta, sau chiar dovezi că cineva se gândește la asta. Cum fac asta să funcționeze?
