Un sidecar de VPN necesita unha regra de arranque e unha regra de fallo

Un pod arranca o contedor do túnel antes que a aplicación e as primeiras peticións teñen éxito, que é xusto o caso que agocha o problema. A orde resolve unha carreira e non di nada do tráfico que a aplicación inicia catro horas despois, cando o túnel xa fallou. Son dúas decisións distintas. Normalmente só se deseña unha delas.

A orde só controla a primeira petición

Kubernetes admite un ciclo de vida de sidecar construído con contedores init reiniciables. Dentro dese modelo, unha sonda de arranque pode reter o seguinte paso de inicialización ata que o túnel informe de que está listo. É unha mellora real, e merece usarse a propósito en lugar de engadir un sleep a un script de entrada. A porta é tan boa como a condición que comproba.

Fóra dese modelo, a semántica de orde pertence ao runtime ou sistema de dependencias que estea a usar, e non teñen por que coincidir. Un despregamento copiado doutra plataforma pode parecer que espera o túnel porque a aplicación resulta que arranca amodo. Non é a mesma garantía, e falla baixo carga.

Diga que observa a porta: existe un proceso, existe unha interface, completouse un handshake. Cada unha desas afirmacións é máis feble que «o camiño de datos ata os destinos que necesita este pod funciona».

Impón o camiño de datos en lugar de supoñelo

Unha sonda é unha comprobación nun momento e unha devasa é unha propiedade que vale entre momentos. Se o requisito é que o tráfico da aplicación non saia nunca fóra do túnel, ten que expresarse no espazo de nomes de rede compartido como unha regra de aceptar ou descartar. A orde de arranque dos contedores non pode levar ese requisito. Só unha regra pode.

Os contedores dun mesmo pod comparten ese espazo de nomes, así que o punto de aplicación é o propio espazo de nomes. Escriba o que escriba, debe deixar dispoñible a conexión exterior do túnel, porque bloqueala para protexer a aplicación corta o camiño que a aplicación necesita.

Decida a política de fallo explicitamente: debe deterse por completo o tráfico da aplicación cando o túnel non está san, ou continuar e marcarse como non protexido? Ambas son defendibles, e ningunha é o que se obtén arrancando contedores nunha orde concreta.

Probe o tráfico que non mencionou

Faga unha petición nova durante un fallo controlado do túnel e vexa se sae. Despois repita a comprobación para os camiños que unha proba de enderezo de saída nunca toca: resolución de DNS dentro do clúster, destinos IPv6 e servizos alcanzados por enderezos internos do clúster en lugar de internet pública. Eses son os camiños que seguen funcionando en silencio despois de que o túnel morre.

Unha páxina de enderezo de saída demostra que unha petición foi onde esperaba naquel momento. Non pode inventariar os outros camiños, e a fenda entre o que probou e o que o pod pode alcanzar é onde viven os fallos interesantes.

Repita a proba despois dun reinicio do sidecar e non só despois dun arranque limpo. Un contedor de túnel reiniciado pode deixar o espazo de nomes con rutas e política nun estado intermedio.

Escriba o rexistro de despregamento

Tres feitos pertencen ás notas de despregamento: a proba de dispoñibilidade e que observa, a acción de recuperación cando esa proba falla, e a regra de aplicación que goberna a saída. A documentación dos contedores sidecar cobre a mecánica do ciclo de vida e deixa esa decisión de política nas súas mans. Esa división é correcta, e tamén é por iso que a política adoita faltar.

Unha comprobación de estado confundida cunha protección é o tipo máis caro de indicador verde, porque fai que a xente deixe de facer preguntas. Nomeala con precisión na documentación custa unha frase e evítao.

Por último, probe o camiño de recuperación unha vez coa aplicación en marcha. Un deseño que esixe recrear o pod para restaurar a saída é unha decisión, e debería ser unha que vostede tomou e non unha que descubriu.