Los planos de control de Kubernetes se diseñan para contener fallos en componentes individuales, pero su disponibilidad depende en gran medida del comportamiento de esos componentes ante situaciones de presión o bajo demanda elevada. En entornos a gran escala, un componente no necesita colapsar para causar un incidente: una falla local puede amplificarse a través de metadatos compartidos, procesos sincronizados en el arranque o comprobaciones de salud demasiado estrictas.
Uno de estos mecanismos es el informer, que proporciona a un controlador una visión local del estado del clúster para que sus trabajadores puedan avanzar sin consultar repetidamente al servidor API. Esto resulta eficiente cuando los controladores arrancan de manera independiente, pero cuando muchos se reinician simultáneamente en un entorno amplio, la reconstrucción masiva de estas vistas genera una carga considerable sobre el plano de control, convirtiendo al mecanismo mismo en un amplificador del problema.
1. Fallos en servidores API de extensión tras una actualización de dependencia
Un primer caso examinado involucró un servidor API de extensión que, tras actualizar una dependencia, publicó un esquema inválido que bloqueaba a clientes sin relación con dicha extensión. En un clúster, despliegues con Helm empezaron a fallar en aplicaciones que solo contenían recursos estándar de Kubernetes, sin interacción alguna con la extensión problemática. Este error de validación se detectaba incluso antes de que las solicitudes llegaran al servidor API central, evidenciando que el fallo viajaba a través de los metadatos, específicamente de un documento esquema que combinaba definiciones de múltiples APIs agregadas. 
Kubernetes permite extender el servidor API mediante servidores agregados, que incorporan nuevas APIs sin modificar el núcleo. Para los usuarios, una API agregada se presenta como nativa y se accede vía el mismo punto final normal del clúster. Estos servidores de extensión generan un esquema OpenAPI que describe sus objetos y campos, facilitando validar solicitudes antes de que sean procesadas.
El sistema usa dos formatos de OpenAPI: v2 y v3. El formato v2 publica un único documento que combina definiciones del servidor central y las APIs agregadas, creando un dominio compartido donde un fallo en una extensión puede invalidar todo el esquema y provocar errores en clientes que intentan validar recursos no relacionados. Por el contrario, OpenAPI v3 segmenta los esquemas por grupo y versión, limitando el impacto de un fallo local.
El problema surgió cuando una servidor de extensión actualizó su dependencia sin la anotación necesaria para que el generador de nombres de modelos OpenAPI funcionara correctamente. Así, empezó a publicar nombres de modelo con rutas de paquete Go crudas y caracteres inválidos como barras («/»), invalidando el esquema. Aunque el servidor continuó funcionando y superaba sus comprobaciones de salud, los clientes que usaban OpenAPI v2 detectaban errores, afectando procesos como Helm que validaban el esquema antes de desplegar.
Para evitar estos errores, es crucial validar los esquemas expuestos en ambos formatos tras actualizaciones, asegurando que los documentos que reciben los clientes sean correctos y realizando pruebas con herramientas que validan contra OpenAPI v2 y v3.
2. Cómo un reinicio sincronizado puede convertirse en una avalancha de peticiones
Un DaemonSet despliega un pod por nodo para tareas que necesitan una visión actualizada, como monitoreo o políticas de red. Estos agentes mantienen su información usando informers que listan objetos y luego observan cambios para actualizar cachés locales.
En clústeres con miles de nodos, cada informer inicia con decenas de miles de operaciones, pero si los agentes arrancan en momentos dispersos, la carga se distribuye sin problemas. Sin embargo, si un reinicio masivo ocurre simultáneamente en muchos nodos –por ejemplo, tras una caída y reinicio forzado–, miles de agentes crean listas completas de pods al mismo tiempo, generando una tormenta de peticiones.
Uno de los factores que aumenta la carga es que, históricamente, cuando los informers hacen la consulta inicial con resourceVersion=0, el servidor API responde desde su caché de observación en memoria. Esto debería ser rápido y no implicar consultas directas a etcd, pero dicha respuesta ignoraba el parámetro limit, devolviendo la totalidad de objetos sin filtrar. Así, miles de agentes recibían decenas de miles de pods en una respuesta gigantesca que saturaba memoria y CPU del servidor API, impactando negativamente a todo el plano de control.
La comunidad de Kubernetes ha mejorado este mecanismo en versiones recientes, con estimaciones de costo corregidas y soporte para WatchList, que reemplaza la consulta tradicional. Aun así, el diseño subyacente implica que escalar informers a todo un clúster multiplica el gasto inicial.
Por ello, es recomendable limitar el ámbito de observación de los agentes al mínimo necesario: por ejemplo, usar informers que monitoricen solo pods en namespaces específicos, o utilizar metadata mínima o EndpointSlices, que suelen ser colecciones más pequeñas y eficientes que el listado completo de pods. Esto reduce la carga y evita sincronizar grandes demandas de trabajo de arranque simultáneo.
3. Comprobaciones de vida que reinician procesos innecesariamente
Las liveness probes que incluyen verificaciones exhaustivas de dependencias pueden causar ciclos perniciosos: si una dependencia externa está caída, la sonda falla, provocando reinicios repetidos del proceso mientras la dependencia sigue inaccesible. Esto agregan latencia y no solucionan el problema.
Por ejemplo, muchas arquitecturas Kubernetes usan un servicio externo de gestión de claves (KMS) para cifrar secretos. El proveedor cifrador mantiene en memoria material en caché para mitigar breves desconexiones. Sin embargo, una liveness probe que prueba en cada chequeo una operación de cifrado y descifrado real contra el KMS externo puede fallar si la red está degradada, reiniciando el proveedor en un bucle sin fin.
Este problema se agrava si el chequeo de salud del servidor API incorpora el estado del proveedor KMS. Cuando la dependencia está inaccesible, el servidor API se reemplaza continuamente, perdiendo así el material en caché y forzando la reestabilización en un contexto ya comprometido.
La solución consiste en diferenciar entre comprobar la disponibilidad de dependencias y comprobar la capacidad funcional del proceso local. La sonda de vida debe evaluar si el proceso está operativo internamente, sin reiniciarlo simplemente por fallos transitorios en dependencias que no comprometen la funcionalidad inmediata. La supervisión de dependencias debería generar alertas para operadores, pero sin provocar reinicios automáticos que empeoren la situación.
Claves para fortalecer la disponibilidad del plano de control
- Validar siempre los esquemas OpenAPI expuestos a clientes tras actualizaciones o cambios de extensión.
- Minimizar el ámbito y volumen de datos observados por informers, para evitar cargas excesivas durante arranques o recuperaciones.
- Separar la monitorización de dependencias de las sondas de liveness y readiness para evitar reinicios innecesarios.
- Probar escenarios de recuperación donde muchos componentes se reinician simultáneamente para evaluar el impacto en el plano de control.
Estos principios generales buscan que los fallos locales permanezcan aislados, que el plano de control conserve funcionalidad útil cuando una dependencia cae y que las operaciones de recuperación ordinarias no desencadenen incidentes mayores. Estas recomendaciones son especialmente relevantes para equipos que gestionan componentes compartidos a escala en plataformas Kubernetes.
