Actualites

Administration Kubernetes : ScaleOps chasse les ressources inutilisées

La startup arrive en Europe avec une solution qui identifie combien coûtent à une entreprise toutes les ressources CPU, RAM que les développeurs allouent à leurs applications, mais qui ne sont jamais utilisées. Surtout, son logiciel permet aux informaticiens de résoudre le problème.

Yann Serra
par
Publié le: 02 avr. 2026

Remettre un peu d’administration système dans la jungle des déploiements sur Kubernetes. En pleine conquête du marché européen, l’éditeur américano-israélien ScaleOps est venu la semaine dernière sur le salon KubeCON pour présenter sa console éponyme. Elle pointe les différences entre les ressources que les développeurs réservent sur des clusters pour exécuter leurs applications et les quantités de puissance processeur, capacité mémoire ou stockage que ces applications utilisent réellement.

Les frises chronologiques de la console ScaleOps chiffrent le nombre d’euros qui partent ainsi en fumée chaque seconde, à cause d’un gâchis dont les entreprises n’ont qu’une vague idée. Heureusement, ses boutons permettent d’éteindre l’incendie en un tournemain.

« Le problème, aujourd’hui sous Kubernetes, est que l’on demande aux développeurs de renseigner des caractéristiques techniques qui ne relèvent pas de leurs compétences. Et forcément, ils font cela en s’efforçant de voir large, pour ne pas que leur code soit mis en difficulté », raconte Nicolas Vermandé, responsable chez ScaleOps des relations avec les développeurs (en photo en haut de cet article).

« À leur décharge, il faut comprendre que leurs applications vont évoluer au fil du temps, alors que les caractéristiques se définissent une bonne fois pour toutes et que personne ne pense ensuite à les réviser », ajoute-t-il.

Sur l’écran qu’il montre, ScaleOps monitore de façon continue les traitements en cours sur un cluster Kubernetes. Celui-ci peut tout aussi bien être un service en cloud que fonctionner sur des machines locales. En cloud public, la solution fait automatiquement le lien avec les tarifs que l’entreprise cliente a contractualisé avec son hyperscaler. Sur des serveurs privés, le service informatique devra passer un peu de temps sur la calculatrice de l’interface pour déterminer le coût horaire des ressources.

ScaleOps fonctionne depuis le cluster qu’il monitore ; on l’y installe avec une simple commande helm. Le fait qu’il puisse par conséquent se surveiller lui-même tend à démontrer la transparence de la solution.

Modifier les paramètres d’exécution dans la mémoire de l’orchestrateur

La lecture des coûts est juste une première approche, qui permet déjà de cartographier quel container consomme trop à quel endroit. La consommation est exprimée en millicores : un cœur de processeur vaut 1000, un pod réserve 3000 millicores, ScaleOps se rend compte qu’il n’en utilise que 1010. Par exemple. En sus, cette visualisation est illustrée de commentaires qui indiquent au développeur ce qu’il devrait plutôt faire. ScaleOps oriente ses recommandations selon les profils applicatifs qu’il reconnaît.

Mais le logiciel prend tout son intérêt quand il permet à un informaticien – ou un « ingénieur plateforme » - de rationaliser le fonctionnement du cluster.

Tout d’abord, ScaleOps se connecte aux informations primitives de Kubernetes, ce qui lui permet de contrôler comment l’orchestrateur attribue des ressources à un pod de containers (alias le Vertical Pod Autoscalling) et sous quelles conditions il décide de répliquer un pod pour correspondre à la charge de son activité.

« La première chose que notre logiciel va faire, c’est créer une sorte de puits de gravité qui va consolider les containers les uns contre les autres sur un noyau de nœuds, de sorte à libérer les nœuds autour et ainsi réduire la taille du cluster », raconte Nicolas Vermandé. En cloud, l’entreprise consomme moins. Sur site, elle peut éteindre des serveurs et retarder ainsi le moment où elle aura l’impression qu’il faut en racheter d’autres pour augmenter la capacité.

Vient ensuite le différentiel de millicores entre les caractéristiques demandées par le développeur et celles que ScaleOps recommande. On passe des premières aux secondes en appuyant sur un seul bouton : « Automate ». Avec ce clic, le logiciel reconfigure dans Kubernetes les ressources nécessaires à une application en se basant sur la moyenne de celles qu’elle a utilisées depuis qu’on la surveille. Nicolas Vermandé précise que ScaleOps ne modifie pas la déclaration du développeur, il change juste les paramètres que l’orchestrateur a en mémoire et il les changera à nouveau quand le même pod sera redéployé.

Cependant, ce n’est pas forcément la meilleure approche. « Si vous regardez l’historique de chaque traitement dans le détail, vous vous rendez compte que certains alternent entre des pics d’activité et des périodes de sous-régime. Dans ces situations, reconfigurer une bonne fois pour toutes les caractéristiques n’est pas optimal. Il existe un mode temps réel qui réajuste les ressources au fur et à mesure qu’une tâche les utilise », dit le responsable. Ce réajustement se fait avec une commande appelée in-Place Resize et qui est arrivée avec la version 1.35 de Kubernetes. Celle publiée en décembre dernier.

Pour autant, ce mode temps réel est à manier avec précaution. Plus efficace pour les économies, il rend les charges de travail par nœud moins prédictives. « Le problème est que vous pouvez vous retrouver à un moment donné avec un pod qui demande de la puissance qui n’est plus disponible sur son nœud hôte, ce qui signifie qu’il faut le redémarrer sur un autre nœud où il y a suffisamment de ressources », détaille Nicolas Vermandé en assurant que ScaleOps s’efforce de minimiser les contraintes.

Prise en charge de Java et des GPU Nvidia

ScaleOps utilise sa propre base de données pour stocker les métriques historiques et le contexte applicatif qui leur donne du sens. Mais cette base peut contenir bien d’autres éléments. L’éditeur compte par exemple s’en servir pour ajouter à l’avenir des fonctions de dépannage.

En attendant, la toute dernière version du logiciel dévoilée lors de KubeCON présentait deux nouveautés. La première est la prise en charge de Java.

« Dans un container, Kubernetes ne sait pas discerner le temps de calcul qui est consommé par le code de l’application de celui que consomme la JVM, soit le moteur du langage Java dans lequel est écrite cette application. C’est dommage, car les JVM exécutent les mêmes opérations de routine dans tous les containers, et il y a donc matière à optimisation. Dans notre nouvelle version, nous avons donc apporté un connecteur qui permet à ScaleOps de s’intégrer à Java. Typiquement, il s’agit d’aligner au même moment les mêmes opérations », décrit Nicolas Vermandé.

L’autre nouveauté est la capacité de fractionner la puissance d’un GPU pour qu’il puisse être utilisé par plusieurs containers. « D’ordinaire, ce n’est possible que si vous payez une licence à Nvidia pour faire du MIG ou du Time-slicing », assure notre interlocuteur.

Le MIG (Multi-Instance GPU) subdivise le GPU en partitions matérielles de puissances égales, ce qui n’est pas optimal. Le Time-Slicing réattribue tout le GPU à tour de rôle aux containers. Le nouveau plug-in de ScaleOps est capable de découper le GPU en partitions logiques de tailles variables. Pour calculer la taille dont chaque container a besoin, ScaleOps se connecte à dgcm-exporter, le système de télémétrie intégré aux pilotes de Nvidia.

Pour approfondir sur Kubernetes