🥇 Revue de Kubecost pour économiser de l'argent sur Kubernetes dans le cloud

De nos jours, de plus en plus d'entreprises transfèrent leur infrastructure des serveurs physiques et des machines virtuelles locales vers le cloud. Cette décision peut être facilement expliquée : il n'est plus nécessaire de s'occuper du matériel, le cluster peut être configuré de nombreuses façons différentes... et surtout, les technologies existantes (comme Kubernetes) permettent de simplement faire évoluer les capacités de calcul en fonction de la charge.

L'aspect financier est toujours important. L'outil dont nous parlerons dans cet article est conçu pour aider à réduire les budgets lors de l'utilisation d'infrastructures cloud avec Kubernetes.

Introduction

Kubecost — une start-up californienne fondée par d'anciens de Google, développant une solution pour le calcul des coûts d'infrastructure dans les services cloud (au sein du cluster Kubernetes + ressources partagées), pour identifier les goulets d'étranglement dans les configurations du cluster et envoyer des notifications correspondantes sur Slack.

Nous avons des clients utilisant Kubernetes aussi bien dans des clouds familiers comme AWS et GCP que sur Azure, qui est moins courant pour la communauté Linux — en fait, sur toutes les plateformes prises en charge par Kubecost. Pour certains d'entre eux, nous calculons les coûts des services intra-cluster de manière autonome (selon une méthodologie similaire à celle utilisée par Kubecost), et nous surveillons également les dépenses d'infrastructure tout en essayant de les optimiser. Il est donc logique que nous soyons intéressés par l'automatisation de ces tâches.

Le code source du module principal de Kubecost est ouvert sous une licence Open Source (Apache License 2.0). Il peut être utilisé librement, et les fonctionnalités disponibles devraient suffire pour des projets de petite taille. Cependant, le business est le business : le reste du produit est propriétaire et nécessite un accès par abonnements payants, qui incluent également un support commercial. De plus, les auteurs proposent une licence gratuite pour les petits clusters (1 cluster avec 10 nœuds — au moment de la rédaction de cet article, cette limite a été portée à 20 nœuds) ou une période d'essai d'un mois avec toutes les fonctionnalités.

Comment tout fonctionne

Ainsi, la partie principale de Kubecost est une application cost-model, écrite en Go. Le chart Helm décrivant l'ensemble du système s'appelle cost-analyzer et est essentiellement un ensemble de cost-model avec Prometheus, Grafana et plusieurs tableaux de bord.

En général, le cost-model dispose de sa propre interface web qui affiche des graphiques et des statistiques détaillées sur les coûts sous forme de tableau, ainsi que, bien sûr, des conseils pour optimiser les dépenses. Les tableaux de bord présentés dans Grafana représentent une phase antérieure du développement de Kubecost et contiennent en grande partie les mêmes données que le cost-model, en les complétant par des statistiques familières sur la consommation de CPU/mémoire/réseau/espace disque dans le cluster et ses composants.

Comment fonctionne Kubecost ?

Le cost-model obtient les prix de maintenance via l'API des fournisseurs de cloud.
Ensuite, en fonction du type de matériel des nœuds et de la région, le coût par nœud est calculé.
Sur la base du coût de fonctionnement des nœuds, chaque pod final reçoit un coût par heure d'utilisation du processeur, de consommation d'un gigaoctet de mémoire et de coût par heure de stockage d'un gigaoctet de données — en fonction du nœud sur lequel il a fonctionné ou de la classe de stockage.
À partir du coût de fonctionnement des pods individuels, le paiement est calculé par espaces de noms, services, déploiements, StatefulSets.
Pour calculer les statistiques, des métriques fournies par kube-state-metrics et node-exporter sont utilisées.

Il est important de noter que Kubecost ne prend en compte que les ressources disponibles dans Kubernetes. Les bases de données externes, les serveurs GitLab, les stockages S3 et d'autres services, absents du cluster (même s'ils se trouvent dans le même cloud), ne lui sont pas visibles. Cependant, pour GCP et AWS, il est possible d'ajouter des clés de ses comptes de service et de tout calculer ensemble.

Installation

Pour faire fonctionner Kubecost, il est nécessaire :

Kubernetes version 1.8 et supérieure ;
kube-state-metrics ;
Prometheus ;
node-exporter.

Il se trouve que dans nos clusters, toutes ces conditions étaient préalablement remplies, il suffisait donc d'indiquer le bon endpoint pour accéder à Prometheus. Néanmoins, le chart Helm officiel de kubecost contient tout le nécessaire pour se lancer même sur un cluster "nu".

Kubecost peut être installé de plusieurs manières :

