Pod IP, ClusterIP sau un balansator intern pentru utilizatorii VPN
Un Pod IP este rutabil prin VPN până când Pod-ul este înlocuit. Comparați accesul direct la Pod, ClusterIP și un balansator intern și cât vă costă fiecare.
Cu VPC CNI, un Pod poate avea o adresă din VPC, iar un utilizator VPN cu ruta corectă o poate atinge direct. Asta face accesul direct la Pod să pară cea mai simplă opțiune și chiar este, până când Pod-ul este înlocuit. Adresa pe care un utilizator o reține ar trebui să aparțină aplicației, nu unei replici. Compararea celor trei intrări se reduce la ce obiect deține adresa și ce trebuie să continue să funcționeze când sarcina de lucru se mută.
Alegeți mai întâi după ciclul de viață, apoi după ce trebuie să facă rețeaua pentru ca intrarea să fie accesibilă.
Trei intrări, trei cicluri de viață
Un Pod IP aparține unui Pod: este alocat odată cu el și eliberat când acesta se termină. Un ClusterIP aparține unui Service și este virtual, are sens doar acolo unde există rutarea serviciilor în cluster. Un balansator intern aparține unei resurse cloud pe care controlerul clusterului o programează cu backend-uri. Aceste modele de proprietate prezic defecțiunea pe care o veți primi: o adresă învechită, un nume de neatins sau un set de backend-uri învechit.
Scrieți comparația înainte de a alege. Odată ce proprietarul și defecțiunea sunt numite, alegerea se face de obicei singură.
| Entry | Owner | Failure when the workload moves |
|---|---|---|
| Pod IP | The Pod | Address changes and saved links break |
| ClusterIP | The Service | Virtual address with no meaning outside cluster routing |
| Internal balancer | Cloud resource plus controller | Backends update, but the DNS view is yours to maintain |
Acces direct la Pod: util, temporar
Accesul direct este cu adevărat util pentru o verificare controlată: un administrator, o sesiune scurtă, un port anume. Dar este un contract slab pentru utilizatori, pentru că adresa este un detaliu de implementare care se schimbă la fiecare implementare. Iar înregistrarea uneia într-un wiki este felul în care un serviciu funcțional devine un zvon.
De asemenea, invită la reguli largi. Permisiunea pentru un administrator de a atinge un Pod nu este permisiune pentru fiecare adresă din subrețeaua nodului, iar a doua este cea care se scrie de obicei.
ClusterIP: limitat la cluster prin proiectare
Un ClusterIP funcționează pentru că planul de date al clusterului programează rutarea pentru el în interiorul clusterului. De pe un laptop în VPN adresa nu înseamnă nimic dacă ceva nu o expune deliberat. Un nume care se termină în svc.cluster.local aparține DNS-ului clusterului, așa că copierea lui pe un client cu alt resolver produce un nume care nu există în loc de o eroare de rutare.
ClusterIP rămâne intrarea corectă pentru apelanții din interiorul clusterului, inclusiv alte sarcini de lucru. Pur și simplu nu este un mecanism de publicare pentru utilizatorii din afara domeniului de rutare al clusterului.
Balansator intern: calea publicată
Un balansator intern vă oferă o adresă privată stabilă și un nume către care zona dumneavoastră poate indica, în timp ce controlerul menține setul de backend-uri actualizat, așa cum descrie ghidul EKS pentru echilibrarea încărcării. Aceasta este intrarea care supraviețuiește unei înlocuiri obișnuite de Pod fără ca cineva să editeze un document. Costă o resursă cloud, o configurație de controler și o rută din VPN, iar acestea sunt părțile pe care oamenii le subestimează.
Folosiți modelul de controler pe care clusterul îl rulează efectiv. Adnotările scrise pentru o integrare nu se aplică alteia.
Cine este adresa sursă
Grupurile de securitate văd sursa care ajunge la granița lor, iar aceasta poate fi clientul conectat sau o adresă tradusă, în funcție de calea VPN și de echilibrare a încărcării. Pe nodurile bazate pe EC2, Pod-urile obișnuite VPC CNI moștenesc implicit grupurile ENI ale nodului, în timp ce configurațiile acceptate pot atașa grupuri specifice Pod-ului. Scrieți reguli pentru calea documentată, nu pentru o adresă presupusă a laptopului.
Păstrați listenerul și autentificarea proprii aplicației ca controale separate. O regulă de rețea care permite fluxul nu este o decizie de autorizare și nu ar trebui tratată ca atare.
Ce să le oferiți utilizatorilor
Oferiți utilizatorilor un nume de serviciu, nu o adresă. Publicați numele în zona privată, îndreptați-l spre intrarea internă și apoi testați înlocuind un Pod de backend în timp ce un client ține același nume deschis. Acel exercițiu testează proprietatea care contează: atingerea aceleiași aplicații după o implementare de rutină.
Păstrați accesul direct la Pod ca o excepție operațională documentată cu propriul domeniu, departe de instrucțiunile pentru utilizatori.