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

En VPN-sidecar i en Kubernetes-Pod ser ut som en VPN på vertsnivå med bedre manerer, og likheten stopper ved navnerommets grense. Containere i en Pod deler nettverksnavnerommet, inkludert adresse- og portrommet, så en sidecar som installerer ruter og policy endrer faktisk hvor applikasjonens pakker går. Den endrer ingenting for de andre Podene på noden, og den berører ikke nodens egen stack med mindre du konfigurerer den til det. Å få denne grensen riktig avgjør både hva du kan rulle ut og hva du må teste. Avsnittene nedenfor følger det fra navnerommet og utover.

Delt navnerom, delte konsekvenser

To containere i en Pod snakker over loopback og ser de samme grensesnittene, og det er derfor sidecar-mønsteret i det hele tatt fungerer: applikasjonen trenger ikke vite at en tunnel finnes, fordi ruten den løser opp til, ble installert i navnerommet den bruker. Den samme egenskapen betyr at sidecarens feil er applikasjonens feil. En rute som fanger for mye, eller en DNS-endring som peker på en resolver inne i tunnelen, gjelder umiddelbart for hver prosess i den Poden. I et delt navnerom finnes det ingen ruting per container, så en sidecar kan ikke avgrenses til én prosess.

Dette er mekanismen å huske på under gjennomgangen: skaderadiusen er Poden, ikke noden og ikke klyngen.

Hva sidecaren ikke når

Andre Pods beholder sine egne navnerom og sin egen ruting, så en arbeidsbelastning som trenger samme utgang trenger samme sidecar eller i stedet et design på nodenivå. Nodens trafikk er også utenfor Podens navnerom, og Pods med vertsnettverk velger bevisst å melde seg helt ut av denne isolasjonen. Hvis du kjører sidecaren med vertsnettverk for å nå noe praktisk, har du utvidet omfanget fra én Pod til hele noden og bør si det høyt.

Trafikk til klyngens tjenester er den andre vanlige overraskelsen. En bred standardrute inne i Poden kan fange forespørsler ment for API-serveren eller en ClusterIP-tjeneste, som deretter feiler på måter som ser ut som om tunnelen er ødelagt.

Ruteplan: Pod-, tjeneste-, node- og VPN-områder

Skriv ned de fire områdene og kontroller dem for overlapping før du ruller ut noe: Pod-CIDR, tjeneste-CIDR, nodeadresser og destinasjonene bak VPN-en. Overlapping mellom VPN-ens private områder og klyngens eget rom er ikke sjelden, og en standardrute er feil løsning på det. Ruteplanen hører hjemme i samme repositorium som manifestet, fordi neste klynge kan dele ut helt andre Pod- og tjenesteområder.

DNS er en del av planen og ikke en egen bekymring. En sidecar som skriver om resolver-konfigurasjonen, kan bryte tjenesteoppdagelse inne i klyngen mens eksterne oppslag fungerer perfekt.

Oppstart og feil er eksplisitte tilstander

En kjørende sidecar-prosess er ikke en utgangspolicy. Bestem hvilken trafikk som kan flyte før tunnelen er klar, og hva som skjer hvis den dør etterpå, og implementer så den beslutningen: en probe som gater applikasjonscontaineren, en nettverkspolicy som nekter som standard, eller begge deler. Uten en av dem starter applikasjonen, løser opp og sender trafikk ut av nodens normale vei mens tunnelen fortsatt kobler til.

Det gapet er kort i en sunn klynge og permanent i en ødelagt, og det er nettopp egenskapen en angriper eller en utilsiktet datalekkasje foretrekker.

Koble rekkefølgen til en feiltest. Drep sidecaren og bekreft at applikasjonen mister den tiltenkte utgangen i stedet for å falle stille tilbake.

Kapabiliteter, policyer og testing fra app-containeren

Å gi kapabilitetene som trengs for å lage grensesnitt og endre ruter er en privilegiebeslutning, og et privilegium som passer for en isolert Pod er ikke automatisk passende på nodens stack. Bruk klyngens støttede mekanismer for nettverks- og sikkerhetspolicy, og ikke anta at enhver CNI- eller policyimplementering behandler et VPN-grensesnitt likt; forskjellene viser seg nettopp i feiltilfellene du bryr deg om.

Test fra den ekte applikasjonscontaineren, med ferske forespørsler til en privat destinasjon, en klyngetjeneste og det åpne internettet. En test fra sidecaren beviser at tunnelen virker, ikke at applikasjonen når det den trenger.

Dokumenter klyngens nettverksantakelser ved siden av VPN-konfigurasjonen. Å flytte arbeidsbelastningen til en annen klynge er da en øvelse i å kontrollere ruteplanen i stedet for en imageendring som stille slutter å virke.