Este es el primer postmortem del curso. No es un relato de héroes: es el registro de una prueba de carga que se salió de control y de lo que aprendí al arreglarlo.

\n

Resumen

\n

Durante un ensayo de capacidad en el clúster de homologación, subí el HPA del backend a 10 réplicas y disparé una rampa de 50 usuarios autenticados. La prueba no devolvió errores HTTP, pero la latencia p95 fue de 8,4 segundos. Minutos después, el primario de PostgreSQL perdió los probes de liveness y CloudNativePG inició un failover. El antiguo primario quedó atascado en el apagado y tuve que eliminarlo para que el clúster promoviera la réplica.

\n

No se perdió ningún dato. El servicio siguió respondiendo a través de los pods antiguos durante la mayor parte del incidente. Pero el susto fue grande — y las lecciones, valiosas.

\n

Línea de tiempo (resumida)

\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n

Hora	Evento
T+0	HPA ajustado a maxReplicas: 10; comienza la prueba de 50 VUs autenticados
T+1 min	Los workers alcanzan 92% y 82% de memoria
T+2 min	El backend escala a 10 pods; p95 sube a 8,4 s
T+3 min	Los probes de Postgres comienzan a fallar por timeout
T+5 min	CNPG inicia failover; el primario antiguo entra en shutdown
T+8 min	El primario antiguo no termina el shutdown; el clúster queda Failing over
T+10 min	Elimino el pod del primario antiguo; CNPG promueve la réplica
T+12 min	Clúster healthy; HPA reducido a 6; la latencia se normaliza

\n

Causa raíz

\n

No fue “Kubernetes”. Fue una combinación de decisiones:

\n

\n
1. HPA sin presupuesto de memoria. El límite de 10 pods se definió pensando en CPU, pero cada pod de backend usaba ~1,2–1,3 GiB. En workers de 8 GiB, 10 pods competían con la base de datos, Elasticsearch, MinIO y RabbitMQ.
\n
2. Presión de memoria en los nodos. Con un 92% de uso, el kubelet y los probes empiezan a sufrir. Postgres no fue eliminado por OOM, pero los probes de liveness/readiness comenzaron a agotar el timeout.
\n
3. Probe agresivo en una base de datos bajo carga. El liveness de CNPG usa el instance manager; bajo contención de CPU/red, el timeout de 25 s fue suficiente para marcar al primario como enfermo.
\n
4. Failover sin plan de fencing. El primario antiguo no terminó el shutdown; el clúster quedó en Failing over hasta la eliminación manual del pod.
\n

\n

Lo que funcionó

\n

\n
• CNPG promovió la réplica correctamente tan pronto como el primario antiguo salió.
\n
• El backend siguió sirviendo con los pods antiguos; no hubo caída total.
\n
• El PDB de Postgres impidió desalojos accidentales antes de tiempo (y después demostró por qué existe).
\n
• El runbook de failover se escribió a partir del incidente y quedó en el repositorio.
\n

\n

Lo que no funcionó

\n

\n
• Ajustar el HPA solo por CPU, ignorando la memoria por pod.
\n
• Ejecutar carga autenticada sin mirar kubectl top nodes cada minuto.
\n
• Probar a través del NodePort directo: el rate limit vio la IP de NAT (10.244.1.0) y generó 429, enmascarando el resultado real. A través del ingress, la misma prueba tuvo 0% de error.
\n
• Dejar el HPA al máximo durante el failover, presionando aún más los nodos.
\n

\n

Acciones tomadas

\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n

Acción	Resultado
HPA reducido a maxReplicas: 6	Estabilidad inmediata
Workers ampliados a 16 GiB	Margen para 8–10 pods con datos
Prueba rehecha a través del ingress	0% de error, p95 83,9 ms en 50 VUs
Runbook de failover CNPG	Procedimiento documentado
Plan de capacidad	HPA máximo según presupuesto de memoria, no solo CPU

\n

Lecciones

\n

\n
1. HPA es una decisión de capacidad, no un número mágico. Calcula memoria por pod × réplicas × nodos.
\n
2. PDB protege, pero no salva de la falta de recursos. Evita desalojos; no impide que el nodo se quede sin memoria.
\n
3. El probe de base de datos es sensible a la contención. Ajusta el timeout y failureThreshold con datos reales.
\n
4. El failover necesita fencing. Si el primario antiguo no muere, el clúster no promueve la réplica por sí solo.
\n
5. Prueba por el camino real. NodePort directo no representa el tráfico del ingress.
\n
6. Postmortem sin culpa. El objetivo es corregir el sistema, no a la persona que apretó el botón.
\n

\n

Checklist para tu clúster

\n

\n
• [ ] Sé cuánta memoria usa cada réplica del backend.
\n
• [ ] El HPA tiene maxReplicas compatible con la memoria de los workers.
\n
• [ ] Postgres tiene PDB y anti-affinity.
\n
• [ ] Sé qué hacer si el primario antiguo no termina el shutdown.
\n
• [ ] Pruebo la carga a través del ingress, no a través del NodePort.
\n
• [ ] Tengo runbook de failover y restore.
\n

\n

Próximo

\n

En el capítulo 05 vamos a montar el control plane en HA — y a entender por qué el etcd con quórum es la diferencia entre “alta disponibilidad” y “tres máquinas que se caen juntas”.

\n

Próximo: Curso Kubernetes 05 — HA: 3 masters, VIP y etcd