Cum pot obține IP static de ieșire pe spațiu de nume într-un cluster EKS

Configurația mea actuală implică un cluster EKS cu mai multe spații de nume (multi-locatari) în multe noduri EKS diferite în subrețele private. Aș dori ca traficul de ieșire din pod-uri să aibă un EIP dedicat per spațiu de nume. AFAIK nu există soluții disponibile pentru această problemă. Am căutat mult și greu pe internet, dar în zadar. Iată câteva dintre soluțiile pe care le-am obosit, dar în cele din urmă am lovit un obstacol.

Istio Egress Gateway Vă permite să direcționați tot traficul de ieșire din poduri printr-un pod dedicat de ieșire gateway. Dar podul gateway-ului de ieșire va prelua ip-ul nodului pe care rulează, ceea ce nu va funcționa pentru cazul meu de utilizare. De asemenea, nu am găsit documentație decentă despre modul în care pot configura mai multe poduri de gateway de ieșire pe mai multe noduri.

Calico Egress Gateway Foarte similar cu soluția Istio Egress Gateway și se aplică aceeași constrângere

Soluție personalizată Am început să implementez o soluție personalizată, în care am configurat mai multe noduri Gateway în subrețea publică, fiecare cu un EIP dedicat. Acum pot modifica rutele/gateway-urile IP în nodul EKS privat, pentru a direcționa traficul printr-un anumit nod gateway pe baza IP-ului sursei podului.Această soluție pare foarte neplăcută, iar costul operațional al unei astfel de soluții este foarte mare.

M-am uitat la solutii de genul acest, dar nu am avut noroc cu ei.

Există o abordare/soluție mai bună pentru această problemă?

P.S. Clusterul meu de producție este extrem de mare, nu-mi permit să suport un cluster pentru fiecare spațiu de nume.

Am postat această întrebare pe Cross stackoverflow de asemenea. Chiar nu sunt sigur care forum este un loc mai bun pentru această întrebare. Bucură-te să-l șterg acolo unde este cazul.

Rezumat din discuția pe acest subiect pentru mai multă vizibilitate aici:

Există o solicitare de caracteristică creată în GitHub, dar fără actualizări din martie.

Calico Enterprise va rezolva acest caz de utilizare specific prin alocarea unui IP spațiului de nume așa cum este descris în integrarea lor pentru Kubernetes Aici:

Egress Gateway definește un IP static de ieșire pentru SNAT la traficul care părăsește clusterul și îl aplică unui anumit spațiu de nume. Apoi desemnează un pod într-un spațiu de nume ca pod de ieșire și atribuie un IP rutabil care este utilizat în mod special pentru traficul de ieșire care părăsește clusterul.

Dar, în practică, podul gateway Egress nu este conștient de AWS VPS, prin urmare nu poate atribui EIP pod-urilor Egress. Când traficul iese din podurile de gateway, acesta presupune IP-ul nodului însuși ca IP sursă.

multe noduri EKS diferite în subrețele private...

EIP nu funcționează în subrețeaua privată.Dacă aveți noduri de lucru desemnate în subrețeaua publică, puteți utiliza EIP și proxy invers pe aceste noduri accesibile public pentru a expune serviciile în rețeaua privată. Apoi, puteți utiliza Calico Egress Gateway pe aceste noduri publice pentru podurile proxy inverse, la rândul lor, utilizează EIP-ul de bază.

În cele din urmă, m-am hotărât pe o soluție, în care ies traficul din podurile din subrețea privată prin „Proxy Pods” pe care le-am configurat în subrețele publice. Aceste poduri proxy li se atribuie ip-uri publice, prin urmare traficul de ieșire își asumă automat aceste ip-uri. Din punct de vedere operațional, această soluție are o suprasarcină, dar acesta este cel mai bun lucru pe care l-am putut găsi, având în vedere constrângerile