La méthode standard d'installation, décrite dans des instructions sur le site du développeur. Vous devez ajouter le dépôt Helm cost-analyzer, puis installer le chart. Il ne restera plus qu'à rediriger un port et à peaufiner les paramètres manuellement (via kubectl) et/ou à l'aide de l'interface web du cost-model.
Cette méthode, nous ne l'avons même pas essayée, car nous n'utilisons pas de configurations tierces prêtes à l'emploi, mais elle semble être une bonne option « juste pour essayer par soi-même ». Si vous avez déjà installé certains composants du système ou si vous souhaitez une configuration plus fine, il serait préférable d'envisager la seconde voie.
Utiliser en fait le même chart, mais en le configurant et en l'installant soi-même de la manière qui vous convient.
Comme déjà mentionné, en plus de kubecost, ce chart contient des charts Grafana et Prometheus, qui peuvent également être configurés selon vos souhaits.
Celui présent dans le chart values.yaml pour cost-analyzer permet de configurer :
- la liste des composants du cost-analyzer à déployer ;
- votre point de terminaison pour Prometheus (si vous en avez déjà un) ;
- les domaines et autres paramètres pour les ingress du cost-model et de Grafana ;
- les annotations pour les pods ;
- la nécessité d'utiliser des stockage persistants et leur taille.
La liste complète des options de configuration disponibles avec description se trouve dans documentation.
Étant donné que kubecost, dans sa version de base, ne sait pas limiter l'accès, il sera nécessaire de configurer d'emblée l'authentification de base pour le panneau web.
Installer uniquement le noyau du système — cost-model. Pour cela, il est nécessaire d'avoir Prometheus installé dans le cluster et d'indiquer l'adresse correspondante dans la variable prometheusEndpoint pour Helm. Ensuite, appliquez un ensemble de configurations YAML dans le cluster.
Encore une fois, il faudra ajouter manuellement un Ingress avec l'authentification de base. Enfin, il sera nécessaire d'ajouter une section pour la collecte de métriques du cost-model dans extraScrapeConfigs dans la configuration de Prometheus :
```
- job_name: kubecost
  honor_labels: true
  scrape_interval: 1m
  scrape_timeout: 10s
  metrics_path: /metrics
  scheme: http
  dns_sd_configs:
  - names:
    - 
    type: 'A'
    port: 9003
```

Que obtenons-nous ?

Lors d'une installation complète, nous disposons d'un panneau web kubecost et de Grafana avec un ensemble de tableaux de bord.

Coût total, affiché sur l'écran principal, indique en fait le coût estimé des ressources pour le mois. C'est un prix prévisionnel qui montre le coût d'utilisation du cluster (par mois) au niveau actuel de consommation des ressources.

Cette métrique est davantage destinée à l'analyse des dépenses et à leur optimisation. Il n'est pas très pratique de consulter les coûts pour un mois de juillet abstrait dans kubecost : il faudra aller dans la facturation. Cependant, vous pouvez voir les dépenses ventilées par espaces de noms, labels, pods sur 1/2/7/30/90 jours, ce que la facturation ne vous montrera jamais.

À propos des labels. Il est recommandé d’accéder immédiatement aux paramètres et de définir les noms des étiquettes qui seront utilisées comme catégories supplémentaires pour regrouper les coûts :

Vous pouvez apposer n'importe quelle étiquette sur celles-ci — c'est pratique si vous avez déjà votre propre système de marquage.

Vous pouvez également changer l'adresse de l'API endpoint à laquelle se connecte le modèle de coût, ajuster la taille de la remise dans GCP et définir vos propres prix pour les ressources et la devise utilisée pour leur mesure (cette fonctionnalité n'affecte malheureusement pas le coût total).

Kubecost peut montrer divers problèmes dans le cluster (et même alerter en cas de danger). Malheureusement, cette option n'est pas configurable, donc — si vous avez des environnements pour les développeurs et qu'ils sont utilisés, vous pourrez constamment observer quelque chose de similaire :

Un outil important — Cluster Savings. Il mesure l'activité des pods (consommation des ressources, y compris réseau), et calcule combien d'argent et dans quels domaines vous pouvez économiser.

Il peut sembler que les conseils d'optimisation soient assez évidents, cependant, l'expérience indique qu'il y a toujours quelque chose à observer. En particulier, l'activité réseau des pods est suivie (Kubecost recommande de prêter attention à ceux qui sont inactifs), la consommation mémoire et CPU demandée et réelle est comparée, ainsi que le CPU utilisé par les nœuds du cluster (recommandation de regrouper plusieurs nœuds en un seul), la charge sur les disques et quelques dizaines d'autres paramètres.

Comme pour toute question relative à l'optimisation, l'optimisation des ressources basée sur les données de Kubecost doit être abordée avec prudence. Par exemple, Cluster Savings propose de supprimer des nœuds, affirmant que c'est sûr, mais ne tient pas compte de la présence de sélecteurs de nœuds et de taints sur les pods déployés sur ceux-ci, qui ne se trouvent pas sur les autres nœuds. Et en général, même les auteurs du produit dans leur un article récent (d’ailleurs, cela peut s'avérer très utile pour ceux qui s'intéressent au projet) recommandent de ne pas se jeter aveuglément dans l'optimisation des coûts, mais d'aborder la question de manière réfléchie.

Résultats

Après avoir utilisé kubecost pendant un mois sur quelques projets, nous pouvons conclure qu'il s'agit d'un outil intéressant (et aussi facile à maîtriser et à installer) pour analyser et optimiser les dépenses en services des fournisseurs de cloud utilisés pour les clusters Kubernetes. Les calculs sont très précis : dans nos expériences, ils coïncidaient avec ce que les fournisseurs demandaient réellement.

Il y a aussi des inconvénients : certains bugs mineurs, et les fonctionnalités ne couvrent pas toujours les besoins spécifiques de certains projets. Cependant, si vous devez rapidement comprendre où va l'argent et ce qui peut être « coupé » pour réduire de manière stable la facture des services cloud de 5 à 30 % (cela a été le cas pour nous), c'est une excellente option.

P.S.

Lisez aussi dans notre blog :

Source : habr.com

Aperçu de Kubecost pour des économies sur Kubernetes dans le cloud