Pod-IP, ClusterIP eller intern lastbalansar for VPN-brukarar

Med VPC CNI kan ein Pod ha ei adresse frå VPC-et, og ein VPN-brukar med rett rute kan nå ho direkte. Det får direkte Pod-tilgang til å kjennast som det enklaste alternativet, og det er det, heilt til Poden vert erstatta. Adressa ein brukar hugsar, bør høyra til applikasjonen, ikkje ein replika. Samanlikninga av dei tre inngangane handlar til slutt om kva objekt som eig adressa, og kva som må halda fram med å verka når arbeidslasta flyttar seg.

Vel først etter livssyklus, deretter etter kva nettverket må gjera for at inngangen skal bli tilgjengeleg.

Tre inngangar, tre livssyklusar

Ein Pod-IP vert eigd av ein Pod: han vert tildelt saman med han og frigjord når han avsluttar. Ein ClusterIP vert eigd av ein Service og er virtuell, han gjev berre meining der tenesterutinga til klynga finst. Ein intern lastbalansar vert eigd av ein skyressurs som kontrolløren i klynga programmerer med backendar. Desse eigarskapsmodellane føresegner feilen du får: ei utdatert adresse, eit namn som ikkje kan nåast, eller eit backend-sett som er utdatert.

Skriv ned samanlikninga før du vel. Når eigaren og feilen er namngjevne, gjer valet seg vanlegvis sjølv.

Direkte Pod-tilgang: nyttig, mellombels

Direkte tilgang er verkeleg nyttig for ein kontrollert sjekk: ein administrator, ei kort økt, ein bestemd port. Men det er ein dårleg kontrakt for brukarar, fordi adressa er ein implementasjonsdetalj som endrar seg ved kvar utrulling. Og å skriva ein ned i ein wiki er måten ein fungerande teneste vert eit rykte.

Det inviterer òg til breie reglar. Løyve for ein administrator til å nå ein Pod er ikkje løyve til kvar adresse i subnettet til noden, og det er vanlegvis den andre som vert skriven.

ClusterIP: klyngebegrensa av design

Ein ClusterIP verkar fordi dataplanet i klynga programmerer ruting for han inne i klynga. Frå ein laptop på VPN-et tyder adressa ingenting med mindre noko medvite eksponerer ho. Eit namn som endar på svc.cluster.local høyrer til DNS-en i klynga, så å kopiera det til ein klient med ein annan resolver gjev eit namn som ikkje finst i staden for ein rutingfeil.

ClusterIP er framleis den rette inngangen for kallarar inne i klynga, inkludert andre arbeidslaster. Det er berre ikkje ein publiseringsmekanisme for brukarar utanfor rutedomenet til klynga.

Intern lastbalansar: den publiserte vegen

Ein intern lastbalansar gjev deg ei stabil privat adresse og eit namn di eiga sone kan peika på, medan kontrolløren held backend-settet oppdatert, slik EKS-rettleiinga for lastbalansering skildrar. Det er inngangen som overlever ein vanleg Pod-utskifting utan at nokon redigerer eit dokument. Han kostar ein skyressurs, ein kontrollørkonfigurasjon og ei rute frå VPN-et, og det er desse delane folk undervurderer.

Bruk kontrollørmodellen klynga faktisk køyrer. Annotasjonar skrivne for éin integrasjon gjeld ikkje for ein annan.

Kven kjeldeadressa er

Sikkerheitsgrupper ser kjelda som kjem til grensa deira, og det kan vera den tilkopla klienten eller ei omsett adresse avhengig av VPN- og lastbalanseringsvegen. På EC2-baserte nodar arvar vanlege VPC CNI-Podar nodens ENI-grupper som standard, medan støtta konfigurasjonar kan knyta Pod-spesifikke grupper. Skriv reglar for den dokumenterte vegen i staden for ei antatt laptopadresse.

Hald applikasjonen sin eigen lyttar og autentisering som separate kontrollar. Ein nettverksregel som tillèt flyten er ikkje ei autorisasjonsavgjerd og bør ikkje handsamast som ei.

Kva du skal gje brukarane

Gje brukarane eit tenestenamn, ikkje ei adresse. Publiser namnet i den private sona, peik det mot den interne inngangen, og test deretter ved å byta ut ein backend-Pod medan ein klient held det same namnet ope. Den øvinga testar eigenskapen som betyr noko: å nå den same applikasjonen etter ein rutinemessig utrulling.

Hald direkte Pod-tilgang som eit dokumentert operativt unntak med sitt eige omfang, langt unna brukarinstruksjonane.