Recherche

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.

Publié par Clément Bohic le - mis à jour à
Lecture
2 min
  • Imprimer
FinOps Kubernetes : un modèle QoS à maîtriser

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.

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

Livres Blancs #cloud

Voir tous les livres blancs
S'abonner
au magazine
Se connecter
Retour haut de page