Para entender cómo y por qué un plano de control de Kubernetes se queda sin recursos, es esencial distinguir entre tres tipos de escalabilidad, que surgen de casos de uso muy distintos y cuellos de botella propios.
El primer caso corresponde a un conjunto de entrenamiento para inteligencia artificial, que mantuvo unos pocos miles de nodos durante meses, y de repente aumentó a quince mil nodos debido a una nueva tarea. En esta situación, el servicio kube-apiserver comienza a consumir excesiva memoria, mientras que etcd muestra mensajes de saturación.
El segundo ejemplo es una plataforma de agentes que nunca pasa de unos pocos miles de nodos y enfrenta una enorme presión día a día. Esta plataforma maneja miles de sesiones que se crean, suspenden, reanudan y destruyen a un ritmo frenético, lo que implica constantes escrituras en el plano de control con una tasa inmanejable. 
Finalmente, el tercer caso se trata de un clúster de plataforma con apenas algunos cientos de operadores instalados pero con decenas de miles de objetos almacenados, mayormente inactivos. No obstante, cada instancia del apiserver mantiene una copia completa de todos estos objetos, aumentando el consumo de recursos innecesariamente.
Estos ejemplos revelan tres direcciones distintas en las que un plano de control se encuentra limitado: por número de nodos, por la rapidez y volumen de operaciones que realizan los agentes (alta tasa de cambios o churn), y por el volumen y cantidad de objetos almacenados que deben residir en memoria.
Más allá del conteo de nodos: los verdaderos límites de escalabilidad
La mayoría de las guías y recomendaciones en la comunidad se centran en escalar hasta 5.000 nodos. Sin embargo, cuando se intenta ir más allá o se enfrentan situaciones que escapan a esta métrica estándar, la falta de orientación es evidente.
Intentar resolver los problemas de escalabilidad añadiendo más instancias del apiserver es una solución común pero contraproducente: cada nuevo apiserver replica toda la caché de objetos, exacerbando el consumo de memoria sin resolver el problema de fondo.
En realidad, grandes clústeres de más de 5.000 nodos operan exitosamente en producción empleando exclusivamente componentes estándar de Kubernetes, pero lo logran mediante una gestión consciente de qué datos y recursos almacena cada parte del sistema.
Las tres formas de escala
El error común es asumir que la escala del plano de control está determinada únicamente por el número de nodos. Esta visión simplista lleva a que las configuraciones se ajusten para problemas que realmente no existen en el entorno particular de cada clúster.
Escalabilidad ligada a nodos: Aquí la principal carga son los mensajes de «latido» (heartbeats) enviados por cada kubelet. A gran escala, por ejemplo 100.000 nodos enviando latidos cada 10 segundos, se generan cerca de 10.000 escrituras por segundo solo para mantener la vida del nodo en el sistema.
Escalabilidad ligada a la rotación o churn: Plataformas donde el número de nodos es moderado pero las operaciones o sesiones cambian rápidamente, lo que provoca altas tasas de escritura por segundo. Aquí el problema no es cuántos nodos hay, sino cuántas operaciones intensas maneja cada uno.
Escalabilidad ligada al estado: En clústeres con muchos tipos y objetos almacenados, la limitación está en la cantidad de datos que debe mantener cada apiserver en memoria, pues cada uno replica toda esa información, independientemente del ritmo de cambios.
Estos tres tipos de escalabilidad son independientes, y una receta basada solo en el conteo de nodos puede llevar a optimizaciones ineficaces o erróneas.
Los ‘seams’ y las recetas para escalar
En arquitectura de software, los «seams» son las fronteras o puntos de interfaz entre componentes que se pueden modificar o reemplazar sin romper el sistema. En Kubernetes, identificar y aprovechar estos «seams» es clave para escalar de manera eficiente.
Las «recetas» son combinaciones de configuraciones probadas que escalan bien, validadas mediante pruebas continuas, y que ayudan a aplicar soluciones según el tipo específico de escalabilidad requerida.
Los cuatro seams fundamentales
- Contrato de almacenamiento: Define qué tipos de recursos se almacenan en cada backend. Por ejemplo, los nodos y eventos son efímeros y no requieren la misma durabilidad que despliegues o configuraciones.
- Contrato de latencia de nodos: Gestiona cómo los nodos reportan su estado de «vivo». Soluciones incluyen introducir una capa intermediaria que filtre y reduzca estas señales para aligerar el plano de control.
- Eje de particionamiento (sharding): Define cómo se dividen objetos y responsabilidades entre controladores y caches para distribuir la carga y evitar cuellos de botella.
- Residencia en caché: Controla qué datos mantiene en memoria cada instancia del apiserver, evitando replicar toda la información cuando solo se requiere una parte específica.
Mientras algunos de estos seams ya han sido identificados y tienen cierto soporte en Kubernetes, otros aún están en desarrollo o revisión, ofreciendo un gran campo para mejora y contribución.
Escalando de manera gradual: la escalera de recetas
La progresión habitual para escalar un plano de control consiste en varias etapas, desde configuraciones clásicas de alta disponibilidad hasta arquitecturas segmentadas y particionadas:
- Classic HA: Hasta 5.000 nodos, con varias réplicas idénticas del plano de control.
- Role-Split: Entre 5.000 y 20.000 nodos, donde se separan componentes del plano de control en pools independientes.
- Node Plane: Hasta 65.000 nodos, adicionando una capa orientada a manejar latidos y renovaciones de nodos.
- Partitioned Store: Cercano a 100.000 nodos, con distribución de tipos de recursos entre almacenes independientes.
- Sharded Slice: Más allá de este punto, con unidades shard independientes que combinan controlador y apiserver por segmentación. Esta etapa aún no existe plenamente en producción.
Sin embargo, estas recetas están principalmente basadas en el número de nodos; faltan configuraciones probadamente eficientes para escalabilidad basada en churn o volumen de estado, lo que refleja una brecha significativa en la comunidad.
Iniciativas y oportunidades para avanzar
Para abordar esta problemática, la comunidad Kubernetes está promoviendo:
- Configuraciones de almacenamiento específicas por CRD para gestionar el churn con mayor precisión.
- El desarrollo y revisión de KEPs (Kubernetes Enhancement Proposals) que introducen mejoras en filtrado de tráfico por hash y gestión de cachés residenciales.
- El aporte y publicación de recetas para clústeres con altas tasas de churn o con grandes volumenes de estado, aspectos menos explorados hasta ahora.
Eventos como KubeCon + CloudNativeCon en Salt Lake City continúan siendo puntos claves para compartir experiencias, identificar problemas reales y colaborar en estos retos técnicos.
Así, mientras las plataformas de entrenamiento, las plataformas de agentes y los clústeres de plataforma enfrentan desafíos distintos para escalar, la solución pasa por combinar componentes estándar con configuraciones inteligentes que exploten al máximo los «seams» del sistema.
