Coût du cloud : Kubernetes et platform engineering

Douze pods demandent chacun 2 cœurs de processeur (CPU). Le 95e percentile d’usage réel, le p95, est de 0,22 cœur. L’ordonnanceur Kubernetes range les pods selon la demande (request), pas selon l’usage. Réservé : 24 cœurs. Travail : 2,6 cœurs. L’autoscaler horizontal (Horizontal Pod Autoscaler, HPA) calcule le pourcentage de la request, voit de la marge et ne réduit pas le nombre de répliques. Le Cluster Autoscaler ajoute une machine du même type, parce que la place vide sur le nœud est occupée par une request que personne n’a touchée depuis la migration.

Le coût du cloud ne commence pas par une remise du fournisseur. Il commence par qui, dans le platform engineering, a le droit de changer la request, la famille de machines et l’heure à laquelle un environnement hors production s’éteint. Un limit trop serré augmente la latence p99 (99e percentile) ou tue le processus faute de mémoire (out of memory, OOM). Une request bien coupée retire des nœuds que personne n’utilise.

Trois mots qui se fondent en une ligne dans un brief :

• Le platform engineering est l’équipe qui construit la plateforme interne : cluster, intégration et livraison continues (CI/CD), catalogue de services, budgets. Les équipes produit ne montent pas Kubernetes depuis zéro.
• Le FinOps (Financial Operations) est le rythme dans lequel l’ingénierie et la finance voient le coût d’une unité de travail, par exemple mille requêtes, et pas seulement la facture de fin de mois.
• Le slack est l’écart entre la limit ou la request et l’usage réel. Chez Google, les tâches réglées à la main avaient 46% de slack. L’automatisation l’a ramené à 23%.

1. Trois boucles qui ne voient pas le même nombre

Trois régulateurs tournent sur le cluster. Chacun optimise une variable différente. Aucun ne voit la facture seul.

1. Request et limit sur le pod. La request est une réservation pour l’ordonnanceur. La limit est un plafond : au-dessus, le CPU est bridé et la mémoire finit par tuer le processus. Une request 4× au-dessus du p95 laisse sur le nœud un trou où le pod suivant ne rentre pas.
2. Nombre de répliques (HPA). Le HPA ajoute des pods quand le pourcentage de la request dépasse une cible, souvent 50–80%. Si la request est 9× trop grande, l’usage ressemble à 11%. Le HPA dort. Ou il oscille, quand la limit bride le CPU et que la latence monte avant que la moyenne « rattrape ».
3. Nombre de nœuds (Cluster Autoscaler). Le Cluster Autoscaler ajoute et retire des machines d’un pool défini. Le pool est homogène : le type d’instance écrit dans l’infrastructure as code (IaC). Un pod qui ne tient pas dans la place libre réveille une machine de la même famille, même quand une famille moins chère (plus de mémoire, moins de CPU) aurait fait le travail avec un seul nœud.

Le quatrième élément n’est pas un régulateur. C’est un calendrier. Dev et staging à la taille de la production, 24 heures sur 24, 7 jours sur 7. Les heures ouvrées 8 h–19 h font 55 heures sur 168. Le reste, environ deux tiers de la semaine, est une facture de vide.

resources:
  requests:
    cpu: "500m"       # réservation : l’ordonnanceur et le HPA regardent ici
    memory: "512Mi"
  limits:
    cpu: "1500m"      # plafond ; au-dessus, le CPU est bridé
    memory: "1Gi"     # au-dessus, le processus meurt (OOM)

L’autoscaler vertical (Vertical Pod Autoscaler, VPA) sait réécrire la request. En mode automatique il redémarre les pods. Sur la mémoire il peut cacher une fuite : l’application grossit, le VPA monte la limit, le bug quitte le graphique et reste sur la facture. Une recommandation VPA sans barrière n’est pas un déploiement.

Les outils qui choisissent un type de machine pour les pods en attente (sur Amazon Web Services, c’est Karpenter ; ailleurs, le node auto-provisioning) contournent la limite du pool homogène. Ils ne remplacent pas le right-sizing de la request. Ils emballent ce que les pods demandent. S’ils demandent 9× trop, Karpenter achète un emballage plus net du même trou, pas zéro trou.

La facture du processeur graphique (GPU) et de l’entraînement de modèle est une autre boucle : détection de dérive et réentraînement, pas l’emballage des nœuds. Nous l’avons écrite à part dans l’article sur les services MLOps. Mettre les deux briefs dans un « DevOps qui fait tout » produit une astreinte. Ni du FinOps, ni du réentraînement.

2. Ce que les travaux mesurent vraiment

Une slide « nous économiserons 40% » ne dit pas sur quel montage, ni contre quelle base. Quatre sources mesurent des choses différentes. Séparez-les avant d’écrire un pourcentage dans un contrat.

