FinOps Kubernetes : un modèle QoS à maîtriser
Pas d'optimisation des coûts sur Kubernetes sans maîtrise du modèle de qualité de service des pods ? Google Cloud insiste sur cet élément.
Vos équipes ont-elle bien assimilé les niveaux de service selon lesquels les pods sont classés ? Google Cloud pose la question dans un rapport qu'il consacre à l'optimisation des coûts de Kubernetes.
L'orchestrateur détermine la QoS d'un pod en fonction de ses demandes de ressources (mémoire et CPU) :
- BestEffort : pas de demandes spécifiées, ni de limites
- Burstable : demandes spécifiées ; limites éventuellement précisées
- Guaranteed : mêmes niveaux de demandes et de limites
Si un noeud vient à manquer de ressources, le kubelet tente d'en récupérer. Il stoppe en priorité les pods BestEffort. Ensuite, les Burstable s'ils utilisent plus de mémoire que demandé. Puis, en dernier lieu, les Guaranteed.
Lire aussi : Le FinOps, en filigrane de l'AWS re:Invent 2024
Mal maîtrisé, ce mécanisme peut dégrader le fonctionnement de l'orchestrateur. Mais aussi perturber les outils d'estimation des coûts qui ont tendance à se baser sur les demandes de ressources et non sur la consommation réelle.
La limite CPU a moins d'importance : Kubernetes peut adapter la consommation, au prix d'une dégradation de performance.
Les webhooks d'admission en tour de contrôle
Pour repérer et contrôler la présence de pods BestEffort ou de pods Burstable sous-dotés en mémoire, les webhooks d'admission sont une option. Google Cloud évoque aussi Gatekeeper, le contrôleur du projet Open Policy Agent - il l'a d'ailleurs intégré, entre autres, dans son offre Anthos.
Exemple pratique : lorsqu'un merge request ne comporte pas de demande de ressources, un pipeline de validation par les pairs peut s'enclencher. Ou bien un avertissement peut être ajouté en annotation. On peut aussi envisager de créer les pods sur des ressources préemptibles (VM Spot). Ou, pour les workloads tolérant les redémarrages, de recommander ou de forcer l'autoscaling vertical.
Cette maîtrise de la QoS s'assortira du dimensionnement adéquat des workloads. Un élément pas forcément acquis, à en croire Google Cloud : même les utilisateurs qui gèrent correctement la consommation mémoire ont de la marge sur le CPU.
À consulter en complément :
FinOps : une mise en conformité qui peut coûter cher
Le refactoring applicatif Kubernetes, un risque à ne pas négliger
ChatGPT peut-il sécuriser Kubernetes ?
Illustration principale © LuckyStep - Adobe Stock
Sur le même thème
Voir tous les articles Cloud