Pod-IP, ClusterIP eller intern lastbalanser for VPN-brukere

Med VPC CNI kan en Pod ha en adresse fra VPC-et, og en VPN-bruker med riktig rute kan nå den direkte. Det får direkte Pod-tilgang til å føles som det enkleste alternativet, og det er det, helt til Poden erstattes. Adressen en bruker husker, bør tilhøre applikasjonen, ikke en replika. Sammenligningen av de tre inngangene handler til slutt om hvilket objekt som eier adressen, og hva som må fortsette å virke når arbeidslasten flytter seg.

Velg først etter livssyklus, deretter etter hva nettverket må gjøre for at inngangen skal bli tilgjengelig.

Tre innganger, tre livssykluser

En Pod-IP eies av en Pod: den tildeles sammen med den og frigjøres når den avsluttes. En ClusterIP eies av en Service og er virtuell, den gir bare mening der klusterets tjenesteruting finnes. En intern lastbalanser eies av en skyressurs som klusterets kontroller programmerer med backender. Disse eierskapsmodellene forutsier feilen du får: en utdatert adresse, et navn som ikke kan nås, eller et backend-sett som er utdatert.

Skriv ned sammenligningen før du velger. Når eieren og feilen er navngitt, gjør valget seg vanligvis selv.

Direkte Pod-tilgang: nyttig, midlertidig

Direkte tilgang er virkelig nyttig for en kontrollert sjekk: én administrator, én kort økt, én bestemt port. Men det er en dårlig kontrakt for brukere, fordi adressen er en implementasjonsdetalj som endres ved hver utrulling. Og å skrive en ned i en wiki er måten en fungerende tjeneste blir til et rykte.

Det inviterer også til brede regler. Tillatelse for én administrator til å nå én Pod er ikke tillatelse til hver adresse i nodens subnett, og det er vanligvis den andre som skrives.

ClusterIP: klusterbegrenset av design

En ClusterIP virker fordi klusterets dataplan programmerer ruting for den inne i klusteret. Fra en laptop på VPN-et betyr adressen ingenting med mindre noe bevisst eksponerer den. Et navn som slutter på svc.cluster.local tilhører klusterets DNS, så å kopiere det til en klient med en annen resolver gir et navn som ikke finnes i stedet for en rutingfeil.

ClusterIP er fortsatt den riktige inngangen for kallere inne i klusteret, inkludert andre arbeidslaster. Det er bare ikke en publiseringsmekanisme for brukere utenfor klusterets rutingdomene.

Intern lastbalanser: den publiserte veien

En intern lastbalanser gir deg en stabil privat adresse og et navn din egen sone kan peke på, mens kontrolleren holder backend-settet oppdatert, slik EKS-veiledningen for lastbalansering beskriver. Det er inngangen som overlever en vanlig Pod-utskifting uten at noen redigerer et dokument. Den koster en skyressurs, en kontrollerkonfigurasjon og en rute fra VPN-et, og det er disse delene folk undervurderer.

Bruk kontrollermodellen klusteret faktisk kjører. Annotasjoner skrevet for én integrasjon gjelder ikke for en annen.

Hvem kildeadressen er

Sikkerhetsgrupper ser kilden som ankommer grensen deres, og det kan være den tilkoblede klienten eller en oversatt adresse avhengig av VPN- og lastbalanseringsveien. På EC2-baserte noder arver vanlige VPC CNI-Poder nodens ENI-grupper som standard, mens støttede konfigurasjoner kan knytte Pod-spesifikke grupper. Skriv regler for den dokumenterte veien i stedet for en antatt laptopadresse.

Hold applikasjonens egen lytter og autentisering som separate kontroller. En nettverksregel som tillater flyten er ikke en autorisasjonsbeslutning og bør ikke behandles som en.

Hva du skal gi brukerne

Gi brukerne et tjenestenavn, ikke en adresse. Publiser navnet i den private sonen, pek det mot den interne inngangen, og test deretter ved å bytte ut en backend-Pod mens en klient holder det samme navnet åpent. Den øvelsen tester egenskapen som betyr noe: å nå den samme applikasjonen etter en rutinemessig utrulling.

Hold direkte Pod-tilgang som et dokumentert operativt unntak med sitt eget omfang, langt unna brukerinstruksjonene.