Los fallos difíciles de Kubernetes rara vez son los obvios. Un fallo de proceso es visible, un readiness probe puede sacarlo de rotación y un pod de reemplazo se levanta. Los incidentes caros empiezan cuando las dependencias se degradan de forma desigual y cada capa reintenta a la vez.
Para servicios de alta concurrencia, la disponibilidad proviene de definir qué componente puede fallar, esperar, encolar o descartar trabajo. El clúster es un detalle de implementación de esas decisiones, no un sustituto de ellas.
Dibuja el límite antes que la topología
Un timeout de ingress, un backlog de workers y un failover de la base de datos primaria son dominios de fallo separados. No deberían colapsar en una sola tormenta de reintentos compartida. Coloca una cola acotada entre la admisión síncrona y el trabajo asíncrono, y haz explícito el comportamiento de recuperación del consumidor.
flowchart LR
C[Clients] --> I[Ingress]
I --> A[Stateless API]
A --> Q[(Bounded queue)]
Q --> W[Worker pool]
W --> D[(Primary datastore)]
D -. replica promotion .-> R[(Recovery path)]La cola no es solo una herramienta de throughput. Es el límite que permite que el nivel de API siga respondiendo mientras la capacidad aguas abajo es incierta.
La capacidad es una decisión de política
El autoscaling añade pods, pero no crea conexiones de base de datos, cuota de terceros ni CPU en un nodo saturado. Por lo tanto, cada servicio debe declarar un comportamiento de sobrecarga:
- Rechazar las peticiones que no puedan cumplir su contrato de latencia.
- Encolar trabajo solo mientras la cola se mantenga dentro de un límite definido de edad y profundidad.
- Degradar las dependencias opcionales antes que las rutas de transacción primarias.
- Reintentar solo trabajo idempotente con un calendario acotado y con jitter.
Estas reglas evitan que una ralentización local se convierta en un evento de amplificación en todo el clúster.
Prueba los límites aburridos
Los game days deberían incluir resolución DNS fallida, una zona parcialmente disponible, un proveedor de credenciales lento, pools de conexiones agotados y consumidores obsoletos tras un despliegue. Cada prueba debe responder una pregunta: ¿qué capa es dueña de la recuperación, y cómo se mantiene cada otra capa dentro de su presupuesto de recursos mientras esa recuperación ocurre?
Esa disciplina crea clústeres que fallan de forma legible. Es un objetivo más útil que tratar el failover como un evento excepcional que la infraestructura resolverá por sí sola.