● Silicon.fr Télécom 📅 23/04/2026 à 17:42

Cybersécurité 👤 Philippe Leroy

🏷️ Tags : cert kubernetes rte

Pour la troisième année consécutive, CAST AI publie son State of Kubernetes Optimization Report, qui mesure l’utilisation réelle des ressources CPU, mémoire et, nouveauté 2026, GPU dans les clusters Kubernetes. Les données sont issues de mesures directes réalisées sur des dizaines de milliers de clusters de production tournant sur AWS, GCP et Azure ; avant toute optimisation. Le verdict est sans appel : l’utilisation CPU est tombée à 8%, contre 10% l’année précédente. Celle de la mémoire est passée de 23% à 20%. Contrairement à ce que l’on pourrait attendre d’une technologie arrivant à maturité, les taux d’utilisation ne progressent pas mais ils régressent. Lire aussi : La SNCF, utilisatrice désormais primée de l'écosystème Kubernetes Au cœur du problème : le surprovisioning. Le taux de surprovisioning CPU a bondi de 40% à 69% en un an. Côté mémoire, il atteint 79%. Les entreprises paient donc pour des ressources que leurs applications ne demandent même pas. Un surprovisioning devenu structurel Le mécanisme est bien connu des équipes DevOps : pour éviter les ralentissements ou les crashs par manque de mémoire (OOM evictions), les développeurs ajoutent des marges de sécurité généreuses à leurs requêtes de ressources. Ce padding, invisible pour les équipes en charge des coûts, n’est jamais réexaminé après le déploiement. Les charts Helm appliquent des estimations conservatrices à l’ensemble des services, et les autoscalers de cluster répondent à ces demandes gonflées comme s’il s’agissait d’une charge réelle, en provisionnant des nœuds en conséquence. Le gaspillage devient structurel. Ce qui est contre-intuitif, c'est que cette surcapacité ne garantit pas la stabilité. Un cluster analysé par CAST AI affichait en moyenne 40 à 50 OOM kills par intervalle de mesure, malgré un padding généreux des ressources. Après déploiement d'un rightsizing automatisé, qui a également réduit les CPU provisionnés de moitié, les OOM kills sont tombés à presque zéro. Autre constat surprenant de l'édition 2026 : la taille des clusters n'a aucune influence sur le taux d'utilisation. Les petits comme les grands clusters gaspillent environ 70% de leur CPU et mémoire alloués. Il existe toutefois des nuances selon les fournisseurs cloud : les clusters AWS tendent à gaspiller légèrement moins (environ 66%), ceux sur Azure davantage (environ 72%), GCP se situant entre les deux. Mais même le meilleur résultat ( 66% de gaspillage) reste très élevé. Les GPU : un problème d'une autre dimension L'ajout des GPU dans le périmètre du rapport 2026 révèle une situation encore plus alarmante. L'utilisation moyenne des GPU s'établit à 5% sur les 23 000 clusters analysés, soit environ 20 fois moins que la capacité allouée. Lire aussi : Kubernetes : les projets CNCF les plus déployés en production Or l'économie des GPU est fondamentalement différente de celle du CPU. Un cœur CPU inactif coûte quelques centimes par heure. Un GPU inactif, lui, coûte des dollars. Et pour la première fois depuis le lancement d'EC2 en 2006, les prix des GPU augmentent. AWS a relevé les prix de ses Capacity Blocks H200 de 15% en janvier 2026, rompant une tendance de deux décennies à la baisse. Le rapport pointe également un comportement de rétention : les entreprises s'accrochent aux capacités GPU de peur de ne plus pouvoir en obtenir, alimentant une boucle inflationniste. L'adoption des instances Spot pour les charges GPU était quasiment inexistante en 2025, avec moins de 2% des GPU fonctionnant en Spot, partiellement faute de disponibilité. La situation évolue toutefois depuis début 2026 pour le matériel d'entrée de gamme : les instances T4 dans certaines régions américaines affichent désormais des taux de survie supérieurs à 90% sur une fenêtre de 30 minutes. Mais les disparités régionales sont considérables : pour AWS, eu-west-3 maintient une probabilité de survie supérieure à 0,9 sur 24 heures, tandis que eu-central-1 et us-east-1 tombent sous 0,2 dans la même fenêtre ; soit un risque d'interruption de 80% en une journée. En sélectionnant la région la plus favorable à un moment donné, les équipes pourraient obtenir des différences de coût de 2 à 5 fois sur le seul prix Spot. Impossible à monitorer manuellement en temps réel. Le partage GPU : théoriquement connu, pratiquement ignoré Le rapport illustre le potentiel du GPU sharing avec un cas concret. ALLEN Digital exploitait 7 modèles sur SageMaker ( 3 Open Source et 4 Custom ) avec des instances GPU fonctionnant en continu mais servant une charge intermittente. En migrant vers Kubernetes avec du GPU time-slicing activé, un mix 50/50 on-demand/Spot et du bin-packing de nœuds, l'entreprise a réalisé 20% d'économies immédiatement grâce au time-slicing, 30 à 40% supplémentaires en consolidant les modèles sur des instances partagées, et plus de 70% d'économies totales par rapport à SageMaker après rightsizing CPU et mémoire. Un cluster dans le jeu de données du rapport ( 136 H200 maintenant 49% d'utilisation GPU) montre que le plafond n'est pas théorique. La moyenne du parc est à 5%. L'écart est de 10x, et il est presque entièrement une question de méthode, non de matériel. Au-delà des GPU, le rapport note une tendance de fond sur l'architecture des processeurs. Depuis le deuxième trimestre 2024, l'adoption des processeurs ARM progresse à 3,5 fois le rythme des processeurs x86. Les processeurs ARM représentent désormais 9% du parc CPU total. L'automatisation, seule réponse viable ? Face à ces chiffres, CASTAI formule un diagnostic net : les inefficacités décrites dans le rapport ne sont pas nouvelles. Elles s'accumulent d'année en année. La tendance est constante : l'adoption de Kubernetes progresse, l'efficacité décline proportionnellement, et l'écart entre ce que les organisations paient et ce qu'elles consomment ne cesse de s'élargir. Cette trajectoire ne se corrige pas d'elle-même. La conclusion des auteurs est sans équivoque : les équipes qui ont réduit cet écart n'ont pas attendu une amélioration spontanée. Elles ont traité l'efficacité comme une propriété opérationnelle continue, au même titre que la disponibilité, plutôt que comme un projet ponctuel.

🔗 Lire l'article original 👁️ 1 lecture