Pod, node eller klynge: hvad en VPN-sidecar egentlig omdirigerer

En VPN-sidecar i en Kubernetes-Pod ligner en VPN på værtsniveau med bedre manerer, og ligheden slutter ved navnerummets grænse. Containere i en Pod deler netværksnavnerummet, inklusive adresse- og portrummet, så en sidecar, der installerer ruter og politik, ændrer reelt, hvor applikationens pakker går hen. Den ændrer intet for de andre Pods på noden, og den rører ikke nodens egen stak, medmindre du konfigurerer den til det. At få den grænse rigtigt afgør både, hvad du kan udrulle, og hvad du skal teste. Afsnittene nedenfor følger det fra navnerummet og udad.

Delt navnerum, delte konsekvenser

To containere i en Pod taler over loopback og ser de samme interfaces, og det er derfor sidecar-mønsteret overhovedet virker: applikationen behøver ikke at vide, at der findes en tunnel, fordi den rute, den opløser, blev installeret i det navnerum, den bruger. Den samme egenskab betyder, at sidecar'ens fejl er applikationens fejl. En rute, der fanger for meget, eller en DNS-ændring, der peger på en resolver inde i tunnelen, gælder straks for hver proces i den Pod. I et delt navnerum findes der ingen routing pr. container, så en sidecar kan ikke afgrænses til én proces.

Det er mekanismen, man skal huske under gennemgang: skadesradius er Pod'en, ikke noden og ikke klyngen.

Hvad sidecar'en ikke når

Andre Pods beholder deres egne navnerum og deres egen routing, så en arbejdsbyrde, der har brug for samme udgang, har brug for samme sidecar eller i stedet et design på nodeniveau. Nodens trafik er også uden for Pod'ens navnerum, og Pods med værtsnetværk vælger bevidst at melde sig helt ud af denne isolering. Hvis du kører sidecar'en med værtsnetværk for at nå noget bekvemt, har du udvidet omfanget fra én Pod til hele noden og bør sige det højt.

Trafik til klyngens tjenester er den anden almindelige overraskelse. En bred standardrute inde i Pod'en kan fange anmodninger beregnet til API-serveren eller en ClusterIP-tjeneste, som så fejler på måder, der ser ud som om tunnelen er i stykker.

Ruteplan: Pod-, tjeneste-, node- og VPN-intervaller

Skriv de fire intervaller ned, og kontroller dem for overlap, før du udruller noget: Pod-CIDR, tjeneste-CIDR, nodeadresser og destinationerne bag VPN'en. Overlap mellem VPN'ens private intervaller og klyngens eget rum er ikke sjældent, og en standardrute er den forkerte løsning på det. Ruteplanen hører til i samme repository som manifestet, fordi den næste klynge kan uddele helt andre Pod- og tjenesteintervaller.

DNS er en del af planen og ikke en særskilt bekymring. En sidecar, der omskriver resolver-konfigurationen, kan bryde service discovery inde i klyngen, mens eksterne opslag fungerer perfekt.

Opstart og fejl er udtrykkelige tilstande

En kørende sidecar-proces er ikke en udgangspolitik. Beslut, hvilken trafik der må flyde, før tunnelen er klar, og hvad der sker, hvis den dør bagefter, og implementér så den beslutning: en probe, der gater applikationscontaineren, en netværkspolitik, der afviser som standard, eller begge dele. Uden en af dem starter applikationen, opløser og sender trafik ud ad nodens normale vej, mens tunnelen stadig forbinder.

Det hul er kort i en sund klynge og permanent i en brudt, og det er netop den egenskab, en angriber eller en utilsigtet datalæk foretrækker.

Par ordenen med en fejltest. Dræb sidecar'en, og bekræft, at applikationen mister sin tilsigtede udgang i stedet for lydløst at falde tilbage.

Kapaciteter, politikker og test fra app-containeren

At give de kapaciteter, der skal til for at oprette interfaces og ændre ruter, er en privilegiebeslutning, og en privilegie, der passer til en isoleret Pod, passer ikke automatisk på nodens stak. Brug klyngens understøttede mekanismer for netværks- og sikkerhedspolitik, og antag ikke, at enhver CNI- eller politikimplementering behandler et VPN-interface ens; forskellene viser sig netop i de fejltilfælde, du bekymrer dig om.

Test fra den rigtige applikationscontainer med friske anmodninger til en privat destination, en klyngetjeneste og det offentlige internet. En test fra sidecar'en beviser, at tunnelen virker, ikke at applikationen kan nå det, den har brug for.

Dokumentér klyngens netværksantagelser ved siden af VPN-konfigurationen. At flytte arbejdsbyrden til en anden klynge er så en øvelse i at kontrollere ruteplanen i stedet for en imageændring, der lydløst holder op med at virke.