Kubernetes no se escala con un solo número: tres cuellos distintos

Cuando alguien pregunta cuánto tiene que crecer el plano de control de Kubernetes, la respuesta suele llegar en forma de número de nodos. Es una métrica cómoda, pero engañosa: hay clústeres pequeños que sufren mucho más que otros diez veces mayores. La clave está en qué tipo de presión soportan. Y ahí, añadir apiservers a ciegas puede ser la peor decisión.

Tres clústeres, tres problemas que no se parecen

Imagina tres escenarios distintos. El primero es una flota de entrenamiento que llevaba meses en unos pocos miles de nodos y de golpe pasa a quince mil: el kube-apiserver empieza a consumir memoria y etcd se queja. El segundo nunca pasa de unos miles de nodos, pero sus objetos están vivos: sesiones que se crean, se suspenden, se reanudan y se destruyen miles de veces por minuto, y cada transición es una escritura. El tercero ni es grande ni es rápido: un clúster de plataforma con doscientos operadores y decenas de miles de objetos que en su mayoría no hacen nada, pero cada apiserver guarda una copia de todos ellos.

Dos de esos tres casos son cargas de IA y uno no, pero eso es lo menos relevante. Lo importante es que se están quedando sin margen en direcciones distintas, y arreglar una no hace nada por las otras. El artículo original lo resume así: el escalado no es la parte difícil, lo que falta son las instrucciones de montaje.

Las tres dimensiones del escalado

El primer eje es el límite por nodos. Flotas de entrenamiento y aprendizaje por refuerzo: grandes, homogéneas, y la presión viene de que cada kubelet reporta. Con cien mil nodos y un latido cada diez segundos, solo la comprobación de vida genera unas diez mil escrituras por segundo; en las mediciones del artículo, las renovaciones de lease suponían cerca del 70% del QPS de escritura. La mayor parte de lo que hace ese plano de control es que los nodos digan educadamente «sigo aquí», sin fin.

El segundo eje es el límite por rotación. Plataformas de agentes: tamaño modesto, día muy intenso. Los sistemas que empaquetan muchas sesiones de agente en un grupo más pequeño de pods de trabajo expresan el ciclo de vida de cada actor como un recurso personalizado, así que los objetos más ocupados y efímeros son CRDs, y la tasa de escritura no tiene nada que ver con cuántas máquinas tengas.

El tercero es el límite por estado. Clústeres de plataforma: muchos tipos, muchos objetos, la mayoría dormidos. El coste no son las escrituras, sino los bytes residentes multiplicados por cada apiserver que los guarda. Este es el eje donde el reflejo de añadir un apiserver duele de verdad.

Por qué añadir apiservers puede empeorar las cosas

Cuando el plano de control se atasca, la respuesta habitual es sumar apiservers. Es una opción documentada en kOps y lo que contestará la mayoría. Pero cada apiserver que añades replica la caché de watch completa: compras capacidad de peticiones y la pagas con memoria que no tenías. En un clúster limitado por estado, es un tiro en el pie.

El artículo propone dos conceptos útiles. Las costuras son los puntos donde puedes desmontar Kubernetes: un contrato entre dos componentes, normalmente en un límite de red, sustituible sin parchear el upstream. Como las costuras de una chaqueta: puedes ajustarla por la cintura o ensanchar los hombros y sigue siendo la misma chaqueta. Si cortas donde no hay costura, te quedas con un trapo caro. Las recetas son configuraciones probadas a escala, ejecutables, que pasan o fallan su test de escala, con CI avisando el día que dejan de ser válidas.

Las cuatro costuras que conviene conocer

1. El contrato de almacenamiento: qué almacén guarda qué tipos de recurso. Alivia la rotación. No todo el estado merece las mismas garantías de durabilidad: los eventos y los leases de nodo son efímeros, y los de elección de líder también, y ninguno necesita el mismo almacén replicado por Raft que tus Deployments. La KEP-4743 define esa frontera y --etcd-servers-overrides ya permite enrutar tipos de recurso a backends distintos. La limitación: solo conoce recursos integrados, así que una plataforma limitada por rotación no puede enrutar los CRDs que generan su tormenta de escrituras.
2. El contrato de vida del nodo: cómo llega la liveness al plano de control. Alivia el número de nodos. Dos arreglos que se componen: absorberla con una capa orientada a nodos delante del plano de control que gestione las renovaciones y propague solo transiciones reales, y abaratarla enrutando las renovaciones por la actualización de leases en memoria de etcd en lugar de un commit completo de Raft. Ese segundo cambio aterriza en etcd y ayuda a cualquier clúster, hasta al de tres nodos.
3. El eje de sharding: el campo por el que controladores, cachés y almacenes aceptan dividir. Alivia los tres ejes. La KEP-5866 introduce filtrado por rango de hash para el tráfico de API, que es la base; la coordinación, el resharding y el sharding del controller manager quedan fuera de alcance y necesitan trabajo.
4. La residencia en caché: qué guarda realmente en memoria un apiserver. Alivia el estado. Un apiserver que solo habla con el scheduler no necesita tener residentes todos los objetos, y un prototipo de dos shards reduce el heap aproximadamente a la mitad por shard. Hay un suelo: con todas las cachés desactivables apagadas, un apiserver sigue cargando unos 0,9 KB por objeto RBAC, porque los informers del autorizador los retienen igualmente.

Qué significa para una pyme y qué recomendamos

La mayoría de pymes no van a tener quince mil nodos, pero sí pueden caer en el tercer patrón sin darse cuenta: un clúster de plataforma con muchos operadores, muchos objetos y varios apiservers replicando caché. Y ahí el reflejo de escalar verticalmente o añadir réplicas encarece la factura sin resolver nada.

Nuestra recomendación práctica:

• Mide antes de tocar. Distingue si tu cuello es de nodos, de rotación o de estado. Sin esa clasificación, cualquier ajuste es una apuesta.
• Revisa qué guardas en etcd. Eventos y leases efímeros no deberían competir con el estado de negocio, si tu versión y tu distribución lo permiten.
• No añadas apiservers por inercia. En clústeres limitados por estado, cada réplica nueva es memoria que se multiplica.
• Vigila los operadores. Doscientos operadores en un clúster pequeño generan más presión de la que parece; instálalos con criterio y revisa los que ya no aportan.
• Diseña para el pico real, no para el promedio. Como contábamos en las lecciones de ingeniería para picos de tráfico, el comportamiento bajo carga extrema revela lo que el día a día esconde.

La conclusión es sencilla: Kubernetes escala, pero no con un solo número. Entender qué tipo de presión soporta tu plano de control es lo que separa una ampliación útil de una factura más alta con los mismos problemas. Si quieres revisar cómo está montado tu clúster antes de que llegue el pico, en ForgeNEX podemos ayudarte a diagnosticarlo.

Fuente: The New Stack. Análisis y adaptación: ForgeNEX.