Optimisation des coûts Kubernetes: 8 étapes, 23 outils et études de cas
Les clusters Kubernetes peuvent sembler parfaitement sains pendant que la facture grimpe. L'autoscaling est configuré, les tableaux de bord sont verts, et les dépenses augmentent quand même. Dans une enquête, 42 % des 455 ingénieurs plateforme ont cité le coût comme leur principal défi Kubernetes, tandis que 88 % ont vu le coût total de possession augmenter d'une année sur l'autre.1
Nous avons rassemblé 68 études de cas d'optimisation des coûts Kubernetes et cartographié chaque cas d'usage mentionné pour chaque fournisseur qui l'a publié :
Les cellules plus sombres signifient davantage de mentions. Les cellules vides signifient que l'outil n'a aucun cas publié pour ce cas d'usage.
Poursuivez pour un guide en 8 étapes avec des exemples réels pour réduire les dépenses de cluster et la comparaison de l'outil d'optimisation des coûts Kubernetes.
1. Mesurez avant de changer quoi que ce soit
Chaque nombre dans le reste de ce guide est un delta, et un delta a besoin d'un point de départ. Sans référence capturée avant le premier changement, il n'y a aucun moyen de savoir si l'étape 1 a fonctionné, et aucun moyen d'attribuer les économies de l'étape 3 à la consolidation plutôt qu'au dimensionnement correct qui l'a précédée. Cela importe davantage ici que dans la plupart des travaux d'ingénierie, car les six actions réduisent la même facture et leurs économies ne s'additionnent pas. Libérer de la capacité à l'étape 1 ne produit rien sur la facture jusqu'à ce que l'étape 3 supprime les nœuds.
Mesurez quatre choses :
- Les ressources demandées par rapport aux ressources utilisées en CPU et mémoire, par charge de travail. L'écart est votre backlog de l'étape 1, trié par taille.
- Coût par namespace et par charge de travail. C'est ce qui fait des quotas de l'étape 2 une négociation plutôt qu'une imposition.
- Efficacité du bin-packing, allouable par rapport au demandé par nœud. Cible de l'étape 3.
- Coût des ressources inactives par heure de la journée et jour de la semaine en non-production. Dimensionne l'étape 5 avant de la construire.
Mesurez sur au moins un cycle métier complet. Sept jours est le minimum et trente est mieux. La fenêtre n'est pas une prudence procédurale. L'étape 1 définit les demandes de mémoire au maximum observé, et un maximum observé ne vaut que ce que vaut la fenêtre qui l'a observé. Un maximum relevé sur 48 heures manque un traitement par lots hebdomadaire et provoque un OOMKill le dimanche suivant.
Outillage
- Répartition des coûts : OpenCost, le projet CNCF derrière le modèle d'allocation, est le socle gratuit. L'offre gratuit de Kubecost enveloppe le même moteur dans une interface jusqu'à 250 cœurs.
- Utilisation : Prometheus avec kube-state-metrics est le substrat. Robusta KRR le lit directement sans rien installer dans le cluster.
- Dépenses plus larges : Lorsque Kubernetes n'est qu'une partie d'une facture que la finance doit également expliquer, CloudZero, Vantage et Finout se situent au-dessus de cette couche plutôt que de la remplacer.
Les deux outils de coût attribuent par libellé, donc l'étiquetage vient en premier. Les dépenses non étiquetées sont la raison la plus courante pour laquelle une référence s'avère inutile trois semaines plus tard.
Chaque action ci-dessous indique la recommandation, la méthode, la configuration et une entreprise qui a appliqué cette étape. Chaque étude de cas et chaque statistique comporte un lien source.
2. Définissez des quotas de namespace comme garde-fous
Les économies s'amenuisent à mesure que les équipes déploient de nouvelles charges de travail sans demandes spécifiées. Un LimitRange fournit des demandes par défaut aux conteneurs qui les omettent, et une ResourceQuota plafonne ce qu'un namespace peut consommer au total.
Déployez le LimitRange avant la ResourceQuota. Une fois qu'un quota contraint une ressource, tout pod sans demande pour cette ressource est rejeté à l'admission, donc l'ordre inverse interrompt les déploiements.2
Chaque équilibreur de charge est facturé séparément par le fournisseur cloud, et les volumes orphelins continuent d'être facturés après la disparition de leurs pods.
2. Dimensionnez correctement les demandes de CPU et de mémoire
Les demandes déterminent le nombre de nœuds, et le nombre de nœuds détermine la facture. La plupart des clusters fonctionnent bien en dessous de la capacité payée, car les demandes ont été devinées une fois puis jamais revues. Une analyse de 23 000 clusters de production sur AWS, Azure et Google Cloud a révélé une utilisation moyenne du CPU de 8 %, de la mémoire de 20 % et du GPU de 5 %. 3
Définissez les demandes de CPU proches du 95 centile de l'utilisation observée. Définissez les demandes de mémoire au maximum observé plutôt qu'à un centile, et fixez la limite de mémoire égale à la demande. Un centile laisse le conteneur à court pendant le trafic restant, et comme la limite correspond à la demande, ce manque se manifeste par un OOMKill plutôt que par un ralentissement.
Omettez la limite de CPU. L'étranglement du CPU dégrade la latence sans tuer le pod, et la demande réserve déjà ce dont la charge de travail a besoin.
Le Vertical Pod Autoscaler en mode recommandation uniquement produit ces chiffres sans risque pour la production.
Lisez les recommandations avec kubectl describe vpa payments-api et comparez la valeur cible à la demande actuelle.
Étude de cas réelle : Tryg Insurance
Tryg Insurance est le plus grand assureur généraliste de la région nordique et exécute Kubernetes sur l'infrastructure Oracle Cloud. Son équipe d'ingénierie a combiné le Horizontal Pod Autoscaler et le Vertical Pod Autoscaler pour dimensionner dynamiquement les charges de travail tout en maintenant les niveaux de service, et a réduit les coûts cloud Kubernetes de 50 % en utilisant uniquement des autoscalers open source, sans plateforme d'optimisation commerciale.4
4. Consolidez les nœuds avec Karpenter et réduisez à zéro les charges de travail inactives
Le dimensionnement correct libère de la capacité, mais cette capacité repose sur des nœuds qui continuent de fonctionner jusqu'à ce que quelque chose les supprime. Karpenter provisionne des instances juste à temps et recompacte les charges de travail sur moins de nœuds. KEDA réduit à zéro les charges de travail pilotées par file d'attente, ce qu'un Horizontal Pod Autoscaler standard ne peut pas faire.
Définissez la politique de consolidation sur WhenEmptyOrUnderutilized. L'alternative, WhenEmpty, limite la perturbation aux nœuds ne contenant aucun pod de charge de travail, ce qui se produit rarement sans intervention. 5
Une liste d'instances étroite contrecarre cela, car Karpenter ne peut pas trouver de bonnes affaires aberrantes et votre résilience spot diminue. Vous devriez le laisser choisir parmi des familles d'instances entières.
Étude de cas réelle : Adidas
Adidas exécute plusieurs clusters Kubernetes sur AWS EKS. Leur équipe d'ingénierie plateforme a adopté Karpenter pour le provisionnement des nœuds, a ajouté KEDA pour la mise à l'échelle pilotée par événements, a créé automatiquement des objets Vertical Pod Autoscaler via des politiques Kyverno, et utilisé kube-downscaler pour les environnements inactifs. Ils ont réduit le coût d'exécution de leurs clusters Kubernetes sur AWS jusqu'à 50 %, en utilisant une pile entièrement open source.6
5. Préparez correctement avant de déplacer les charges de travail vers le spot
Les instances spot offrent la remise la plus élevée disponible et l'applicabilité la plus étroite. Rien ne doit être déplacé vers le spot tant que les PodDisruptionBudgets, la diversification des instances, la répartition topologique et la gestion des interruptions ne sont pas tous en place.
Un PodDisruptionBudget qui ne laisse aucune marge bloque toute perturbation volontaire, y compris la consolidation Karpenter, donc les valeurs doivent avoir du jeu. 7
Étude de cas réelle : Delivery Hero
Delivery Hero exploite 390 applications dans 43 pays, avec environ 90 % des charges de travail exécutées sur AWS EKS. Leur équipe a migré vers des instances Spot sur environ six mois, en intégrant la gestion des interruptions et un déscheduler dans le processus plutôt qu'en changeant directement de type de capacité.
- Les coûts d'infrastructure ont baissé d'environ 70 %
- Les remises spot ont atteint jusqu'à 90 % par rapport au tarif à la demande
- La plateforme absorbe des pics de trafic de 4 à 5 fois le volume normal.8
6. Éteignez la non-production selon un calendrier
Les environnements de développement et de staging supportent peu ou pas de charge la nuit et le week-end. L'arrêt planifié est techniquement simple et politiquement incontesté, ce qui en fait l'économie la plus rapide à réaliser et une première action utile là où des changements plus difficiles nécessiteront plus tard un soutien.
Appliquez le calendrier par défaut à tous les namespaces de non-production et demandez aux équipes de se désinscrire explicitement. Une politique qui exige une action pour adhérer touche moins d'équipes qu'une politique qui exige une action pour se retirer.
L'économie n'atteint la facture que si la consolidation des nœuds est déjà en cours, car les déploiements réduits laissent des nœuds vides derrière eux.
Étude de cas réelle : Bud Financial
Bud Financial enrichit les données de transactions financières pour le secteur des services financiers et exécute environ 25 clusters sur Google Kubernetes Engine. Leur équipe a utilisé la pause et la reprise planifiées pour réduire les nœuds des clusters la nuit et le week-end, parallèlement à un rééquilibrage quotidien.
- Les coûts ont baissé de 47 % rien qu'avec le changement de planification
- Le calendrier a supprimé 80 heures de fonctionnement des clusters par semaine
- L'utilisation des ressources est passée au-dessus de 90 %.9
7. Migrez les charges de travail compatibles vers ARM
Les instances basées sur ARM modifient le prix unitaire plutôt que de concurrencer la même capacité inactive que les actions ci-dessus, donc ces économies s'additionnent réellement avec le reste. Les blocages seront les dépendances sans versions ARM64.
Les utilisateurs devraient dimensionner cela par charge de travail plutôt que sur l'ensemble du parc, et construire des images multi-architectures avant de planifier quoi que ce soit.
Étude de cas réelle : Pinterest
Pinterest a migré sa charge de travail d'API web vers des instances AWS Graviton fonctionnant sur ARM64, motivé à la fois par la réduction des coûts et du carbone.
- Les coûts ont baissé de 47 %
- La consommation de calcul a baissé de 38 %
- Les émissions de carbone ont baissé de 62 %.10
8. Quand l'optimisation atteint ses limites, changez l'architecture
Les six actions ci-dessus optimisent les charges de travail dans les clusters existants. Une fois épuisées, des gains supplémentaires nécessitent un changement d'architecture plutôt qu'une optimisation supplémentaire.
Deux résultats publiés marquent la limite pratique. InCred Finance a réduit les dépenses de 30 % sur des clusters que son équipe considérait déjà optimisés11, et Yotpo a atteint 30–40 % alors qu'il exécutait déjà 80 % des charges de travail sur des instances spot12. Au-delà de cette fourchette, le gaspillage restant ne se trouve plus dans les clusters mais dans le nombre de clusters. Chacun porte une charge de plan de contrôle et forme un îlot d'ordonnancement que le bin-packing ne peut pas franchir.
La multi-location supprime ces deux coûts. Au lieu de dédier un cluster à chaque client, équipe ou environnement, des clusters virtuels s'exécutent sur une infrastructure physique partagée. Chaque locataire reçoit son propre serveur d'API et son plan de contrôle virtuel tandis que les nœuds sont mutualisés. Cela élimine la charge de plan de contrôle par cluster et permet le bin-packing sur le pool de nœuds partagé plutôt qu'au sein de domaines isolés.
yaml
bash
Deux mécanismes sont disponibles. Les namespaces sont toujours moins chers, donc le choix se fait sur la séparation exigée par les locataires, pas sur le coût.
- Les namespaces partitionnent un cluster unique et n'ajoutent aucun plan de contrôle propre. Ils suffisent lorsque les locataires se font confiance et peuvent partager un serveur d'API et un ensemble de CRDs.
- Les clusters virtuels donnent à chaque locataire son propre serveur d'API, exécuté comme une charge de travail sur l'hôte. Ce coût est justifié dans deux cas : les locataires qui ont besoin de leurs propres ressources à l'échelle du cluster, et les exigences d'isolation qu'un serveur d'API partagé ne peut pas satisfaire.
Étude de cas réelle : Atlan
Atlan est une entreprise de catalogue de données qui héberge la plateforme pour environ 95 % de ses clients, dont beaucoup dans la santé et la finance où l'isolation des données est contractuelle. Elle exploitait un cluster EKS complet par client et a dépassé 100 clusters, un parc coûteux à faire fonctionner 24 heures sur 24 et difficile à maintenir. À partir du premier trimestre 2022, elle a évalué les options de multi-location et a reconstruit sur vCluster, donnant à chaque client un cluster virtuel plutôt que physique.
- Les clusters EKS physiques sont passés de plus de 100 à 20, servant toujours 100 clients et plus
- Les dépenses Kubernetes ont baissé de 600 000 $.14
Ajouter comme source préféréeOrdre d'exécution
Les engagements arrivent en dernier, bien qu'ils soient l'action la plus facile. Les acheter avant le dimensionnement correct verrouille de un à trois ans le gaspillage que le dimensionnement allait supprimer. C'est l'erreur de séquencement la plus coûteuse qui soit, et elle est courante car elle nécessite un achat plutôt qu'un travail d'ingénierie.
L'action 7 est une branche, pas une étape. Ne l'engagez que lorsque les six premières sont terminées et que le résultat est encore insuffisant, car elle modifie le nombre de clusters exécutés plutôt que l'efficacité de chacun.
Outils d'optimisation des coûts Kubernetes
Nous avons tracé les outils avec trois études de cas publiées ou plus couvrant 47 des 68 études de cas de l'ensemble de données :
- Horizontal : combien d'études de cas chaque outil possède, comptées une seule fois chacune.
- Vertical : combien de catégories de cas d'usage distinctes ces cas couvrent, sur dix. Un outil compte une fois par catégorie quel que soit son nombre d'apparitions, donc les 12 mentions distinctes de dimensionnement correct de CAST IA contribuent 1 à son score de 10.
- Taille de la bulle : dans combien des huit étapes stratégiques l'outil apparaît.
Frameworks open source
Les frameworks open source peuvent être déployés pour les étapes de 0 à 6. Les utilisateurs assument les mises à niveau, le renouvellement des versions, la facture de rétention Prometheus et les décisions de jugement qu'un recommandeur commercial prendrait à leur place.
Chacun d'eux possède un domaine différent, c'est pourquoi plusieurs s'exécutent en même temps.
- Robusta KRR ou VPA en
updateMode: "Off"produit le backlog de l'étape 1. N'écrit rien. - Karpenter possède les nœuds : provisionnement, consolidation, sélection des instances, diversification spot, architecture. Prend en charge les étapes 3, 4 et 6.
- KEDA possède le nombre de réplicas, y compris la mise à zéro, ce que HPA seul ne peut pas faire.
- py-kube-downscaler ou kube-green possède le calendrier de non-production. Économie la moins coûteuse de la liste.
- OpenCost mesure en continu et ne participe à rien.
Plateformes commerciales
Chaque outil commercial adopte l'une des trois positions sur la couche nœud. C'est la décision, et elle importe plus que le prix ou le nombre de fonctionnalités, car le manifeste NodePool de l'étape 3 survit ou non.
- N'y touchez pas : StormForge, PerfectScale, Sedai et Kubex ne font que dimensionner les charges de travail. Ils ont besoin de Karpenter ou de Cluster Autoscaler en dessous et n'y touchent jamais. L'ajout le plus sûr à une configuration existante.
- Travaillez avec : ScaleOps ajoute le bin packing par-dessus Karpenter. nOps règle un Cluster Autoscaler ou Karpenter existant au lieu de substituer le sien. Plus de couverture, le provisionneur reste le vôtre.
- Remplacez-le : CAST IA et Spot Ocean installent leur propre provisionneur et abandonnent le manifeste. Couverture la plus large, contrôle minimal.
- Les outils de visibilité se situent à l'extérieur : OpenCost, Kubecost, CloudZero, Vantage et Finout ne font que lire, donc ils n'entrent en conflit avec rien et s'empilent librement. Exécutez-en un quel que soit le reste adopté.
Comment combiner ces outils
La facture est basée sur les nœuds en cours d'exécution, pas sur les demandes déclarées. Le dimensionnement correct réduit les demandes, ce qui libère de l'espace sur les nœuds existants mais n'en supprime aucun, donc la facture reste inchangée jusqu'à ce qu'un outil de nœud consolide cet espace. Les outils de nœud seuls échouent pour la raison inverse : ils compactent toutes les demandes qu'ils reçoivent, donc les demandes surdimensionnées sont simplement compactées plus étroitement.
Deux façons de couvrir les deux couches :
- Deux outils : VPA, StormForge ou PerfectScale pour les demandes, plus Karpenter pour les nœuds. Moins cher, et la couche nœud reste sous contrôle direct.
- Une plateforme : CAST IA, Zesty ou Spot Ocean font les deux dans un seul produit. Plus cher, et leur provisionneur remplace Karpenter.
Cinq combinaisons d'outils qui cassent des choses :
- Deux redimensionneurs à mutation sur un déploiement : VPA en
Autoaux côtés de StormForge, ScaleOps, PerfectScale ou Zesty signifie deux contrôleurs écrivant des chiffres différents dans le même champ. Un contrôleur d'admission à mutation par charge de travail. - Karpenter et Cluster Autoscaler sur un groupe de nœuds : Les deux provisionnent contre les mêmes pods non ordonnançables, donc le cluster se retrouve avec environ le double des nœuds nécessaires.
- VPA et HPA sur la même métrique : L'utilisation augmente, VPA élève la demande, l'utilisation mesurée baisse car c'est l'utilisation sur la demande, HPA supprime des réplicas, la charge par pod augmente, et ainsi de suite. Sûr lorsque HPA met à l'échelle sur quelque chose que VPA ne touche pas, comme la profondeur de file via KEDA.
- Deux outils d'engagement sur un compte payeur : Les deux achètent contre les mêmes dépenses non couvertes, verrouillant le sur-engagement pour un à trois ans.
- Deux plateformes complètes : CAST IA, Zesty et Spot Ocean installent chacun leur propre provisionneur et s'attendent chacun à le posséder.
Filtrez toutes les études de cas que nous avons rassemblées :
Pour aller plus loin
Lisez davantage pour maîtriser le placement des pods et réduire vos dépenses de calcul cloud :
- Comparez les meilleurs outils d'orchestration de conteneurs
- Comparez plus de 20 orchestrateurs cloud
- Meilleurs planificateurs de tâches cloud hybride
Citer cette recherche
Choisissez le format qui correspond à votre lieu de publication. Coller la version avec lien dans votre CMS préserve le lien retour.
@misc{simsek2026,
author = {Şimşek, Hazal},
title = {{Optimisation des coûts Kubernetes: 8 étapes, 23 outils et études de cas}},
year = {2026},
month = sep,
howpublished = {\url{https://aimultiple.com/kubernetes-cost-optimization}},
note = {AIMultiple. Consulté le 18 septembre 2026}
}Résultats et horodatages de 114 points de données. Téléchargez les données de synthèse présentées dans les graphiques et les tableaux de cet article sous forme de fichier ZIP contenant 4 fichiers CSV.
Vous voulez les données détaillées derrière ? Rejoindre Premium
Liens de référence
Soyez le premier à commenter
Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires. Les commentaires sont laissés dans leur langue d'origine.