Un sidecar de VPN necesita una regla de arranque y una regla de fallo

Un pod arranca el contenedor del túnel antes que la aplicación y las primeras peticiones tienen éxito, que es justo el caso que oculta el problema. El orden resuelve una carrera y no dice nada del tráfico que la aplicación inicia cuatro horas después, cuando el túnel ya ha fallado. Son dos decisiones distintas. Normalmente solo se diseña una de ellas.

El orden solo controla la primera petición

Kubernetes admite un ciclo de vida de sidecar construido con contenedores init reiniciables. Dentro de ese modelo, una sonda de arranque puede retener el siguiente paso de inicialización hasta que el túnel informe de que está listo. Es una mejora real, y merece usarse a propósito en lugar de añadir un sleep a un script de entrada. La puerta es tan buena como la condición que comprueba.

Fuera de ese modelo, la semántica de orden pertenece al runtime o sistema de dependencias que esté usando, y no tienen por qué coincidir. Un despliegue copiado de otra plataforma puede parecer que espera al túnel porque la aplicación resulta que arranca despacio. No es la misma garantía, y falla bajo carga.

Diga qué observa la puerta: existe un proceso, existe una interfaz, se completó un handshake. Cada una de esas afirmaciones es más débil que «el camino de datos hacia los destinos que necesita este pod funciona».

Imponga el camino de datos en lugar de suponerlo

Una sonda es una comprobación en un momento y un cortafuegos es una propiedad que vale entre momentos. Si el requisito es que el tráfico de la aplicación no salga nunca fuera del túnel, tiene que expresarse en el espacio de nombres de red compartido como una regla de aceptar o descartar. El orden de arranque de los contenedores no puede portar ese requisito. Solo una regla puede.

Los contenedores de un mismo pod comparten ese espacio de nombres, así que el punto de aplicación es el propio espacio de nombres. Escriba lo que escriba, debe dejar disponible la conexión exterior del túnel, porque bloquearla para proteger la aplicación corta el camino que la aplicación necesita.

Decida la política de fallo explícitamente: ¿debe detenerse por completo el tráfico de la aplicación cuando el túnel no está sano, o continuar y marcarse como no protegido? Ambas son defendibles, y ninguna es lo que se obtiene arrancando contenedores en un orden concreto.

Pruebe el tráfico que no mencionó

Haga una petición nueva durante un fallo controlado del túnel y vea si sale. Luego repita la comprobación para los caminos que una prueba de dirección de salida nunca toca: resolución de DNS dentro del clúster, destinos IPv6 y servicios alcanzados por direcciones internas del clúster en lugar de internet pública. Esos son los caminos que siguen funcionando en silencio después de que el túnel muere.

Una página de dirección de salida demuestra que una petición fue adonde esperaba en ese momento. No puede inventariar los otros caminos, y la brecha entre lo que probó y lo que el pod puede alcanzar es donde viven los fallos interesantes.

Repita la prueba después de un reinicio del sidecar y no solo después de un arranque limpio. Un contenedor de túnel reiniciado puede dejar el espacio de nombres con rutas y política en un estado intermedio.

Escriba el registro de despliegue

Tres hechos pertenecen a las notas de despliegue: la prueba de disponibilidad y qué observa, la acción de recuperación cuando esa prueba falla, y la regla de aplicación que gobierna la salida. La documentación de contenedores sidecar cubre la mecánica del ciclo de vida y deja esa decisión de política en sus manos. Esa división es correcta, y también es por eso que la política suele faltar.

Una comprobación de estado confundida con una protección es el tipo más caro de indicador verde, porque hace que la gente deje de hacer preguntas. Nombrarla con precisión en la documentación cuesta una frase y lo evita.

Por último, pruebe el camino de recuperación una vez con la aplicación en marcha. Un diseño que exige recrear el pod para restaurar la salida es una decisión, y debería ser una que usted tomó y no una que descubrió.