7 Min. Temps de lecture<\/p>\n
EKS 1.36 d\u00e9place la question des co\u00fbts d’un \u00e9tage : plus seulement l’efficacit\u00e9 des n\u0153uds, mais l’allocation par charge de travail. Quiconque ne l’ancre pas maintenant dans la plateforme paiera avec des factures de cloud qui ne pourront plus \u00eatre expliqu\u00e9es proprement au prochain trimestre.<\/strong><\/p>\n Les points cl\u00e9s en bref<\/p>\n Li\u00e9 :<\/span>FinOps pour l’inf\u00e9rence de l’IA<\/a> \/<\/span> Un logisticien \u00e9conomise 31 % de co\u00fbts de cloud multi-cloud<\/a><\/p>\n Qu’est-ce qu’EKS 1.36 ?<\/strong> Amazon Elastic Kubernetes Service dans la ligne de versions 1.36 est le service Kubernetes g\u00e9r\u00e9 sur AWS qui refl\u00e8te la version Kubernetes 1.36. Ce qui est nouveau, ce n’est pas seulement l’ensemble de fonctionnalit\u00e9s upstream, mais l’\u00e9troite imbrication de Karpenter, des donn\u00e9es d’allocation de co\u00fbts fractionn\u00e9es et de Container Insights, qui rendent les co\u00fbts au niveau du pod directement audit\u00e9s \u00e0 partir du cluster.<\/p>\n Quiconque regarde dans la console GSC ce que les \u00e9quipes de plateforme ont recherch\u00e9 ces derni\u00e8res semaines, trouve \u00ab\u00a0eks 1.36\u00a0\u00bb plusieurs fois dans les principales requ\u00eates. Ce n’est pas un int\u00e9r\u00eat pour les notes de version. Quiconque tape le terme a d\u00e9j\u00e0 un cluster en fonctionnement et veut savoir ce qui change dans la vue des co\u00fbts.<\/p>\n La r\u00e9ponse courte : AWS a pouss\u00e9 les \u00e9tiquettes d’allocation de co\u00fbts, les donn\u00e9es d’allocation de co\u00fbts fractionn\u00e9es et Container Insights avec des m\u00e9triques au niveau du pod dans la plateforme EKS sur plusieurs versions. EKS 1.36 est le moment o\u00f9 ces \u00e9l\u00e9ments s’embo\u00eetent. Auparavant, c’\u00e9taient des chemins s\u00e9par\u00e9s avec des mod\u00e8les de donn\u00e9es s\u00e9par\u00e9s. Maintenant, ils atterrissent dans une vue que les \u00e9quipes de plateforme doivent elles-m\u00eames curer.<\/p>\n Cela change la responsabilit\u00e9. Jusqu’\u00e0 pr\u00e9sent, l’\u00e9quipe de plateforme pouvait dire : Nous fournissons le cluster, FinOps fournit la vue. Avec 1.36, cela bascule. Quiconque exploite le cluster est \u00e9galement responsable de l’allocation des co\u00fbts, car les \u00e9tiquettes, les \u00e9tiquettes de pod et la pipeline de reporting sont li\u00e9s \u00e0 la plateforme et non \u00e0 l’outil de finance.<\/p>\n Premi\u00e8rement : convention de tagging. Sans tags coh\u00e9rents sur les clusters, les NodePools, les namespaces et les pods, aucune allocation n’est possible. Si vous n’avez pas mis en place cela en 2026, vous reconstruirez la vue \u00e0 chaque ex\u00e9cution de rapport. Une convention suffit, mais elle doit \u00eatre appliqu\u00e9e, id\u00e9alement avec des politiques OPA ou Kyverno.<\/p>\n Deuxi\u00e8mement : strat\u00e9gie de NodePool. Karpenter est stable depuis la version 1.0 et est recommand\u00e9 par d\u00e9faut dans EKS 1.36. Un NodePool d\u00e9cide si une charge de travail s’ex\u00e9cute sur Spot ou \u00e0 la demande, quelle famille d’instances elle obtient et si Graviton est autoris\u00e9. Si cette d\u00e9cision est laiss\u00e9e \u00e0 l’\u00e9quipe d’applications, il n’y a pas d’histoire de co\u00fbts de plateforme. Si elle est prise de mani\u00e8re centralis\u00e9e, il y a des frictions. Les deux sont acceptables, mais cela doit \u00eatre explicite.<\/p>\n Troisi\u00e8mement : allocation au niveau du pod. Les donn\u00e9es d’allocation de co\u00fbts EC2 r\u00e9parties par AWS Split Cost Allocation Data ne fonctionnent que si les demandes de ressources sont correctement configur\u00e9es. Dans la plupart des clusters, ce n’est pas le cas. Les pods s’ex\u00e9cutent avec des demandes par d\u00e9faut trop \u00e9lev\u00e9es ou trop basses, et l’allocation devient inutilisable. Avant l’histoire des co\u00fbts, il y a donc un audit des demandes.<\/p>\n \n”<\/span><\/p>\n Une vue FinOps sur EKS n’est aussi pr\u00e9cise que les demandes de ressources dans les manifestes. Si vous mentez \u00e0 ce sujet, vous ruinez toute l’allocation.<\/p>\n<\/blockquote>\n<\/figure>\n Dans les premi\u00e8res ann\u00e9es de Karpenter, l’objectif \u00e9tait de remplacer le Cluster-Autoscaler et d’acc\u00e9l\u00e9rer la mont\u00e9e en charge. C’est chose faite. Ce qui compte maintenant, c’est la discipline des NodePools. Un NodePool est un contrat entre la plateforme et l’\u00e9quipe : quels types d’instances, quelle zone de disponibilit\u00e9, quelle proportion de Spot, quelle tol\u00e9rance aux perturbations.<\/p>\n Si vous regroupiez tout dans un seul NodePool, vous n’avez pas de contr\u00f4le. Si vous construisez un NodePool par \u00e9quipe, vous avez trop de complexit\u00e9. De mani\u00e8re r\u00e9aliste, il y a trois \u00e0 cinq NodePools par cluster productif : un pour les charges de travail statiques \u00e0 long terme, un pour les charges de travail Spot capables de traitement par lots, un pour l’inf\u00e9rence GPU, et \u00e9ventuellement un pour les pods isol\u00e9s pour des raisons de conformit\u00e9.<\/p>\n La d\u00e9finition du NodePool est ainsi une d\u00e9cision FinOps qui figure dans le manifeste du cluster. Elle est auditable, versionn\u00e9e et se trouve dans le m\u00eame r\u00e9f\u00e9rentiel que le reste de la configuration de la plateforme. C’est le point o\u00f9 la gouvernance des co\u00fbts devient technique et ne se limite plus \u00e0 un tableau de bord.<\/p>\n Le multi-cloud ressemble \u00e0 une diversification des risques pour la finance. Pour la plateforme, c’est un probl\u00e8me d’allocation. EKS facture diff\u00e9remment d’AKS, AKS facture diff\u00e9remment de GKE, et aucune des trois vues ne peut \u00eatre mapp\u00e9e sur les autres sans adaptateur.<\/p>\n Source : documentation des fournisseurs, \u00e9tat en mai 2026, \u00e9valuation propre.<\/p>\n Lorsqu’on utilise trois clouds en parall\u00e8le, il est n\u00e9cessaire d’avoir une couche de traduction. Celle-ci peut \u00eatre assur\u00e9e par un outil tel que Kubecost ou OpenCost, ou \u00e9galement par une pipeline construite en interne qui rassemble les trois API de co\u00fbt sur un sch\u00e9ma commun. Ce qui ne fonctionne pas : permettre \u00e0 chaque \u00e9quipe d’avoir sa propre convention cloud et construire un Excel \u00e0 la fin du mois.<\/p>\n La question difficile dans chaque programme FinOps n’est pas la somme, mais la r\u00e9partition. Un cluster utilis\u00e9 par quatre \u00e9quipes a un op\u00e9rateur de cluster et quatre consommateurs. L’op\u00e9rateur paie pour le plan de contr\u00f4le, le r\u00e9seau et les services partag\u00e9s. Les consommateurs paient pour leurs pods.<\/p>\n Cela semble simple. En pratique, trois choses s’effondrent : les pods sans \u00e9tiquettes propres ne sont pas attribu\u00e9s. Les services partag\u00e9s tels que les contr\u00f4leurs d’entr\u00e9e ou les r\u00e9seaux de services sont compt\u00e9s deux fois. Les ressources inactives ne sont pas r\u00e9parties. Une allocation qui ne r\u00e9glemente pas ces trois points est une politique, pas une facturation.<\/p>\n Le chemin pragmatique : les pods sans \u00e9tiquette d’\u00e9quipe atterrissent dans un \u00ab\u00a0bac de plateforme\u00a0\u00bb et sont ren\u00e9goci\u00e9s mensuellement. Les services partag\u00e9s sont r\u00e9partis proportionnellement \u00e0 la consommation de CPU. La capacit\u00e9 inactive est r\u00e9partie entre les \u00e9quipes qui ont caus\u00e9 les instances r\u00e9serv\u00e9es ou les plans d’\u00e9pargne. Ce n’est pas parfait, mais c’est explicable.<\/p>\n Une \u00e9quipe de plateforme qui exploite EKS 1.36 de mani\u00e8re productive en 2026 a un contrat diff\u00e9rent avec l’organisation qu’il y a deux ans. \u00c0 l’\u00e9poque, la question \u00e9tait : Pouvez-vous nous donner un cluster qui fonctionne ? Aujourd’hui, elle est : Pouvez-vous nous dire ce qu’il co\u00fbte et qui le paie ?<\/p>\n Cela n\u00e9cessite trois choses dans le catalogue de services. Premi\u00e8rement, une convention de tagging qui s’applique comme condition d’int\u00e9gration. Deuxi\u00e8mement, une s\u00e9lection de NodePool que l’\u00e9quipe doit faire activement et qui est clairement d\u00e9crite avec des implications de co\u00fbt. Troisi\u00e8mement, un rapport de co\u00fbt mensuel qui est sur la table de la finance et non seulement lorsque le directeur financier demande.<\/p>\n Qui obtient cela, a une plateforme. Qui n’y arrive pas, a une collection de clusters avec une facture inconnue. EKS 1.36 rend la diff\u00e9rence techniquement visible. La d\u00e9cision de la tirer \u00e9galement organisationnellement appartient aux \u00e9quipes de plateforme.<\/p>\n Non, mais la t\u00e2che devient plus compliqu\u00e9e avec une construction propre. Les donn\u00e9es d’allocation de co\u00fbts AWS Split et les tags d’allocation de co\u00fbts suffisent pour la plupart des sc\u00e9narios de cluster unique. D\u00e8s que plus de trois clusters ou de multi-cloud sont impliqu\u00e9s, un outil comme Kubecost, OpenCost ou une couche similaire en vaut la peine. Les co\u00fbts des outils eux-m\u00eames sont g\u00e9n\u00e9ralement nettement inf\u00e9rieurs aux heures qu’une \u00e9quipe passe dans ses propres pipelines.<\/p>\n<\/details>\n Karpenter utilise automatiquement les instances r\u00e9serv\u00e9es et les plans d’\u00e9conomie s’ils sont disponibles sur la m\u00eame famille d’instances. Mais il pr\u00e9f\u00e8re les instances Spot bon march\u00e9, ce qui conduit \u00e0 une politique Spot agressive qui fait que les plans d’\u00e9conomie ne sont pas pleinement utilis\u00e9s. Qui ach\u00e8te des plans d’\u00e9conomie sur plusieurs ann\u00e9es devrait d\u00e9finir des NodePools avec une capacit\u00e9 On-Demand uniquement qui absorbent ces plans et n’autorise Spot que l\u00e0 o\u00f9 la charge de travail est tol\u00e9rante aux perturbations.<\/p>\n<\/details>\n Un pod s’ex\u00e9cute toujours dans un seul espace de noms. Ce qui est vis\u00e9 : si une charge de travail utilise des ressources Cross-Namespace comme des volumes partag\u00e9s, des services communs ou des bases de donn\u00e9es centrales, l’allocation doit refl\u00e9ter cette connexion transversale. Voie pragmatique : les ressources Cross-Namespace vont dans un bucket \u00ab\u00a0Services partag\u00e9s\u00a0\u00bb qui est r\u00e9parti sur les consommateurs selon une cl\u00e9 clairement d\u00e9finie (consommation de CPU, nombre de requ\u00eates). Qui ne r\u00e9glemente pas cela, perd 10 \u00e0 20 pour cent des co\u00fbts dans une attribution peu claire.<\/p>\n<\/details>\n Le chemin de mise \u00e0 niveau vers 1.36 en vaut la peine pour chaque cluster productif, ne serait-ce que pour les correctifs de s\u00e9curit\u00e9 et la politique de cycle de vie d’AWS. Les fonctionnalit\u00e9s FinOps sont un bonus, pas un moteur. Pour trois \u00e9quipes, une seule NodePool avec une tol\u00e9rance Spot clairement d\u00e9finie, un sch\u00e9ma d’\u00e9tiquetage coh\u00e9rent et un export de co\u00fbt mensuel suffisent souvent. L’appareil FinOps complet est n\u00e9cessaire pour les clusters de cinq \u00e9quipes ou de charge de travail informatique combin\u00e9e de plus de 200 000 euros par an.<\/p>\n<\/details>\n Plus d’informations sur le r\u00e9seau MBF Media<\/p>\n Optimisation des processus sans projet permanent<\/a>\n<\/div>\n\n
Ce qui change avec EKS 1.36 dans la question des co\u00fbts<\/h2>\n
Trois \u00e9l\u00e9ments \u00e0 ajuster pour les \u00e9quipes de plateformes<\/h2>\n
Karpenter devient un instrument de contr\u00f4le plut\u00f4t qu’un simple avantage d’\u00e9conomie<\/h2>\n
Ce que le multi-cloud fait avec la facturation EKS<\/h2>\n
\n\n
\n \nDimension d’allocation<\/th>\n EKS 1.36<\/th>\n AKS 1.32<\/th>\n GKE 1.34<\/th>\n<\/tr>\n<\/thead>\n \n Co\u00fbts au niveau du pod<\/strong><\/td>\n Donn\u00e9es d’allocation des co\u00fbts fractionn\u00e9s de mani\u00e8re native<\/td>\n Analyse des co\u00fbts par namespace<\/td>\n Allocation des co\u00fbts GKE, bas\u00e9e sur les \u00e9tiquettes<\/td>\n<\/tr>\n \n Gestion des spots<\/strong><\/td>\n Karpenter NodePool<\/td>\n Pools de n\u0153uds Spot<\/td>\n Provisionnement automatique de n\u0153uds avec Spot<\/td>\n<\/tr>\n \n H\u00e9ritage des \u00e9tiquettes<\/strong><\/td>\n \u00c9tiquettes Kubernetes mapp\u00e9es sur les \u00e9tiquettes AWS<\/td>\n \u00c9tiquettes Azure via Cluster Autoscaler<\/td>\n \u00c9tiquettes natives dans la facturation GCP<\/td>\n<\/tr>\n \n Latence des rapports<\/strong><\/td>\n 24 heures<\/td>\n 12 \u00e0 24 heures<\/td>\n Jusqu’\u00e0 48 heures<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n Allocation : qui paie pour quel pod<\/h2>\n
Ce qui doit changer dans le contrat de plateforme maintenant<\/h2>\n
Foire aux questions<\/h2>\n
Ai-je besoin de Kubecost pour allouer proprement les co\u00fbts EKS ?<\/strong><\/summary>\n
Comment Karpenter se comporte-t-il avec les instances r\u00e9serv\u00e9es et les plans d’\u00e9conomie ?<\/strong><\/summary>\n
Qu’arrive-t-il \u00e0 l’allocation de co\u00fbts si un pod s’ex\u00e9cute dans plusieurs espaces de noms ?<\/strong><\/summary>\n
L’EKS 1.36 en vaut-il la peine pour un petit cluster avec trois \u00e9quipes ?<\/strong><\/summary>\n
Conseils de lecture de la r\u00e9daction<\/h3>\n
\n