Pod-IP, ClusterIP eller intern load balancer til VPN-brugere

Med VPC CNI kan en Pod have en adresse fra VPC’et, og en VPN-bruger med den rigtige rute kan nå den direkte. Det får direkte Pod-adgang til at føles som den enkleste mulighed, og det er den, indtil Pod’en udskiftes. Den adresse, en bruger husker, bør tilhøre applikationen, ikke en replika. Sammenligningen af de tre indgange ender med at handle om, hvilket objekt der ejer adressen, og hvad der skal blive ved med at virke, når arbejdsbyrden flytter sig.

Vælg først efter livscyklus, derefter efter hvad netværket skal gøre for at gøre indgangen tilgængelig.

Tre indgange, tre livscyklusser

En Pod-IP ejes af en Pod: den tildeles med den og frigives, når den slutter. En ClusterIP ejes af en Service og er virtuel, den giver kun mening, hvor klyngens servicerouting findes. En intern load balancer ejes af en cloudressource, som klyngens controller programmerer med backends. De ejerskabsmodeller forudsiger den fejl, du får: en forældet adresse, et navn der ikke kan nås, eller et backend-sæt, der er forældet.

Skriv sammenligningen ned, før du vælger. Når ejeren og fejlen er navngivet, vælger valget som regel sig selv.

Direkte Pod-adgang: nyttig, midlertidig

Direkte adgang er virkelig nyttig til et kontrolleret tjek: én administrator, én kort session, én bestemt port. Men det er en dårlig kontrakt for brugere, fordi adressen er en implementeringsdetalje, der ændrer sig ved hver udrulning. Og at skrive en ned i en wiki er måden, hvorpå en fungerende tjeneste bliver til et rygte.

Det indbyder også til brede regler. Tilladelse til, at én administrator når én Pod, er ikke tilladelse til hver adresse i nodens undernet, og det er normalt den anden, der bliver skrevet.

ClusterIP: klyngebegrænset af design

En ClusterIP virker, fordi klyngens dataplane programmerer routing for den inde i klyngen. Fra en laptop på VPN’et betyder adressen intet, medmindre noget bevidst eksponerer den. Et navn, der ender på svc.cluster.local, tilhører klyngens DNS, så kopiering af det til en klient med en anden resolver giver et navn, der ikke findes, i stedet for en routingfejl.

ClusterIP er fortsat den rigtige indgang for kaldere inde i klyngen, herunder andre arbejdsbyrder. Det er blot ikke en publiceringsmekanisme for brugere uden for klyngens routingdomæne.

Intern load balancer: den publicerede vej

En intern load balancer giver dig en stabil privat adresse og et navn, som din egen zone kan pege på, mens controlleren holder backend-sættet aktuelt, som EKS-vejledningen om load balancing beskriver. Det er den indgang, der overlever en almindelig Pod-udskiftning, uden at nogen redigerer et dokument. Den koster en cloudressource, en controllerkonfiguration og en rute fra VPN’et, og det er de dele, folk undervurderer.

Brug den controllermodel, som klyngen faktisk kører. Annotationer skrevet til én integration gælder ikke for en anden.

Hvem kildeadressen er

Sikkerhedsgrupper ser den kilde, der ankommer til deres grænse, og det kan være den forbundne klient eller en oversat adresse afhængigt af VPN- og load-balancing-vejen. På EC2-baserede noder arver almindelige VPC CNI-Pods som standard nodens ENI-grupper, mens understøttede konfigurationer kan tilknytte Pod-specifikke grupper. Skriv regler for den dokumenterede vej i stedet for en gættet laptopadresse.

Hold applikationens egen listener og godkendelse som separate kontroller. En netværksregel, der tillader flowet, er ikke en autorisationsbeslutning og bør ikke behandles som en.

Hvad du skal give brugerne

Giv brugerne et servicenavn, ikke en adresse. Publicer navnet i den private zone, peg det på den interne indgang, og test derefter ved at udskifte en backend-Pod, mens en klient holder det samme navn åbent. Den øvelse tester den egenskab, der betyder noget: at nå den samme applikation efter en rutinemæssig udrulning.

Hold direkte Pod-adgang som en dokumenteret operationel undtagelse med sit eget omfang, langt væk fra brugerinstruktionerne.