Kubernetes : comprendre les trois limites du plan de contrôle

SSacha

On a souvent tendance à résumer la taille d’une installation au nombre de machines qu’elle peut gérer. Or, d’après The New Stack, le nombre de nœuds ne suffit pas à décrire la capacité d’un plan de contrôle Kubernetes. L’article distingue trois axes indépendants : le nombre de nœuds, le rythme de création et de transition des objets, et la quantité d’état conservée en mémoire par les serveurs API. Le premier axe concerne donc la taille de la flotte. Le deuxième porte sur la fréquence à laquelle les objets sont créés ou changent d’état. Le troisième correspond aux informations que les serveurs API gardent en mémoire. Une installation peut ainsi rencontrer des contraintes différentes selon la façon dont elle utilise Kubernetes, même si le nombre de nœuds ne change pas. Autrement dit, compter les machines donne un repère utile, mais ne décrit pas à lui seul les autres pressions possibles sur le plan de contrôle.

SSacha

C’est un exemple de saturation liée au nombre de nœuds, notamment pour les flottes d’entraînement ou d’apprentissage par renforcement. Prenez une flotte de 100 000 nœuds. Chaque machine signale régulièrement au système qu’elle est toujours présente. Avec un battement de cœur toutes les 10 secondes, ces signaux génèrent environ 10 000 écritures par seconde. Dans les mesures présentées par l’article, les renouvellements de baux représentent environ 70 % du débit d’écriture. Cela donne une idée concrète de la charge : une partie importante des écritures sert à renouveler ces informations de présence. Ce n’est pas une mesure du travail d’entraînement lui-même, mais une pression exercée sur le plan de contrôle par le suivi de la flotte. Plus le nombre de nœuds augmente, plus ce mécanisme de présence mérite donc d’être pris en compte dans l’analyse de la capacité.

SSacha

L’article décrit cet axe à propos des plateformes d’agents, où la charge peut venir du renouvellement des objets plutôt que du nombre de machines. Une session d’agent peut être créée, suspendue, reprise, puis détruite, et chacune de ces transitions correspond à une écriture. Ces sessions peuvent être représentées par des ressources personnalisées de Kubernetes. Dans ce cas, des milliers de transitions par minute peuvent produire un débit d’écriture important, même si la flotte ne compte pas autant de nœuds qu’une infrastructure d’entraînement. Alors, la taille du cluster ne suffit pas à anticiper la charge : il faut aussi regarder combien d’objets changent d’état et à quel rythme. C’est une forme de saturation distincte de celle causée par les battements de cœur des nœuds. Le point important, c’est que le volume d’écritures peut dépendre du cycle de vie des agents, et pas seulement du nombre de machines qui les hébergent.

SSacha

Ajouter des serveurs API peut apporter davantage de capacité pour traiter les requêtes, mais cette option peut aggraver une contrainte de mémoire. Chaque serveur API réplique l’intégralité du cache de surveillance, qui contient une copie de l’état observé. Ajouter un serveur signifie donc aussi ajouter une nouvelle copie de ce cache en mémoire. Quand la quantité d’état conservée est déjà la contrainte principale, cette réplication accroît la mémoire consommée au lieu de réduire cette pression. Cette réponse ne convient donc pas automatiquement à toutes les saturations. Elle pourrait être utile si la capacité à traiter les requêtes est limitée, mais elle peut aggraver la situation si la mémoire est déjà le point de saturation. Il faut distinguer ces contraintes avant de choisir une action : augmenter le nombre de serveurs API ne réduit pas la quantité d’état que chacun doit conserver.

SSacha

L’article indique que des clusters de plus de 5 000 nœuds fonctionnent déjà en production avec les composants standards de Kubernetes, sans fork spécifique. Ce constat montre qu’un très grand nombre de nœuds ne nécessite pas forcément de remplacer les composants standards. Mais il ne signifie pas qu’une même configuration conviendra à toutes les installations. Le point à retenir est de distinguer les trois axes décrits : le nombre de nœuds, le rythme de création et de transition des objets, et l’état conservé en mémoire par les serveurs API. Une flotte d’entraînement peut être surtout sollicitée par les battements de cœur, tandis qu’une plateforme d’agents peut l’être par le renouvellement de ses objets. Une plateforme qui conserve beaucoup d’état peut, elle, rencontrer une contrainte de mémoire. Identifier laquelle de ces pressions est présente permet de comprendre pourquoi une réponse utile dans un cas ne l’est pas nécessairement dans un autre. Le nombre de nœuds reste un repère, mais il ne résume pas à lui seul la capacité du plan de contrôle.