Una dependencia catalogada como opcional provocó la caída de varios servicios en Kubernetes
Un error de arquitectura dejó que la falta de una configuración crítica bloqueara el arranque de pods, extendiendo la interrupción a servicios ajenos.
El servicio de configuración de la compañía estaba clasificado como tier 3, sin SLO ni pager, y con una única réplica. En el documento de arquitectura se describía como una dependencia blanda porque los clientes almacenan en caché sus valores y pueden seguir operando si el servicio desaparece. Esa premisa resultó falsa en el momento crítico.
A las 09:40, durante una rotación rutinaria del pool de nodos, el servicio se cayó. La rotación provocó que los pods fueran reprogramados y, al reiniciarse, cada pod perdió su caché en memoria. La biblioteca cliente intentó leer la configuración en el arranque, bloqueó durante dos minutos y finalmente abortó el proceso. Como la readiness nunca se cumplía, Kubernetes volvió a reiniciar los pods, que volvieron a bloquearse. En unos veinte minutos la rotación atravesó todo el clúster, derribando servicios que no tenían relación con la configuración y que estaban perfectamente sanos.
La lección fue clara: cualquier dependencia sin la que un proceso no pueda iniciar es una dependencia dura, sin importar el tier asignado. Además, una caché en memoria no sobrevive a eventos que la vacían. La solución implementada consistió en varios cambios: la última configuración válida se escribe en disco y se lee al iniciar; los valores por defecto se incorporan en la imagen del contenedor; el arranque ya no bloquea la obtención de la configuración, sino que arranca con lo que tiene y actualiza en segundo plano. Se añadió una métrica que indica la antigüedad de la configuración, de modo que un estado obsoleto sea visible.
El propio servicio de configuración se promocionó a tier 1, con tres réplicas y un pager activo. La práctica que surgió consiste en, cada trimestre, bloquear una dependencia a nivel de red en staging y reiniciar todo lo que afirma no necesitarla. En la primera ejecución se detectaron tres servicios adicionales que, pese a estar marcados como opcionales, no podían iniciar sin esa dependencia. El incidente muestra que los diagramas de dependencias solo son tan fiables como la validación práctica de los mismos.
Este caso subraya la necesidad de revisar continuamente los supuestos de arquitectura y de diseñar mecanismos de arranque resilientes, sobre todo en entornos Kubernetes donde la reprogramación de pods es frecuente.
