Un sidecar VPN ha bisogno di una regola di avvio e di una regola di guasto

Un pod avvia il contenitore del tunnel prima dell'applicazione e le prime richieste riescono, ed è esattamente il caso che nasconde il problema. L'ordine risolve una corsa e non dice nulla sul traffico che l'applicazione avvia quattro ore dopo, quando il tunnel si è guastato. Sono due decisioni separate. Di solito se ne progetta una sola.

L'ordine blocca solo la prima richiesta

Kubernetes supporta un ciclo di vita del sidecar costruito con contenitori init riavviabili. In quel modello, una sonda di avvio può trattenere il passo di inizializzazione successivo finché il tunnel non segnala la prontezza. È un miglioramento reale, e vale la pena usarlo deliberatamente invece di aggiungere uno sleep a uno script di entrypoint. La barriera vale solo quanto la condizione che verifica.

Fuori da quel modello, la semantica dell'ordine appartiene al runtime o al sistema di dipendenze che si sta usando, e non devono coincidere. Un deployment copiato da un'altra piattaforma può sembrare in attesa del tunnel perché l'applicazione per caso si avvia lentamente. Non è la stessa garanzia, e fallisce sotto carico.

Dite cosa osserva la barriera: esiste un processo, esiste un'interfaccia, un handshake è stato completato. Ognuna di queste affermazioni è più debole di «il percorso dati verso le destinazioni di cui questo pod ha bisogno funziona».

Imponete il percorso dati invece di darlo per scontato

Una sonda è un controllo in un determinato momento e un firewall è una proprietà che vale tra un momento e l'altro. Se il requisito è che il traffico dell'applicazione non esca mai fuori dal tunnel, deve essere espresso nello spazio dei nomi di rete condiviso come regola di accettare o scartare. L'ordine di avvio dei contenitori non può portare quel requisito. Solo una regola può farlo.

I contenitori di uno stesso pod condividono quello spazio dei nomi, quindi il punto di applicazione è lo spazio dei nomi stesso. Qualunque cosa scriviate, deve lasciare disponibile la connessione esterna del tunnel, perché bloccarla per proteggere l'applicazione taglia il percorso di cui l'applicazione ha bisogno.

Decidete esplicitamente la politica di guasto: il traffico dell'applicazione deve fermarsi del tutto quando il tunnel non è sano, o continuare ed essere contrassegnato come non protetto? Entrambe sono difendibili, e nessuna delle due è ciò che si ottiene avviando i contenitori in un ordine particolare.

Provate il traffico che non avete menzionato

Fate una nuova richiesta durante un guasto controllato del tunnel e verificate se esce. Poi ripetete il controllo per i percorsi che un test dell'indirizzo di uscita non tocca mai: risoluzione DNS all'interno del cluster, destinazioni IPv6 e servizi raggiunti tramite indirizzi interni al cluster invece che tramite internet pubblico. Sono questi i percorsi che continuano silenziosamente a funzionare dopo che il tunnel muore.

Una pagina dell'indirizzo di uscita dimostra che una richiesta è andata dove vi aspettavate in quel momento. Non può inventariare gli altri percorsi, e il divario tra ciò che avete testato e ciò che il pod può raggiungere è dove vivono i guasti interessanti.

Ripetete il test dopo un riavvio del sidecar, non solo dopo un avvio pulito. Un contenitore del tunnel riavviato può lasciare lo spazio dei nomi con rotte e politica in uno stato intermedio.

Scrivete la registrazione del deployment

Tre fatti appartengono alle note di deployment: il test di prontezza e ciò che osserva, l'azione di ripristino quando quel test fallisce, e la regola di applicazione che governa l'egress. La documentazione dei contenitori sidecar copre la meccanica del ciclo di vita e lascia a voi quella decisione di politica. Questa divisione è corretta, ed è anche il motivo per cui la politica di solito manca.

Un controllo di salute scambiato per una protezione è il tipo più costoso di indicatore verde, perché impedisce alle persone di fare domande. Nominarlo con precisione nella documentazione costa una frase e lo evita.

Infine, provate il percorso di ripristino una volta con l'applicazione in esecuzione. Un progetto che richiede di ricreare il pod per ripristinare l'egress è una decisione, e dovrebbe essere una che avete preso voi, non una che avete scoperto.