Tres cuellos de botella distintos limitan el escalado del plano de control de Kubernetes

Los desafíos de escalado en Kubernetes suelen diagnosticarse erróneamente como simples límites en el número de nodos, pero análisis recientes revelan tres modos de fallo distintos: cambio constante (churn), estado y capacidad de nodo. A medida que los clústeres superan los cinco mil nodos o gestionan cargas de trabajo intensivas de agentes, el escalado horizontal estándar de los servidores API puede agravar la presión sobre la memoria en lugar de aliviarla. Comprender estos cuellos de botella específicos permite a los equipos de infraestructura aplicar correcciones arquitectónicas dirigidas utilizando componentes estándar de la versión principal.

Qué ocurrió

Muchos equipos de ingeniería asumen que escalar el plano de control de Kubernetes es un problema lineal resuelto añadiendo más servidores API. Sin embargo, los clústeres de producción reales demuestran que este enfoque suele fracasar cuando el cuello de botella subyacente no es el volumen de solicitudes, sino la residencia en memoria o la intensidad de escritura. Por ejemplo, una flota de entrenamiento podría mantenerse estable con unos pocos miles de nodos antes de saltar a quince mil, provocando quejas de etcd y agotamiento de memoria en los servidores API. En contraste, una plataforma de agentes con solo unos pocos miles de nodos puede sufrir miles de transiciones de objetos por minuto, creando una tormenta de escrituras que abruma el plano de control independientemente del número de nodos.

Un tercer escenario involucra clústeres de plataforma con cientos de operadores y decenas de miles de objetos estáticos. Aquí, el problema no es la actividad, sino el estado: cada servidor API mantiene una copia de todos los objetos en su caché de observación (watch cache). Añadir más servidores API en este contexto replica toda la caché, aumentando el uso de memoria sin mejorar el rendimiento. Estos tres escenarios —limitados por nodos, por cambio constante y por estado— requieren soluciones diferentes, aunque la mayoría de las guías públicas se centran exclusivamente en conteos de nodos hasta cinco mil.

La falta de estrategias documentadas para clústeres más grandes o complejos lleva a los equipos a realizar cambios contraproducentes. Añadir servidores API a un clúster limitado por estado aumenta la presión sobre la memoria porque cada nueva instancia replica la caché de observación completa. La solución no reside en forks personalizados, sino en comprender las "uniones" de la arquitectura de Kubernetes, donde los componentes pueden desacoplarse y configurarse independientemente para gestionar tipos específicos de carga.

Cómo funciona

La escalabilidad de Kubernetes está limitada por cuatro "uniones" arquitectónicas, que son puntos de sustitución entre componentes. La primera unión es el almacenamiento, que determina qué backend contiene qué tipos de recursos. No todos los datos requieren la misma durabilidad; elementos efímeros como los arrendamientos (leases) de nodos y los eventos pueden desviarse del clúster etcd principal para reducir la carga de escritura. La segunda unión es la vitalidad del nodo, que gestiona cómo llegan los datos de heartbeat al plano de control. Absorbiendo las renovaciones de arrendamientos en una capa orientada al nodo o usando actualizaciones de arrendamientos en memoria en etcd, los clústeres pueden reducir drásticamente las QPS de escritura generadas por miles de kubelets.

La tercera unión es el fragmentado (sharding), que define cómo se dividen los objetos entre controladores y cachés. Si las capas no coinciden en el eje de fragmentado, los controladores desperdician recursos intentando alcanzar objetos fuera de su ámbito. La cuarta unión es la residencia en caché, que controla lo que un servidor API mantiene en memoria. Un clúster limitado por estado sufre porque cada servidor API almacena en caché cada objeto. Restringiendo el contenido de la caché solo a los objetos relevantes para un fragmento o rol específico, se puede reducir significativamente el uso de memoria, aunque cierta sobrecarga base para objetos RBAC permanece inevitable.

Detalles clave

• Los clústeres limitados por nodos están restringidos por los heartbeats de kubelet, con las renovaciones de arrendamientos representando aproximadamente el 70% de las QPS de escritura a gran escala.
• Los clústeres limitados por cambio constante enfrentan altas tasas de escritura provenientes de recursos personalizados de vida corta, como sesiones de agentes, independientemente del número de nodos.
• Los clústeres limitados por estado están constreñidos por el uso de memoria, ya que cada servidor API replica la caché de observación completa de decenas de miles de objetos.
• KEP-4743 define el límite de la interfaz de almacenamiento, permitiendo enrutar tipos de recursos a diferentes backends mediante --etcd-servers-overrides.
• KEP-5866 introduce el filtrado por rango de hash para el tráfico de API, sentando las bases para un fragmentado consistente entre controladores y cachés.
• Las configuraciones de división por roles (Role-Split) separan grupos de máquinas para servir API, planificación y etcd, habilitando el escalado hasta 20.000 nodos.

Por qué importa

Para ingenieros de software y líderes de infraestructura, reconocer el tipo específico de limitación de escala es crítico para evitar configuraciones costosas e incorrectas. Tratar una plataforma de agentes limitada por cambio constante como un problema limitado por nodos conduce a sobreaprovisionar cómputo mientras se ignora el cuello de botella de escritura en etcd. De manera similar, añadir servidores API a un clúster de plataforma limitado por estado incrementa los costos de memoria sin mejorar la latencia. Al identificar si el clúster está limitado por heartbeats de nodos, cambio de objetos o residencia de estado, los equipos pueden aplicar correcciones precisas en lugar de escalado por fuerza bruta.

Estas ideas también destacan la importancia de usar componentes estándar de la versión principal con configuración deliberada, en lugar de depender de forks no documentados. La propuesta "escalera de recetas" ofrece un camino desde configuraciones clásicas de alta disponibilidad hasta almacenes particionados y fragmentos divididos, todo probado con integración continua. Este enfoque asegura que las estrategias de escalado permanezcan válidas a través de las versiones de Kubernetes, ya que los fallos de configuración se detectan temprano en el pipeline de CI en lugar de en producción.

Qué puedes hacer

• Identifica el cuello de botella principal de tu clúster analizando las fuentes de QPS de escritura, distinguiendo entre arrendamientos de nodos, cambio de recursos personalizados y estado de objetos estáticos.
• Implementa configuraciones de división por roles para separar el servicio de API, la planificación y etcd en grupos de máquinas dedicados para clústeres de hasta 20.000 nodos.
• Usa --etcd-servers-overrides para enrutar recursos efímeros como eventos y arrendamientos a backends separados, reduciendo la carga en el clúster etcd principal.
• Evalúa capas orientadas al nodo para absorber renovaciones de arrendamientos y propagar solo transiciones de estado reales, disminuyendo la carga de escritura en el plano de control.
• Contribuye con datos reales de tasas de escritura de clústeres limitados por cambio constante a SIG API Machinery para ayudar a dar forma al futuro soporte para la configuración de almacenamiento por CRD.
• Revisa las ramas prototipo para KEP-5866 y extensiones de residencia en caché para prepararte para las próximas funciones de fragmentado y optimización de memoria.