• Slack manuel 46%, automatisme 23%. Rzadca, Findeisen, Świderski et al., Autopilot: Workload Autoscaling at Google (EuroSys 2020). Autopilot règle l’échelle horizontale (nombre de tâches) et verticale (CPU et mémoire) à partir de l’historique. Le slack passe de 46% en configuration manuelle à 23%. Le nombre de tâches durement touchées par un OOM baisse d’environ 10×. À la publication, Autopilot couvrait plus de 48% de l’usage des ressources de la flotte Google. C’est Borg, le système interne de Google, pas un produit à installer sur EKS (Elastic Kubernetes Service). Ce qui se transpose : vertical et horizontal ensemble, sur l’historique, avec le but « moins de slack, sans OOM et sans bridage CPU ».
• Des machines identiques et une mise à jour cassent le motif. Hua, Yang, Qian et al., Humas (arXiv:2406.15769, 2024). Expérience sur 50 microservices réels et plus de 11 000 conteneurs. Face à des méthodes tenues pour l’état de l’art, Humas améliore l’efficacité des ressources d’environ 30,4% et la stabilité d’environ 48,0%. Dans le tableau, le slack sur les traces brutes est de 52,87%, sur une réimplémentation d’Autopilot de 16,63%, sur Humas de 11,58%. L’allocation CPU moyenne baisse d’environ 46,8% par rapport aux traces brutes. À part : après une nouvelle version, le motif d’usage change (dérive de motif). Un autoscaler appris sur l’ancienne version rate de nouveau. Ce n’est pas le même 23% que chez Rzadca. Autre trace, autre nombre.
• Un seuil CPU par service ne voit pas la latence de bout en bout. Sachidananda et Sivaraman, Collective Autoscaling for Cloud Microservices (COLA, arXiv:2112.14845). Chaque microservice scalé seul sur un seuil CPU ignore que la latence de l’utilisateur est la somme de plusieurs services. Sur Google Kubernetes Engine (GKE), en mode standard et Autopilot, COLA tient une cible de latence médiane ou de queue sur 53 des 63 charges et est alors en moyenne 19,3% moins cher que l’autoscaler suivant qui tient aussi cette cible. Il est le moins cher sur 48 de ces 53. Sur de petites applications, dont on peut énumérer toutes les configurations, il est optimal dans 90% des cas. Les auteurs écrivent que l’économie rembourse le coût d’entraînement en quelques jours. C’est leur montage, pas une promesse sur votre facture.
• Le Cluster Autoscaler ne change pas la famille de machines. Boghani, Kirimlioglu, Moturi et Tso, Cloud Resource Allocation with Convex Optimization (arXiv:2503.21096, 2025). Le Cluster Autoscaler monte et descend des pools d’instances identiques. Il ne choisit pas un mélange de types. L’article compare une optimisation convexe à cet autoscaler dans une simulation (Python, médiane de cinq passages), pas sur une facture AWS. Scénario 1, application web simple depuis zéro : pas de différence notable. Un autoscaler standard suffit. Scénario 2, ajout à une infrastructure existante : 42,5% moins cher (0,12 USD/h contre 0,07 USD/h). Scénarios 3 à 5 : 80,5%, 87,2% et 71,1%. Moyenne des cinq : 56,3%. Charge mémoire (scénario 4) : de 1,08 USD/h à 0,14 USD/h. Un surprovisionnement de l’ordre de milliers de pourcents apparaît dans le scénario qui n’autorise que de petites instances. Ce n’est pas une facture typique. C’est la preuve que la mauvaise famille multiplie les nœuds.
• Un VPA sans barrière de fuite achète de la mémoire pour un bug. Karakaya, Şengül et Kaplan, Safety-Gated Autoscaling (arXiv:2607.26503, 29 juillet 2026). Un détecteur de fuite mémoire (régression linéaire, R²) bloque la recommandation au lieu d’agrandir un conteneur cassé. Sur un GKE vivant, l’économie de 20–40% est une projection « et si », pas une facture mesurée. Le détecteur tombe juste à 83%. Jeu de tests : 1118, couverture 80,3%. Il y a un mode dry-run et une validation humaine. Ne citez 20–40% qu’avec cette réserve.

3. Exemple chiffré : 24 cœurs réservés, 2,6 utilisés

Les chiffres des articles ne se transportent pas 1 pour 1 sur votre facture. L’ordre, si : d’abord la request, ensuite le type de machine, ensuite éteindre ce qui ne sert pas de trafic. Commencer par Karpenter sur des requests de 2000m alors que l’usage est à 220m achète un emballage plus joli du même trou.

4. Tableau de décision

DevOps / SRE / cloud : taux du spécialiste 140–200 PLN/h, taux client 200–325 PLN/h. Marge du fournisseur 10–25%. C’est une carte du marché, pas une offre. Le détail : ce que coûte le body leasing IT en 2026. No Fluff Jobs indique pour le 1er trimestre 2026 des fourchettes B2B d’un spécialiste DevOps de 23,5–28,5 mille PLN. C’est sa facture, pas le prix payé par le client.

