Problema y contexto
Kubernetes v1.35 introduce restartPolicyRules para contenedores cuando la acción RestartAllContainers está habilitada. La regla puede mapear un código de salida a una acción de reinicio, mientras que el Pod mantiene un contrato de ciclo de vida y disponibilidad (readiness). Trata esta funcionalidad como una clasificación de fallos, no como un reemplazo de los probes o de las alertas.
Supongamos que un Pod de tipo worker tiene tres contenedores con diferentes dominios de fallo. El fetcher puede recuperarse de un fallo transitorio al refrescar credenciales; un error de configuración del proxy debería enviar una alerta (page) a un operador; un reporter puede necesitar que se reinicie todo el Pod cuando su estado local esté corrupto.
Qué evalúan los entrevistadores
Los entrevistadores buscan una taxonomía de fallos precisa, conocimiento de los feature gates y requisitos previos de versión, y un plan que evite que los bucles de reinicio enmascaren incidentes. Las respuestas sólidas conectan los códigos de salida con la propiedad (ownership), readiness, backoff, métricas y seguridad en el despliegue.
Una respuesta común añade restartPolicyRules a cada contenedor. Una respuesta sólida explica qué códigos representan una semántica de API estable, cuáles son detalles accidentales del proceso y cómo demostrar que un reinicio es seguro para el estado de cada contenedor.
Preguntas para aclarar primero
- ¿Qué versiones de Kubernetes y feature gates están garantizados en cada clúster?
- ¿Los códigos de salida están controlados por el contrato de la aplicación o los emite un runtime y un wrapper de shell?
- ¿El estado del contenedor es desechable, con puntos de control (checkpointed) o está acoplado a otro contenedor dentro del Pod?
- ¿Qué debería ocurrir cuando se repite el mismo código: backoff, reemplazo del Pod o escalamiento?
- ¿Qué señales definen la disponibilidad para el usuario mientras un contenedor se está reiniciando?
Si los códigos no forman parte de un contrato de aplicación probado, opta por una política de reinicio uniforme y mejora primero el contrato del proceso. Si el estado está acoplado, reiniciar un solo contenedor puede generar una interacción de split-brain con sus pares.
Una respuesta de 30 segundos
“Primero verificaría la versión de Kubernetes y el feature gate, y luego definiría la semántica de los códigos de salida en el contrato de cada contenedor. Reiniciaría únicamente fallos transitorios y sin estado; dejaría visibles los fallos permanentes de configuración; y usaría el reemplazo del Pod para estados compartidos corruptos. Instrumentaría las coincidencias de reglas, los recuentos de reinicios, el backoff, la readiness y las alertas por códigos repetidos, desplegaría la política mediante canary y la revertiría si aumentan las tasas de error o los bucles de reinicio”.
Diseño paso a paso
- Verificar requisitos previos. Confirma el comportamiento de v1.35,
RestartAllContainers, la política de admisión y si el controlador y la pila de observabilidad del clúster entienden los nuevos campos. - Definir la propiedad de los códigos de salida. Reserva un conjunto pequeño y documentado, como refresco transitorio, configuración permanente y estado irrecuperable. Prueba los wrappers para que las señales no se remapeen accidentalmente.
- Mapear la acción segura más pequeña. Reinicia un fetcher sin estado para códigos transitorios. No reinicies un proxy por una mala configuración; muéstralo como NotReady y genera una alerta. Reemplaza el Pod cuando el estado compartido sea inválido.
- Proteger dependencias. Condiciona la readiness al contrato de dependencias, coordina los hooks de apagado y evita aceptar tráfico mientras un contenedor reiniciado carezca de estado precargado (warmed state).
- Controlar la repetición. Combina recuentos de reinicios, backoff exponencial y una alerta por código repetido. Una regla que sigue reiniciando debe convertirse eventualmente en un fallo visible para el operador.
- Desplegar gradualmente. Haz canary de una carga de trabajo, compara la tasa de bucles de reinicio, el tiempo de recuperación, la tasa de error y la rotación (churn) de Pods con la política anterior, y luego expande solo cuando las salvaguardas se mantengan.
Las alternativas incluyen un supervisor dentro de un contenedor, Deployments separados para dominios de fallo independientes o un controlador que reemplace el Pod. Elige el límite más simple que preserve el estado y haga visible el fallo.
Ejemplo de respuesta
“Para el fetcher, el código de salida 42 significa un fallo transitorio al refrescar credenciales y es seguro de reiniciar porque no tiene estado local persistente. Un error de configuración permanece en NotReady y notifica al responsable; reiniciarlo solo repetiría el mismo fallo. Si el reporter detecta checkpoints locales corruptos, terminaría el Pod para que un volumen limpio o un reemplazo pueda recuperarse de forma consistente. Enviaría las reglas detrás del feature gate a un canary, alertaría sobre coincidencias repetidas y bucles de reinicio, y retiraría la política si el tiempo de recuperación o la tasa de error empeoran”.
Errores comunes
- Error: Tratar cada salida distinta de cero como transitoria → Por qué falla: los fallos permanentes se convierten en bucles de reinicio silenciosos → Solución: definir una semántica probada para los códigos de salida.
- Error: Ignorar las diferencias de versiones (skew) y feature gates entre clústeres → Por qué falla: los manifiestos se comportan de forma distinta entre entornos → Solución: añadir verificaciones de admisión y de despliegue.
- Error: Reiniciar un contenedor con estado acoplado → Por qué falla: los contenedores pares conservan un estado incompatible → Solución: reemplazar el Pod o coordinar la recuperación.
- Error: Monitorear únicamente los reinicios de contenedores → Por qué falla: los usuarios aún pueden ver errores mientras los reinicios parecen saludables → Solución: emparejar las métricas de reinicio con readiness y los SLO del servicio.
Preguntas de seguimiento y respuestas
¿Qué pasa si el código de salida 42 es emitido por un wrapper de shell y cambia tras una actualización de imagen?
Trata el código como una API. Fija la versión y prueba el wrapper, documenta la propiedad y haz fallar el despliegue cuando el contrato cambie. No heredes silenciosamente códigos específicos del runtime.
¿Cómo evitas que un bucle de reinicio oculte una interrupción?
Alerta sobre coincidencias repetidas de reglas, tasa de reinicio, saturación de backoff y pérdida de readiness. Tras un número acotado de intentos, escala a un reemplazo de Pod o a un fallo visible para el operador.
¿Cuándo es más seguro reiniciar todo el Pod?
Usa el reemplazo del Pod cuando el estado sea compartido, el orden de inicialización sea relevante o la corrupción de un contenedor pueda invalidar a sus pares. Es preferible un reinicio más amplio que una recuperación parcial inconsistente.
¿Cómo revertirías la funcionalidad?
Deshabilita la política en la plantilla de la carga de trabajo, restaura el comportamiento de reinicio anterior y verifica que las réplicas antiguas converjan. Mantén el contrato de códigos de salida y los paneles de control para que la reversión siga siendo observable.