Pod, node eller klynge: kva ein VPN-sidecar eigentleg omdirigerer

Ein VPN-sidecar i ein Kubernetes-Pod ser ut som ein VPN på vertsnivå med betre manerar, og likskapen stoppar ved grensa til namnerommet. Containarar i ein Pod deler nettverksnamnerommet, inkludert adresse- og portrommet, så ein sidecar som installerer ruter og policy endrar faktisk kvar pakkane til applikasjonen går. Han endrar ingenting for dei andre Podane på noden, og han rører ikkje eigen stack på noden med mindre du konfigurerer han til det. Å få denne grensa rett avgjer både kva du kan rulle ut og kva du må teste. Avsnitta nedanfor følgjer det frå namnerommet og utover.

Delt namnerom, delte konsekvensar

To containarar i ein Pod snakkar over loopback og ser dei same grensesnitta, og det er derfor sidecar-mønsteret i det heile fungerer: applikasjonen treng ikkje vite at ein tunnel finst, fordi ruta han løyser opp til, vart installert i namnerommet han brukar. Den same eigenskapen betyr at feila til sidecaren er feila til applikasjonen. Ei rute som fangar for mykje, eller ei DNS-endring som peikar på ein resolver inne i tunnelen, gjeld straks for kvar prosess i den Poden. I eit delt namnerom finst det inga ruting per containar, så ein sidecar kan ikkje avgrensast til éin prosess.

Dette er mekanismen å hugse på under gjennomgangen: skaderadiusen er Poden, ikkje noden og ikkje klynga.

Kva sidecaren ikkje når

Andre Podar held på sine eigne namnerom og si eiga ruting, så ei arbeidsbelastning som treng same utgang treng same sidecar eller i staden eit design på nodenivå. Trafikken til noden er òg utanfor namnerommet til Poden, og Podar med vertsnettverk vel medvite å melde seg heilt ut av denne isolasjonen. Viss du køyrer sidecaren med vertsnettverk for å nå noko praktisk, har du utvida omfanget frå éin Pod til heile noden og bør seie det høgt.

Trafikk til tenestene i klynga er den andre vanlege overraskinga. Ei brei standardrute inne i Poden kan fange førespurnader meint for API-tenaren eller ei ClusterIP-teneste, som deretter feilar på måtar som ser ut som om tunnelen er øydelagd.

Ruteplan: Pod-, teneste-, node- og VPN-område

Skriv ned dei fire områda og kontroller dei for overlapping før du rullar ut noko: Pod-CIDR, teneste-CIDR, nodeadresser og destinasjonane bak VPN-en. Overlapping mellom dei private områda til VPN-en og eigen rom i klynga er ikkje sjeldan, og ei standardrute er feil løysing på det. Ruteplanen høyrer heime i same repositorium som manifestet, fordi neste klynge kan dele ut heilt andre Pod- og tenesteområde.

DNS er ein del av planen og ikkje ei eiga uro. Ein sidecar som skriv om resolver-konfigurasjonen, kan bryte tenesteoppdaging inne i klynga medan eksterne oppslag fungerer perfekt.

Oppstart og feil er eksplisitte tilstandar

Ein køyrande sidecar-prosess er ikkje ein utgangspolicy. Avgjer kva trafikk som kan flyte før tunnelen er klar, og kva som skjer om han døyr etterpå, og implementer så den avgjerda: ein probe som gatar applikasjonscontainaren, ein nettverkspolicy som nektar som standard, eller begge. Utan ein av dei startar applikasjonen, løyser opp og sender trafikk ut av den normale vegen til noden medan tunnelen framleis koplar til.

Det gapet er kort i ei sunn klynge og permanent i ei øydelagd, og det er nettopp eigenskapen ein angripar eller ein utilsikta datalekkasje føretrekk.

Kopla rekkjefølgja til ein feiltest. Drep sidecaren og stadfest at applikasjonen mistar den tiltenkte utgangen i staden for å falle stille tilbake.

Kapabilitetar, policyar og testing frå app-containaren

Å gi kapabilitetane som trengst for å lage grensesnitt og endre ruter er ei privilegieavgjerd, og eit privilegium som passar for ein isolert Pod er ikkje automatisk passande på stacken til noden. Bruk dei støtta mekanismane for nettverks- og tryggleikspolicy i klynga, og ikkje gå ut frå at kvar CNI- eller policyimplementasjon behandlar eit VPN-grensesnitt likt; skilnadene viser seg nettopp i feiltilfella du bryr deg om.

Test frå den verkelege applikasjonscontainaren, med ferske førespurnader til ein privat destinasjon, ei klyngeteneste og det opne internettet. Ein test frå sidecaren provar at tunnelen verkar, ikkje at applikasjonen når det han treng.

Dokumenter nettverksføresetnadene til klynga ved sida av VPN-konfigurasjonen. Å flytte arbeidsbelastninga til ei anna klynge er då ei øving i å kontrollere ruteplanen i staden for ei imageendring som stille sluttar å verke.