Kubernetes: prueba de fallo del 30% de nodos

Ejercicios de conmutación por fallo en Kubernetes: Apagando el 30 % de los nodos en producción

El equipo apagó el 30 % de los nodos en un clúster de producción basado en OKD para descubrir debilidades reales en la resiliencia del sistema. Este ejercicio probó cómo respondió el plano de control, los componentes de infraestructura y los servicios de aplicación ante una falla masiva en la infraestructura. Problemas con controladores de webhooks y la distribución de réplicas—previamente invisibles durante operaciones normales—se hicieron evidentes.

Arquitectura del clúster bajo prueba

El clúster opera en la nube a través de tres zonas de disponibilidad, cada una en un centro de datos diferente con menos de 1 ms de latencia entre ellas. La topología completamente interconectada simula el comportamiento de una red local.

Componentes clave:

• Balanceador de carga para tráfico de usuarios: Los backends son 3 nodos infra que ejecutan pods de Ingress y el controlador de Volúmenes Persistentes.
• Balanceador de carga API: Los backends son 3 nodos maestros que alojan el plano de control.
• Nodos trabajadores: Distribuidos uniformemente entre las zonas, N en total.

Esta configuración permite simular una falla completa de una zona sin perder cuórum del clúster—etcd puede sobrevivir a la pérdida de hasta un nodo maestro de tres.

Preparándose para el ejercicio de desastre

El plan incluyó 8 pasos:

• Verificar la salud base del clúster y sus servicios.
• Tomar instantáneas de los nodos maestros e infra para recuperación rápida.
• Desactivar todos los nodos en una zona (o 1 maestro, 1 infra + 30 % de nodos trabajadores).
• Monitorear durante 1–2 horas: registrar errores, recopilar métricas, coordinar equipos de soporte.
• Restaurar los nodos desactivados.
• Validar nuevamente el estado del clúster.
• Finalizar el ejercicio.
• Documentar acciones pendientes.

Las instantáneas son preferibles a copias de seguridad de etcd para estos ejercicios: recuperación más rápida, menor riesgo. Los nodos trabajadores no se respaldan porque su estado está en etcd. Los nodos infra se respaldan debido a los volúmenes persistentes.

El 30 % es un objetivo equilibrado: escenario realista de falla (prueba de anti-afinidad, PDBs, replicación), pero no catastrófico. El cuórum de nodos maestros sobrevive a una pérdida del 33 %.

Criterios de éxito:

• La API permanece accesible.
• Se pueden crear y eliminar pods.
• Los volúmenes persistentes siguen disponibles.
• Los servicios continúan funcionando.
• La recuperación de réplicas en 10–15 minutos.
• Las alertas se resuelven (excepto las de nodos fuera de línea).

Ejercicio #1: Clúster de desarrollo

Se desactivó 1/3: 1 maestro, 1 infra, ~80 núcleos trabajadores. El balanceador de carga eliminó los backends inactivos en menos de un minuto. La API permaneció receptiva, pero los nodos entraron en estado "Desconocido" durante 300 segundos (tiempo límite predeterminado), luego pasaron a "No listo"/"Inaccesible".

Los pods no se reiniciaron durante 10 minutos. Al crear nuevos:

Error from server (InternalError): error when creating "pod.yaml": Internal error occurred: failed calling webhook "mutate.kyverno.svc-fail": failed to call webhook: Post "https://infra-kyverno-svc.infra-kyverno.svc:443/mutate/fail?timeout=30s": dial tcp 10.128.4.174:9443: connect: connection refused

Kyverno (webhook de admisión/mutación) tenía un pod por tipo, con 2/3 ubicados en la zona desactivada—ahora en estado Terminating. Sin webhooks activos, los cambios nunca llegan a etcd. Los espacios de nombres del sistema se excluyen de Kyverno para evitar cuellos de botella.

Se aumentó el número de réplicas de Kyverno. Los eventos mostraron bloqueos en programación por escasez de recursos (implicado por el contexto, aunque no expresado directamente).

Problemas y soluciones

Kyverno: Se movió a más de 3 réplicas por tipo de webhook con dispersión topológica consciente de zonas.

Bloqueo del planificador: Se revisaron cuotas y límites de recursos en los espacios de nombres afectados.

En producción (Ejercicios #2 y #3), escenarios similares a gran escala revelaron violaciones de PDB en servicios sin anti-afinidad adecuada, además de retrasos en la migración de volúmenes persistentes.

Los equipos de aplicaciones recibieron una lista de verificación:

• Mínimo 3 réplicas.
• PodDisruptionBudget con minAvailable.
• Constraints de dispersión topológica o nodeAffinity.
• Solicitudes/límites de recursos.
• Probes de liveness/readiness con tiempos de espera razonables.

Lo que más importa

• Apagar el 30 % de los nodos expone problemas ocultos en webhooks y programación que no aparecen en condiciones normales.
• Kyverno requiere más de una réplica, distribuida uniformemente entre zonas.
• El tiempo de espera de 300 segundos para "No listo"/"Inaccesible" es estándar, pero exige recursos de reserva.
• Las instantáneas de nodos maestros e infra son esenciales para ejercicios seguros.
• Recuperación completa: 10–15 minutos para réplicas + resolución de alertas.

Recomendaciones para los equipos

Para desarrolladores de servicios:

• Configurar PDBs: minAvailable: 50%.
• Usar topologySpreadConstraints para distribución entre zonas.
• Establecer solicitudes/límites de CPU/RAM al 80 % de los picos observados.
• Probes con timeout de 5–10 segundos y 3 intentos.

Para administradores de Kubernetes:

• Asegurarse de que Kyverno y otros webhooks tengan más de 3 réplicas con alta disponibilidad.
• Monitorear elecciones de líder en etcd.
• Planificar capacidad con un margen del +30 %.
• Automatizar instantáneas antes de cada ejercicio.

Estos ejercicios son imprescindibles para cualquier clúster de producción con más de 100 nodos.

— Editorial Team