Les d\u00e9cisions relatives \u00e0 l'orchestration des conteneurs ont une incidence directe sur les d\u00e9penses li\u00e9es au cloud, car elles d\u00e9terminent la mani\u00e8re dont les ressources de calcul sont provisionn\u00e9es, mises \u00e0 l'\u00e9chelle et r\u00e9parties au sein de votre infrastructure. Les choix concernant la configuration de la mise \u00e0 l'\u00e9chelle automatique, l'architecture des clusters et le recours \u00e0 un Kubernetes g\u00e9r\u00e9 ou autog\u00e9r\u00e9 peuvent faire varier votre facture mensuelle de cloud de plusieurs dizaines de milliers de dollars. Les sections ci-dessous d\u00e9taillent les d\u00e9cisions sp\u00e9cifiques qui entra\u00eenent les plus grandes diff\u00e9rences de co\u00fbts et expliquent ce que les \u00e9quipes financi\u00e8res informatiques peuvent faire pour y rem\u00e9dier.<\/p>\n
Les choix en mati\u00e8re d'orchestration des conteneurs qui entra\u00eenent les hausses de co\u00fbts les plus importantes sont le dimensionnement des n\u0153uds et les seuils d'auto-scaling, la prolif\u00e9ration des clusters, ainsi que le recours \u00e0 des instances \u00e0 la demande plut\u00f4t qu'\u00e0 des instances spot ou pr\u00e9emptibles. Chacun de ces choix a un effet cumulatif au fil du temps, car les conteneurs fonctionnent en continu ; ainsi, m\u00eame de l\u00e9g\u00e8res inefficacit\u00e9s dans la configuration des ressources se traduisent par des frais mensuels importants.<\/p>\n
Le surprovisionnement est la cause la plus courante. Lorsque les \u00e9quipes configurent les demandes et les limites de ressources de mani\u00e8re trop g\u00e9n\u00e9reuse, les n\u0153uds fonctionnent \u00e0 faible taux d\u2019utilisation alors que vous payez pour la capacit\u00e9 totale. Un cluster dont les n\u0153uds affichent une utilisation moyenne du processeur de 30% gaspille en r\u00e9alit\u00e9 70% de ses d\u00e9penses informatiques. Multipliez ce chiffre par les dizaines de pools de n\u0153uds d\u2019un grand environnement d\u2019entreprise, et l\u2019impact financier devient consid\u00e9rable.<\/p>\n
Au-del\u00e0 du surprovisionnement, les d\u00e9cisions d'orchestration suivantes sont syst\u00e9matiquement \u00e0 l'origine des hausses de co\u00fbts les plus importantes :<\/p>\n
La mise \u00e0 l'\u00e9chelle automatique de Kubernetes peut r\u00e9duire consid\u00e9rablement les factures mensuelles li\u00e9es au cloud lorsqu'elle est correctement configur\u00e9e, mais elle peut \u00e9galement augmenter les co\u00fbts en cas de mauvaise configuration. L'Horizontal Pod Autoscaler (HPA), le Vertical Pod Autoscaler (VPA) et le Cluster Autoscaler ont chacun une incidence diff\u00e9rente sur les d\u00e9penses, et leur interaction d\u00e9termine si la mise \u00e0 l'\u00e9chelle de votre cluster est efficace ou source de gaspillage.<\/p>\n
Le Cluster Autoscaler ajoute et supprime des n\u0153uds en fonction de la demande de pods en attente. Lorsque les seuils d'augmentation de capacit\u00e9 sont d\u00e9finis de mani\u00e8re trop agressive, de nouveaux n\u0153uds sont provisionn\u00e9s avant que la capacit\u00e9 existante ne soit pleinement exploit\u00e9e. Lorsque les seuils de r\u00e9duction de capacit\u00e9 sont trop prudents, des n\u0153uds inactifs persistent longtemps apr\u00e8s que la demande a baiss\u00e9. Ces deux comportements font grimper votre facture.<\/p>\n
Le HPA adapte le nombre de r\u00e9pliques de pods en fonction d'indicateurs tels que l'utilisation du processeur ou des m\u00e9triques sp\u00e9cifiques \u00e0 l'application. Si votre indicateur de mise \u00e0 l'\u00e9chelle ne refl\u00e8te pas fid\u00e8lement la charge r\u00e9elle, le HPA peut maintenir un nombre de r\u00e9pliques sup\u00e9rieur au n\u00e9cessaire. Les \u00e9quipes qui s'appuient uniquement sur le CPU comme indicateur de mise \u00e0 l'\u00e9chelle constatent souvent que les charges de travail limit\u00e9es par la m\u00e9moire ou par les E\/S restent sur-r\u00e9pliqu\u00e9es, car le CPU n'atteint jamais le seuil de d\u00e9clenchement.<\/p>\n
Le Cluster Autoscaler fonctionne de mani\u00e8re plus rentable lorsqu\u2019il est associ\u00e9 \u00e0 des demandes de ressources de pods pr\u00e9cises. Si ces demandes sont sur\u00e9valu\u00e9es, l\u2019Autoscaler consid\u00e8re que les n\u0153uds sont satur\u00e9s avant qu\u2019ils ne le soient r\u00e9ellement, ce qui d\u00e9clenche inutilement la mise \u00e0 disposition de nouveaux n\u0153uds. Des demandes de ressources pr\u00e9cises ne constituent donc pas seulement un enjeu de performance, mais aussi un levier direct pour l\u2019optimisation des co\u00fbts du cloud.<\/p>\n
Les services Kubernetes g\u00e9r\u00e9s, tels qu\u2019Amazon EKS, Azure AKS et Google GKE, transf\u00e8rent la charge op\u00e9rationnelle li\u00e9e \u00e0 l\u2019exploitation du plan de contr\u00f4le au fournisseur de cloud, mais ils entra\u00eenent des frais de gestion par cluster et peuvent limiter la flexibilit\u00e9 en mati\u00e8re d\u2019optimisation des co\u00fbts. Kubernetes en autogestion vous offre un contr\u00f4le total, mais n\u00e9cessite du temps d\u2019ing\u00e9nierie d\u00e9di\u00e9, ce qui engendre un co\u00fbt sp\u00e9cifique souvent n\u00e9glig\u00e9.<\/p>\n
Pour la plupart des grandes entreprises, le Kubernetes g\u00e9r\u00e9 permet de r\u00e9duire le co\u00fbt total de possession malgr\u00e9 les frais de gestion, car le gain de temps en ing\u00e9nierie r\u00e9alis\u00e9 sur la maintenance du plan de contr\u00f4le, les mises \u00e0 niveau et l\u2019application des correctifs de s\u00e9curit\u00e9 l\u2019emporte sur les frais suppl\u00e9mentaires. Le seuil de rentabilit\u00e9 d\u00e9pend du niveau d\u2019expertise de votre \u00e9quipe en mati\u00e8re de Kubernetes et du nombre de clusters que vous exploitez.<\/p>\n
La diff\u00e9rence de co\u00fbt la plus significative entre ces deux approches r\u00e9side dans la gestion des n\u0153uds. Les services g\u00e9r\u00e9s s\u2019int\u00e8grent g\u00e9n\u00e9ralement de mani\u00e8re \u00e9troite aux fonctionnalit\u00e9s de mise \u00e0 l\u2019\u00e9chelle automatique et d\u2019instances spot propres au cloud, ce qui facilite la r\u00e9duction des d\u00e9penses informatiques sans avoir recours \u00e0 des outils personnalis\u00e9s. Les clusters autog\u00e9r\u00e9s vous obligent \u00e0 mettre en place et \u00e0 maintenir vous-m\u00eame ces int\u00e9grations, et les lacunes dans cette automatisation se traduisent directement par des d\u00e9penses li\u00e9es aux ressources inutilis\u00e9es.<\/p>\n
Les architectures multi-clusters entra\u00eenent une augmentation des d\u00e9penses li\u00e9es au cloud, principalement parce que chaque cluster n\u00e9cessite son propre plan de contr\u00f4le, des charges de travail syst\u00e8me d\u00e9di\u00e9es et une capacit\u00e9 minimale en n\u0153uds pour rester op\u00e9rationnel. Ces co\u00fbts de base se multiplient \u00e0 chaque cluster suppl\u00e9mentaire, quelle que soit la charge de travail applicative effectivement ex\u00e9cut\u00e9e par ce cluster.<\/p>\n
Au-del\u00e0 des co\u00fbts de r\u00e9f\u00e9rence par cluster, les environnements multi-clusters g\u00e9n\u00e8rent plusieurs pressions financi\u00e8res qui s'additionnent :<\/p>\n
Les strat\u00e9gies multi-clusters sont souvent justifi\u00e9es par des exigences en mati\u00e8re d'isolation, de conformit\u00e9 ou de r\u00e9silience. La question financi\u00e8re est de savoir si ces exigences n\u00e9cessitent r\u00e9ellement des clusters distincts ou si l'isolation des espaces de noms, les politiques r\u00e9seau et les contr\u00f4les d'acc\u00e8s bas\u00e9s sur les r\u00f4les au sein d'un cluster partag\u00e9 permettraient d'obtenir le m\u00eame r\u00e9sultat \u00e0 moindre co\u00fbt.<\/p>\n
Les \u00e9quipes financi\u00e8res informatiques peuvent imputer les co\u00fbts li\u00e9s aux conteneurs aux unit\u00e9s op\u00e9rationnelles en combinant l'\u00e9tiquetage des espaces de noms Kubernetes, le marquage des ressources au niveau du fournisseur de cloud et un mod\u00e8le d'imputation des co\u00fbts qui convertit la consommation brute de ressources en co\u00fbts au niveau des services. En l'absence d'une strat\u00e9gie d'\u00e9tiquetage structur\u00e9e, les co\u00fbts li\u00e9s aux conteneurs apparaissent comme un poste unique et indiff\u00e9renci\u00e9 qui ne peut \u00eatre attribu\u00e9 \u00e0 aucune \u00e9quipe ni \u00e0 aucun produit.<\/p>\n
La base de la r\u00e9partition des co\u00fbts li\u00e9s aux conteneurs repose sur un \u00e9tiquetage coh\u00e9rent. Chaque espace de noms, d\u00e9ploiement et volume persistant doit comporter des \u00e9tiquettes identifiant l'\u00e9quipe responsable, le produit et le centre de co\u00fbts. Ces \u00e9tiquettes sont reprises dans les donn\u00e9es de facturation du cloud et permettent Outils FinOps<\/a> pour regrouper automatiquement les co\u00fbts par unit\u00e9 op\u00e9rationnelle.<\/p>\n Une approche pratique de la r\u00e9partition comporte trois niveaux :<\/p>\n L'un des d\u00e9fis r\u00e9currents li\u00e9s \u00e0 la r\u00e9partition des co\u00fbts des conteneurs r\u00e9side dans le fait que la granularit\u00e9 de la consommation des ressources Kubernetes ne correspond pas parfaitement aux lignes de facturation du cloud. Les pods partagent des n\u0153uds, et les co\u00fbts li\u00e9s aux n\u0153uds sont factur\u00e9s au niveau des machines virtuelles. Pour combler cet \u00e9cart, il faut disposer d\u2019outils capables de mesurer la consommation r\u00e9elle de ressources au niveau des pods et de la traduire en une part proportionnelle des co\u00fbts li\u00e9s aux n\u0153uds.<\/p>\n Les outils les plus efficaces pour suivre et r\u00e9duire les co\u00fbts li\u00e9s \u00e0 l'orchestration des conteneurs se r\u00e9partissent en trois cat\u00e9gories : les outils de visibilit\u00e9 des co\u00fbts natifs du cloud, les plateformes de gestion des co\u00fbts sp\u00e9cifiques \u00e0 Kubernetes et les plateformes FinOps qui int\u00e8grent les co\u00fbts li\u00e9s aux conteneurs dans une gestion financi\u00e8re informatique plus globale. Le choix de la combinaison la plus adapt\u00e9e d\u00e9pend de votre environnement cloud, du niveau de maturit\u00e9 de vos pratiques FinOps et de la mani\u00e8re dont les co\u00fbts li\u00e9s aux conteneurs s'int\u00e8grent dans votre mod\u00e8le global de transparence des co\u00fbts informatiques.<\/p>\n Les outils natifs du cloud, tels qu\u2019AWS Cost Explorer, Azure Cost Management et Google Cloud Billing, vous offrent une visibilit\u00e9 sur les d\u00e9penses li\u00e9es \u00e0 la puissance de calcul et au stockage au niveau des machines virtuelles et des services, mais ils ne fournissent pas \u00e0 eux seuls une granularit\u00e9 au niveau des pods ou des espaces de noms. Pour obtenir ce niveau de d\u00e9tail, il faut recourir \u00e0 des outils sp\u00e9cifiques \u00e0 Kubernetes.<\/p>\n Parmi les outils de gestion des co\u00fbts de Kubernetes les plus couramment utilis\u00e9s, on peut citer :<\/p>\n Le suivi des co\u00fbts ne repr\u00e9sente que la moiti\u00e9 du chemin. Pour les r\u00e9duire, il faut un processus d\u2019optimisation continu, et non le d\u00e9ploiement ponctuel d\u2019un outil. Les \u00e9quipes qui parviennent \u00e0 optimiser durablement leurs co\u00fbts li\u00e9s au cloud associent l\u2019utilisation d\u2019outils \u00e0 un cycle de gouvernance qui consiste \u00e0 examiner r\u00e9guli\u00e8rement les recommandations de redimensionnement, les achats fermes et la pr\u00e9cision de l\u2019allocation.<\/p>\n Les co\u00fbts li\u00e9s \u00e0 l'orchestration des conteneurs sont difficiles \u00e0 g\u00e9rer isol\u00e9ment, car ils se situent \u00e0 la crois\u00e9e des d\u00e9cisions techniques, de la facturation des fournisseurs de cloud et de la gestion financi\u00e8re informatique. Nous aidons les entreprises \u00e0 mettre en place la gouvernance, les outils et les processus n\u00e9cessaires pour transformer les donn\u00e9es relatives aux co\u00fbts des conteneurs en d\u00e9cisions financi\u00e8res concr\u00e8tes.<\/p>\n\n
Quels outils permettent de suivre et de r\u00e9duire les co\u00fbts li\u00e9s \u00e0 l'orchestration des conteneurs ?<\/h2>\n
\n
Comment nous vous aidons \u00e0 g\u00e9rer les co\u00fbts li\u00e9s \u00e0 l'orchestration des conteneurs<\/h2>\n