Pod, nodo o cluster: che cosa reindirizza davvero un sidecar VPN

Un sidecar VPN dentro un Pod Kubernetes sembra una VPN a livello di host con modi migliori, e la somiglianza finisce al confine dello spazio dei nomi. I container di un Pod condividono lo spazio dei nomi di rete, compreso lo spazio di indirizzi e porte, quindi un sidecar che installa rotte e policy cambia davvero dove vanno i pacchetti dell'applicazione. Non cambia nulla per gli altri Pod sul nodo, e non tocca lo stack del nodo stesso a meno che non lo configuriate così. Cogliere bene questo confine decide sia cosa potete distribuire sia cosa dovete testare. Le sezioni seguenti lo seguono dallo spazio dei nomi verso l'esterno.

Spazio dei nomi condiviso, conseguenze condivise

Due container in un Pod parlano via loopback e vedono le stesse interfacce, ed è per questo che il pattern del sidecar funziona: l'applicazione non ha bisogno di sapere che esiste un tunnel, perché la rotta che risolve è stata installata nello spazio dei nomi che usa. La stessa proprietà significa che gli errori del sidecar sono errori dell'applicazione. Una rotta che cattura troppo, o un cambio DNS che punta a un resolver dentro il tunnel, si applica subito a ogni processo di quel Pod. In uno spazio dei nomi condiviso non esiste routing per container, quindi un sidecar non può essere limitato a un solo processo.

È il meccanismo da tenere a mente in fase di revisione: il raggio d'impatto è il Pod, non il nodo e non il cluster.

Dove il sidecar non arriva

Gli altri Pod mantengono i propri spazi dei nomi e il proprio routing, quindi un carico di lavoro che ha bisogno della stessa uscita ha bisogno dello stesso sidecar o, in alternativa, di un progetto a livello di nodo. Anche il traffico del nodo è fuori dallo spazio dei nomi del Pod, e i Pod con rete host rinunciano deliberatamente del tutto a questo isolamento. Se eseguite il sidecar con rete host per raggiungere qualcosa di comodo, avete allargato la portata da un Pod all'intero nodo e dovreste dirlo ad alta voce.

Il traffico verso i servizi del cluster è l'altra sorpresa comune. Una rotta predefinita ampia dentro il Pod può intercettare richieste destinate al server API o a un servizio ClusterIP, che poi falliscono in modi che sembrano un tunnel rotto.

Piano delle rotte: intervalli Pod, servizio, nodo e VPN

Annotate i quattro intervalli e controllateli per sovrapposizioni prima di distribuire qualcosa: CIDR del Pod, CIDR del servizio, indirizzi del nodo e destinazioni dietro la VPN. La sovrapposizione tra gli intervalli privati della VPN e lo spazio proprio del cluster non è rara, e una rotta predefinita è la soluzione sbagliata. Il piano delle rotte appartiene allo stesso repository del manifest, perché il prossimo cluster può assegnare intervalli di Pod e servizi del tutto diversi.

Il DNS fa parte del piano e non è una preoccupazione separata. Un sidecar che riscrive la configurazione del resolver può rompere il service discovery dentro il cluster mentre rende perfette le query esterne.

Avvio e guasto sono stati espliciti

Un processo sidecar in esecuzione non è una policy di uscita. Decidete quale traffico può fluire prima che il tunnel sia pronto e cosa succede se muore dopo, poi attuate quella decisione: una sonda che fa da gate al container dell'applicazione, una policy di rete che nega per impostazione predefinita, o entrambe. Senza una delle due, l'applicazione parte, risolve e invia traffico fuori dal percorso normale del nodo mentre il tunnel si sta ancora connettendo.

Quel vuoto è breve in un cluster sano e permanente in uno rotto, ed è esattamente la proprietà che preferisce un attaccante o una fuga di dati accidentale.

Abbinate l'ordine a un test di guasto. Uccidete il sidecar e confermate che l'applicazione perde l'uscita prevista invece di ripiegare in silenzio.

Capacità, policy e test dal container dell'applicazione

Concedere le capacità necessarie a creare interfacce e modificare rotte è una decisione sui privilegi, e un privilegio adatto a un Pod isolato non lo è automaticamente sullo stack del nodo. Usate i meccanismi di policy di rete e sicurezza supportati dal cluster e non date per scontato che ogni implementazione di CNI o di policy tratti un'interfaccia VPN allo stesso modo; le differenze emergono proprio nei casi di guasto che vi interessano.

Testate dal container reale dell'applicazione, con richieste nuove verso una destinazione privata, un servizio del cluster e internet pubblico. Un test dal sidecar dimostra che il tunnel funziona, non che l'applicazione raggiunge ciò di cui ha bisogno.

Documentate le ipotesi di rete del cluster accanto alla configurazione VPN. Spostare il carico di lavoro su un altro cluster diventa allora un esercizio di verifica del piano delle rotte invece di un cambio di immagine che smette silenziosamente di funzionare.