El artículo detalla cómo los clústeres de Kubernetes pueden saturarse en tres dimensiones distintas: 'node-bound' (por número de nodos y latidos), 'churn-bound' (por alta tasa de escrituras de objetos, especialmente CRDs) y 'state-bound' (por gran cantidad de objetos estáticos en memoria).
La causa raíz de estos incidentes es la falta de una arquitectura de control plane de Kubernetes que sea intrínsecamente elástica y adaptable a estas diferentes cargas. Las configuraciones por defecto y las recomendaciones comunes (como añadir más apiservers) a menudo abordan solo una dimensión de escalabilidad (ej. capacidad de request) y pueden empeorar otras (ej. consumo de memoria del watch cache).
Las salvaguardas existentes fallan porque la monitorización y las guías de escalado se centran predominantemente en el número de nodos, ignorando las presiones de churn y estado. Esto lleva a una sintonización incorrecta del clúster, donde los recursos se añaden en el lugar equivocado o de una manera contraproducente. La replicación completa del watch cache en cada apiserver es un punto crítico de fallo para los clústeres 'state-bound', mientras que la gestión de leases de nodos y CRDs efímeros sobre etcd es un cuello de botella para los clústeres 'node-bound' y 'churn-bound' respectivamente.
La solución propuesta se basa en identificar 'seams' (puntos de extensión arquitectónicos) y desarrollar 'recipes' (configuraciones validadas) que permitan a los operadores de Kubernetes adaptar el control plane a su patrón de carga específico, en lugar de aplicar una solución única para todos. Esto implica desacoplar el almacenamiento de diferentes tipos de recursos, optimizar la gestión de latidos de nodos, introducir sharding y controlar la residencia de caché en los apiservers.