5. Anti-patrons absents du tutoriel HPA

1. Un HPA à 80% d’une request 4× trop grande. L’autoscaler voit de l’inactivité. Les nœuds restent. Le tableau « utilisation du cluster » affiche 20% et personne ne relie cela au manifeste.
2. Un VPA en mode auto sur la mémoire, sans détecteur de fuite. La recommandation grandit avec le bug. L’incident OOM disparaît. Pas la facture. Le dry-run existe pour qu’une personne voie la tendance avant que la limit monte.
3. Quatre pools « au cas où » et un Cluster Autoscaler qui ne sait qu’ajouter le même type. Boghani : sur une application simple depuis zéro, pas de gain. Le gain est là où la forme des pods ne correspond plus à la famille écrite dans Terraform il y a deux ans.
4. Le FinOps en PDF et un DevOps à 20% d’un temps plein. CI/CD, astreinte, coût, Kubernetes et encore le GPU. Une personne sur cinq boucles n’en ferme aucune. Un outil de coût en lecture seule, sans droit de changer une request, est un PDF plus cher.

6. Playbook : qui louer, et dans quel ordre

Ne commencez pas par un cluster de plus. Commencez par la question de quelle boucle tient la facture : la request, le type de machine, les environnements hors production ou le GPU.

1. Le cluster, l’identité (IAM, identity and access management) et Terraform sont déjà là. Il manque un propriétaire des requests, du budget de namespace et de la revue hebdomadaire. C’est le body leasing d’un ingénieur DevOps classique : une personne, votre stand-up, votre définition de terminé. Le body leasing signifie ici louer un spécialiste dans votre équipe, en général au temps passé (time and materials, T&M). Nous ne vendons pas un banc nommé pour lundi matin.
2. Personne ne possède le cluster. Quatre comptes, pas d’IaC, un dev à la taille de la production, des manifestes avec une request copiée d’un tutoriel. Une personne ne coud pas cela en un sprint. Une équipe plateforme : quelqu’un pour le cluster et l’IaC, quelqu’un pour le CI/CD, quelqu’un qui a le droit de dire « ce namespace s’éteint à 19 h ». C’est plus proche du leasing d’équipes IT que de « on achète encore un DevOps ». Squad ou un rôle : team leasing vs body leasing 2026.
3. Les données et le kubeconfig ne partent pas sur un portable. Le contractant travaille dans votre IAM, dans votre cloud, sous accord de confidentialité (NDA) et clause de sous-traitance. Exporter un kubeconfig « pour calculer les requests plus vite » est un accès à la production. Clauses : contrats, marges, droits d’auteur.
4. Montée en charge. Une personne dans une équipe existante : premiers profils en quelques jours, démarrage après vos entretiens et le contrat. Une équipe depuis zéro : des semaines, parce que vous cousez les droits et une définition de terminé pour changer une request en production. La promesse de « trois seniors plateforme dès lundi » est soit un CV, soit un banc que nous n’avons pas.

Commoditech fait du T&M et du recrutement en CDI depuis Varsovie, depuis 2012. Le réseau compte 80+ spécialistes. Nous ne les gardons pas inactifs sur un banc. Un brief de body leasing ou d’embauche (honoraires au succès, pas d’embauche pas d’honoraires) se dépose aussi depuis l’éditeur, via le MCP pour agents IA (Model Context Protocol, le protocole par lequel un assistant dans l’IDE appelle des outils). Un humain chiffre le stack précis. Les fourchettes sont dans l’article sur les taux, pas dans une réponse automatique. Contact : le formulaire.

FAQ

Sources

• Rzadca, K., Findeisen, P., Świderski, J. et al. (2020). Autopilot: Workload Autoscaling at Google. EuroSys 2020. doi.org/10.1145/3342195.3387524. research.google.
• Hua, Q., Yang, D., Qian, S., Cao, J., Xue, G., Li, M. (2024). Humas. arXiv:2406.15769. arxiv.org/abs/2406.15769.
• Sachidananda, V., Sivaraman, A. (2022). Collective Autoscaling for Cloud Microservices. arXiv:2112.14845. arxiv.org/abs/2112.14845.
• Boghani, S., Kirimlioglu, E., Moturi, A., Tso, H.-T. (2025). Cloud Resource Allocation with Convex Optimization. arXiv:2503.21096. arxiv.org/abs/2503.21096.
• Karakaya, A., Şengül, E., Kaplan, A. (2026). Safety-Gated Autoscaling. arXiv:2607.26503. arxiv.org/abs/2607.26503.
• Commoditech — taux du body leasing 2026, ingénieurs DevOps, team leasing vs body leasing.