VPN per Pod in Kubernetes o gateway di uscita: a chi appartiene il tunnel?
Un Pod è il proprio spazio dei nomi di rete, quindi la scelta reale è quale livello possiede il tunnel: identità per carico di lavoro o uscita guidata dal CNI con un’unica sorgente condivisa.
Distribuisci un Pod chiamato vpn-gateway, punti un client di prova al suo indirizzo e vedi i pacchetti svanire. Nulla nel manifest è sbagliato e il kubelet non ha nulla da ridire. La ragione è strutturale e non di configurazione: Kubernetes assegna a ogni Pod il proprio spazio dei nomi di rete, quindi un nome, un’etichetta o uno spazio dei nomi API condiviso non cambiano nulla su dove vanno i pacchetti. Perciò decidere come il traffico VPN lascia il cluster inizia con una domanda sulla proprietà, non sulle immagini dei container.
Due meccanismi coprono la maggior parte delle distribuzioni reali e non sono intercambiabili. Uno mette il tunnel nello spazio dei nomi di rete del carico di lavoro stesso. L’altro chiede al CNI di instradare il traffico selezionato attraverso un nodo gateway designato. Falliscono in modo diverso, scalano in modo diverso e rispondono a team diversi, ed è per questo che la domanda sui container produce di solito discussioni che non si chiudono mai.
Il confine di un Pod è uno spazio dei nomi, non un jump host
Uno spazio dei nomi di rete Linux possiede le sue interfacce, indirizzi, route e regole del firewall, e ogni Pod ne riceve uno. I container dentro quel Pod vi si uniscono, ed è esattamente per questo che un container ausiliario può riscrivere route che l’applicazione poi segue. Un Pod vicino ha uno stack dall’aspetto identico ma del tutto separato. Non esiste una tabella condivisa che un Pod gateway possa ereditare, né un passaggio implicito di traffico da uno spazio dei nomi a un altro.
È anche per questo che il modello del Pod gateway funziona solo quando qualcosa a monte gli invia davvero pacchetti: un Service, una route statica sul nodo o una politica di instradamento nel CNI. Un indirizzo da solo non attira nulla.
Cosa compra un tunnel per Pod e quanto costa
Un tunnel che gira nello spazio dei nomi del carico di lavoro dà a quel carico la propria identità client, che molti servizi di accesso remoto richiedono prima di autorizzare o contabilizzare una sessione. Anche il raggio d’impatto resta locale: un tunnel rotto mette fuori uso un Deployment invece del percorso condiviso usato da tutto. Come gira dipende dall’implementazione, ed è qui che le persone indovinano male.
Una configurazione che richiede solo stato del kernel può terminare in un container init e uscire. Un demone nello spazio utente che deve restare vivo per tutta la vita del Pod ha bisogno della forma di container init riavviabile introdotta come sidecar nativo in Kubernetes 1.29, e questa distinzione viene dall’implementazione del tunnel, non dal gusto. Il costo di questo modello è la duplicazione: ogni replica si autentica, riceve il proprio indirizzo di tunnel e consuma uno slot di sessione remota, così un evento di autoscaling diventa un evento di capacità dall’altra parte del collegamento. Copiare un’unica credenziale in tutte le repliche non elimina quel costo, elimina la traccia di audit. Anche i privilegi meritano lo stesso esame, perché un tunnel che vuole NET_ADMIN nel proprio spazio dei nomi non ha motivo di ereditare l’autorità sull’intero host di un esempio con privileged: true.
Quando il CNI possiede l’uscita
Se il CNI lo supporta, un gateway di uscita seleziona il traffico per carico di lavoro e intervallo di destinazione, poi lo invia attraverso nodi scelti sotto un unico indirizzo sorgente prevedibile. La versione di Cilium è il riferimento comune, e la sua documentazione afferma chiaramente che la funzione richiede una configurazione Cilium specifica oltre a nodi gateway dotati delle interfacce e degli indirizzi corretti. Segnala anche un periodo iniziale dopo la creazione del Pod in cui l’instradamento non è ancora applicato, che è un dato di progettazione e non una nota a piè di pagina.
Leggi quel ritardo contro la tua stessa promessa. Se la regola è che nessun traffico può uscire da un’altra via, un nuovo Pod che trasmette durante la finestra l’ha già violata, quindi la sequenza di avvio ha bisogno di una risposta propria: trattenere l’applicazione finché la politica si applica, oppure accettare la finestra e documentarla.
Mantieni l’affermazione stretta. Un gateway di uscita sceglie e traduce un percorso. Non termina una VPN, e non trasforma il cluster in un client della tua rete remota senza una connessione supportata dietro.
| Question | Per-Pod tunnel | CNI egress gateway |
|---|---|---|
| Who holds the client identity | Each workload | The gateway, shared |
| What scaling changes | Enrollment and sessions per replica | Throughput and capacity per node |
| What the remote side sees | Distinct addresses | One translated source |
| Failure scope | One Deployment | Every workload behind the gateway |
La traduzione cambia in silenzio ciò che vede il lato remoto
Una volta che il gateway riscrive la sorgente, gli indirizzi per Pod spariscono, quindi una lista di autorizzati basata sull’identità diventa una lista basata su un unico indirizzo condiviso. È uno scambio e non un difetto: meno regole da mantenere, attribuzione più grossolana quando qualcosa si comporta male.
L’autenticazione a livello applicativo e il logging delle richieste devono portare ciò che la rete non riporta più. Tratta la capacità e la sostituzione del gateway come infrastruttura condivisa, perché il riavvio di un singolo nodo ora interrompe ogni carico di lavoro dietro di esso, e verifica presto il percorso di ritorno: l’estremità remota deve sapere come raggiungere l’indirizzo tradotto, di solito tramite una route o NAT che una persona, non un manifest, deve possedere. Anche la pianificazione degli indirizzi rientra qui, perché intervalli di cluster e remoti sovrapposti rompono entrambi i modelli e adottare IPv6 non scusa un piano in conflitto.
Decidi per proprietà, poi prova il guasto che hai promesso
Scegli il tunnel per Pod quando il servizio remoto autentica carichi di lavoro individuali, quando solo pochi Deployment hanno bisogno del collegamento e quando un guasto deve restare locale. Scegli il gateway quando un team di rete possiede già il percorso, quando molti carichi condividono una destinazione e quando un indirizzo sorgente stabile è tutto lo scopo dell’esercizio.
In ogni caso, verifica la proprietà che hai venduto e non lo stato stazionario. Crea un Pod, lascialo trasmettere subito e osserva i primi secondi se la promessa era che nulla sfugge al tunnel. Scala a cinque repliche e conta le sessioni che l’estremità remota riporta se la promessa era l’identità per carico di lavoro. Questi due controlli espongono i limiti del meccanismo molto più in fretta di una revisione del manifest, e ti dicono quale team possiede il prossimo incidente.