FinOps Kubernetes et maîtrise des coûts

Le FinOps Kubernetes consiste à rendre la dépense d'un cluster visible, réductible et durable. Il suit la boucle Inform, Optimize, Operate de la FinOps Foundation : attribuer la dépense aux équipes et aux applications qui la génèrent, agir sur le gaspillage que cette attribution révèle, puis inscrire la discipline dans la plateforme pour que les gains ne s'érodent pas. Sur Kubernetes c'est un travail précis — requests et limits, politique d'autoscaling, capacité spot, attribution des coûts par namespace — pas une revue générique de facture cloud.

Le cluster autoscaler fait varier des groupes de nœuds définis à l'avance : vos économies sont donc plafonnées par la qualité de votre pari initial sur les types d'instances. Karpenter provisionne des nœuds taillés pour les pods réellement en attente, en choisissant type, taille et mode d'achat par charge de travail, et il consolide — il détecte que les mêmes pods tiendraient sur des nœuds moins chers ou moins nombreux et reconstruit la flotte en conséquence. C'est cette boucle de consolidation qui produit l'essentiel du gain récurrent, parce qu'elle continue de travailler après la mission. La contrepartie est le churn : les nœuds sont remplacés plus souvent, donc les PodDisruptionBudgets et l'arrêt gracieux doivent être corrects avant de l'activer.

Non, et nous préférons le dire d'emblée. Karpenter dispose de providers de production pour AWS et Azure ; il n'existe pas de provider OVHcloud ni Scaleway. Sur ces plateformes le travail de coût est la même discipline avec une mécanique différente : le cluster autoscaler managé réglé sur une conception réaliste des node pools, un rightsizing piloté par la consommation mesurée plutôt que par des valeurs par défaut héritées, et de la capacité spot ou préemptible là où la charge tolère une reprise. Les couches d'attribution et de gouvernance — OpenCost, policy as code — sont agnostiques du fournisseur et se comportent à l'identique. D'après notre expérience, le rightsizing seul rapporte généralement plus que le choix de l'autoscaler : le chemin OVHcloud et Scaleway n'est donc pas un lot de consolation.

Le coût devient un signal sur les mêmes tableaux de bord que le reste. OpenCost, projet CNCF, attribue la dépense cloud réelle jusqu'au namespace, au contrôleur et au pod ; nous l'exportons vers Prometheus pour que le coût soit à côté de la latence et du taux d'erreur, et non dans un outil financier que personne dans l'équipe n'ouvre. Vous obtenez une dépense par namespace avec un propriétaire, des alertes sur les anomalies de coût et le pourcentage de ressources inactives, et un chiffre mensuel que chaque équipe reconnaît comme le sien. C'est la visibilité avec responsabilité qui empêche la facture de remonter.

C'est ce qui rend le gain durable plutôt que saisonnier. La politique d'autoscaling, les requests, les définitions de NodePool et les garde-fous de coût vivent dans le même dépôt que le reste de la plateforme, réconciliés par Argo CD. Un changement de posture de coût est une pull request relue avec sa trace d'audit, pas une modification console que quelqu'un oublie. La policy as code avec Kyverno tient la ligne en dessous : refuser les workloads sans requests, bloquer les familles d'instances que vous avez décidé de ne pas payer, exiger le label d'équipe dont dépend l'attribution.