Pod, nod eller kluster: vad en VPN-sidecar egentligen dirigerar om

En VPN-sidecar i en Kubernetes-Pod ser ut som en VPN på värdnivå med bättre uppförande, och likheten slutar vid namnrymdens gräns. Containrar i en Pod delar nätverksnamnrymden, inklusive adress- och portutrymmet, så en sidecar som installerar rutter och policy ändrar faktiskt vart applikationens paket tar vägen. Den ändrar ingenting för de andra Podarna på noden, och den rör inte nodens egen stack om du inte konfigurerar den så. Att få den gränsen rätt avgör både vad du kan driftsätta och vad du måste testa. Avsnitten nedan följer det från namnrymden och utåt.

Delad namnrymd, delade konsekvenser

Två containrar i en Pod pratar över loopback och ser samma gränssnitt, och det är därför sidecar-mönstret alls fungerar: applikationen behöver inte veta att en tunnel finns, eftersom rutten den löser upp till installerades i den namnrymd den använder. Samma egenskap betyder att sidecarens misstag är applikationens misstag. En rutt som fångar för mycket, eller en DNS-ändring som pekar på en resolver inne i tunneln, gäller omedelbart för varje process i den Poden. I en delad namnrymd finns ingen routning per container, så en sidecar kan inte begränsas till en process.

Det här är mekanismen att hålla i minnet vid granskningen: skadradien är Poden, inte noden och inte klustret.

Vad sidecaren inte når

Andra Podar behåller sina egna namnrymder och sin egen routning, så en arbetsbelastning som behöver samma utgång behöver samma sidecar eller i stället en design på nodnivå. Nodens trafik ligger också utanför Podens namnrymd, och Podar med värdnätverk väljer medvetet att helt avstå från den här isoleringen. Om du kör sidecaren med värdnätverk för att något bekvämt, har du vidgat omfånget från en Pod till hela noden och bör säga det högt.

Trafik till klustrets tjänster är den andra vanliga överraskningen. En bred standardrutt inne i Poden kan fånga förfrågningar avsedda för API-servern eller en ClusterIP-tjänst, som sedan misslyckas på sätt som ser ut som om tunneln är trasig.

Ruttplan: Pod-, tjänste-, nod- och VPN-intervall

Skriv ner de fyra intervallen och kontrollera dem för överlapp innan du driftsätter något: Pod-CIDR, tjänste-CIDR, nodadresser och destinationerna bakom VPN. Överlapp mellan VPN:ens privata intervall och klustrets eget utrymme är inte ovanligt, och en standardrutt är fel lösning för det. Ruttplanen hör hemma i samma repository som manifestet, eftersom nästa kluster kan dela ut helt andra Pod- och tjänsteintervall.

DNS är en del av planen och inte en separat oro. En sidecar som skriver om resolver-konfigurationen kan bryta tjänsteupptäckten inne i klustret medan externa uppslag fungerar perfekt.

Start och fel är uttryckliga tillstånd

En körande sidecar-process är inte en utgångspolicy. Bestäm vilken trafik som får flöda innan tunneln är klar och vad som händer om den dör efteråt, och implementera sedan det beslutet: en probe som gatar applikationscontainern, en nätverkspolicy som nekar som standard, eller båda. Utan någon av dem startar applikationen, löser upp och skickar trafik utanför nodens normala väg medan tunneln fortfarande ansluter.

Det gapet är kort i ett sunt kluster och permanent i ett trasigt, och det är precis den egenskap en angripare eller en oavsiktlig dataläcka föredrar.

Koppla ordningen till ett feltest. Döda sidecaren och bekräfta att applikationen förlorar sin avsedda utgång i stället för att tyst falla tillbaka.

Kapabiliteter, policyer och testning från app-containern

Att ge de kapabiliteter som behövs för att skapa gränssnitt och ändra rutter är ett privilegiebeslut, och ett privilegium som passar en isolerad Pod är inte automatiskt lämpligt på nodens stack. Använd klustrets stödda mekanismer för nätverks- och säkerhetspolicy, och anta inte att varje CNI- eller policyimplementering behandlar ett VPN-gränssnitt likadant; skillnaderna visar sig just i de felfall du bryr dig om.

Testa från den riktiga applikationscontainern, med färska förfrågningar till en privat destination, en klustertjänst och det öppna internet. Ett test från sidecaren bevisar att tunneln fungerar, inte att applikationen når det den behöver.

Dokumentera klustrets nätverksantaganden bredvid VPN-konfigurationen. Att flytta arbetsbelastningen till ett annat kluster är då en övning i att kontrollera ruttplanen i stället för en imageändring som tyst slutar fungera.