Qu'est-ce que le chart Helm de Kubecost ?
Vous pouvez installer Kubecost à l'aide du chart Helm officiel via le dépôt cost-analyzer. Ce chart est un package permettant de déployer Kubecost sur un cluster Kubernetes avec Helm. Il définit les ressources Kubernetes dont Kubecost a besoin, comme les déploiements, les services, la configuration et les composants associés. Helm gère ces ressources comme une seule release, ce qui simplifie l'installation, la mise à jour, la configuration et la suppression de Kubecost.
Ce que contient le chart :
Le chart Helm de Kubecost regroupe les ressources Kubernetes et les dépendances configurables nécessaires au fonctionnement de Kubecost. Selon les valeurs configurées, cela peut inclure les composants applicatifs de Kubecost, l'intégration avec Prometheus, les composants de métriques Kubernetes, le stockage persistant, les Services et l'Ingress, les ressources de monitoring, la collecte des coûts réseau, les network policies et les intégrations tarifaires des fournisseurs cloud.
Bonnes pratiques de configuration :
- Figez les versions du chart Helm de Kubecost : spécifiez une version de chart explicite pour garder des déploiements prévisibles et éviter les changements inattendus liés aux nouvelles versions.
- Versionnez les valeurs Helm : stockez les surcharges de configuration dans un fichier
values.yamlversionné, tout en conservant les identifiants et autres secrets hors du dépôt. - Utilisez des fichiers de valeurs distincts selon les environnements : maintenez une configuration spécifique à chaque environnement (développement, staging, production) au lieu de dupliquer ou de modifier les manifests du chart.
- Définissez des requests et limits de ressources adaptés : dimensionnez le CPU et la mémoire des composants Kubecost en fonction de la taille du cluster, et ajustez-les selon la consommation réellement observée.
- Configurez un stockage persistant pour la production : choisissez une capacité de volume persistant adaptée et une StorageClass fiable en fonction des exigences de rétention, de croissance, de sauvegarde et de restauration.
- Testez les mises à jour Helm avant la production : validez les nouvelles versions de chart et vos valeurs personnalisées existantes dans un environnement hors production, et conservez un chemin de rollback testé.
Dans cet article :
- Les deux charts Helm Kubecost : cost-analyzer vs kubecost
- Ce que contient le chart Helm
- Comment installer Kubecost avec Helm
- Chart Helm Kubecost ou manifests Kubernetes
- Bonnes pratiques pour le chart Helm Kubecost
Les deux charts Helm Kubecost : cost-analyzer vs kubecost
Kubecost propose désormais deux lignées de charts Helm que les administrateurs peuvent rencontrer : l'ancien chart cost-analyzer utilisé pour les déploiements Kubecost 2.x, et le nouveau chart kubecost introduit avec Kubecost 3.x. Le dépôt Kubecost actuel identifie la version 2.8 comme la dernière version apportant de nouvelles fonctionnalités à la lignée 2.x, la version 2.9 comme une étape de mise à niveau intermédiaire, et la version 3.0 comme la première version de Kubecost 3.x.
Le chart cost-analyzer est la méthode de déploiement historique utilisée tout au long de Kubecost 2.x. Les environnements existants peuvent continuer à référencer des commandes telles que kubecost/cost-analyzer, et Kubecost maintient toujours les dépôts associés à ce chart pour les déploiements plus anciens et les scénarios de mise à niveau.
Pour Kubecost 3.x, le chart principal s'appelle désormais kubecost. Les nouvelles installations utilisent le chart kubecost/kubecost depuis le dépôt Helm de Kubecost. Kubecost 3.x introduit également des changements architecturaux majeurs, dont un stockage basé sur ClickHouse et un nouvel agent finops-agent qui remplace l'agent cost-model utilisé en 2.x.
Les organisations qui mettent à niveau un déploiement Kubecost 2.x existant ne doivent donc pas considérer ce changement comme un simple renommage de chart. Kubecost recommande de mettre à niveau les agents vers la version 2.9 avant de passer à la 3.x, en laissant tourner cette version intermédiaire avant de finaliser la migration. Les valeurs cost-analyzer existantes doivent aussi être passées en revue plutôt que supposées compatibles avec le nouveau chart kubecost, car les noms de composants, l'architecture de stockage et les options de configuration ont changé.
Ce que contient le chart Helm
Le chart Helm de Kubecost inclut les templates Kubernetes et les dépendances configurables nécessaires au fonctionnement de Kubecost. Les ressources exactes déployées dépendent de la version du chart et des valeurs que vous activez, mais le chart couvre généralement les composants suivants :
- Composants applicatifs de Kubecost : Deployments, Services, ConfigMaps, Secrets, service accounts et autres ressources nécessaires pour exécuter Kubecost et exposer ses fonctionnalités de suivi des coûts.
- Collecte de métriques (
finops-agent) : le chart déploie lefinops-agent, un agent léger qui collecte les métriques du cluster utilisées par Kubecost pour l'allocation des coûts, sans déploiement Prometheus distinct. - Composants de métriques Kubernetes : selon la configuration, le chart peut déployer des composants complémentaires comme
kube-state-metricset Node Exporter, qui fournissent des métriques sur les objets Kubernetes et les nœuds. - Stockage persistant : les valeurs Helm peuvent créer des persistent volume claims pour les données de Kubecost et Prometheus, avec des tailles de stockage et des storage classes configurables.
- Configuration de l'Ingress et des services : le chart propose des paramètres pour exposer Kubecost via des Services Kubernetes et, si activé, un Ingress avec hôtes, chemins, annotations et paramètres TLS configurables.
- Ressources de monitoring : des ressources optionnelles comme
ServiceMonitoretPrometheusRulepeuvent être créées pour les environnements utilisant le Prometheus Operator. - Fonctionnalités et intégrations optionnelles : les valeurs Helm peuvent activer des fonctionnalités supplémentaires comme la collecte des coûts réseau, les network policies, les intégrations tarifaires des fournisseurs cloud et d'autres fonctionnalités Kubecost, sans modifier manuellement les manifests Kubernetes générés.
Comme ces composants sont pilotés via le values.yaml du chart, les organisations peuvent n'activer que les ressources dont elles ont besoin, ou intégrer Kubecost aux composants de monitoring et d'infrastructure déjà présents dans le cluster.
Contenu associé : consultez notre guide sur l'optimisation des coûts Kubernetes
Comment installer Kubecost avec Helm
Kubecost s'installe avec Helm en ajoutant le dépôt de charts officiel de Kubecost et en déployant le chart dans un namespace dédié. Le dépôt de charts Helm actuel de Kubecost fournit le chart kubecost/kubecost pour Kubecost 3.x.
Ajoutez d'abord le dépôt Helm de Kubecost et mettez à jour votre index local de charts :
helm repo add kubecost https://kubecost.github.io/kubecost/helm repo updateInstallez ensuite Kubecost dans un namespace kubecost :
helm install kubecost kubecost/kubecost \ --namespace kubecost \ --create-namespaceKubecost permet aussi d'installer directement depuis l'URL du dépôt. L'exemple officiel définit global.clusterId pour identifier le cluster :
helm install kubecost \ --repo https://kubecost.github.io/kubecost kubecost \ --namespace kubecost \ --create-namespace \ --set global.clusterId=my-clusterAvant de déployer en production, vous pouvez inspecter les valeurs prises en charge par une version de chart donnée :
helm show values kubecost/kubecost --version <chart-version>Vous pouvez alors placer la configuration requise dans un fichier values.yaml personnalisé et installer Kubecost avec :
helm install kubecost kubecost/kubecost \ --namespace kubecost \ --create-namespace \ --values values.yamlL'utilisation d'un fichier de valeurs facilite le versionnement et la reproduction de la configuration pour des paramètres comme le stockage, l'allocation de ressources, le monitoring et les composants Kubecost. Le dépôt officiel de Kubecost recommande également de vérifier la compatibilité entre les versions du chart et de Kubernetes au moment de choisir une release ; par exemple, les charts Kubecost 3.0 ciblent des versions de Kubernetes plus récentes que les dernières versions de Kubecost 2.x.
Chart Helm Kubecost ou manifests Kubernetes
Les charts Helm comme les manifests Kubernetes permettent de déployer des applications sur Kubernetes, mais ils gèrent la configuration différemment. Kubecost recommande Helm comme méthode d'installation principale ; son chart officiel regroupe les ressources requises et expose la configuration via les valeurs Helm.
| Chart Helm Kubecost | Manifests Kubernetes | |
|---|---|---|
| Déploiement | Installe Kubecost comme une release Helm à partir d'un chart packagé. | Les ressources sont appliquées directement avec kubectl apply. |
| Configuration | Les paramètres sont centralisés dans values.yaml ou fournis avec --set. |
La configuration se modifie en éditant chaque définition de ressource YAML. |
| Mises à jour | Helm suit la release et peut appliquer les changements de version de chart et de configuration via helm upgrade. |
Les manifests mis à jour doivent généralement être appliqués et maintenus manuellement. |
| Personnalisation | Les valeurs du chart offrent des options configurables pour les composants, le stockage, Prometheus, les limites de ressources et d'autres paramètres. | Offre un contrôle direct sur chaque objet Kubernetes, mais exige davantage de maintenance manuelle. |
| Reproductibilité | Une version de chart associée à un fichier de valeurs rend le déploiement plus facile à reproduire d'un cluster à l'autre. | Les équipes doivent maintenir et synchroniser elles-mêmes leur collection de manifests. |
| Gestion du cycle de vie | Helm fournit nativement l'installation des releases, les mises à jour, les capacités de rollback et la désinstallation. | Kubernetes gère des ressources individuelles plutôt qu'un cycle de vie de release Helm. |
| Idéal pour | La plupart des déploiements Kubecost, en particulier les environnements qui nécessitent une configuration reproductible et des mises à jour régulières. | Les environnements qui exigent spécifiquement un contrôle direct sur des ressources Kubernetes statiques ou qui ne peuvent pas utiliser Helm. |
Kubecost a historiquement proposé le déploiement par manifests statiques en alternative, mais sa documentation recommande Helm, surtout pour les déploiements en production. Helm facilite également la personnalisation des dépendances et des paramètres (par exemple, le fait que Kubecost utilise ses composants de monitoring embarqués ou l'infrastructure existante) sans maintenir des copies modifiées de chaque ressource Kubernetes.
Bonnes pratiques pour le chart Helm Kubecost
Voici quelques bonnes pratiques à garder à l'esprit lorsque vous utilisez le chart Helm de Kubecost.
1. Figez les versions du chart Helm de Kubecost
Spécifiez une version explicite du chart Kubecost au lieu de laisser Helm installer automatiquement la dernière release disponible. Helm permet de sélectionner une version de chart précise avec l'option --version, tandis que son omission peut entraîner la sélection de la dernière version du chart.
Figer les versions rend les déploiements plus prévisibles et empêche une installation automatisée ou un pipeline CI/CD d'adopter de manière inattendue un chart plus récent dont les valeurs par défaut ou les dépendances auraient changé. Passez en revue les notes de version et les exigences de compatibilité de Kubecost avant de mettre à jour délibérément la version figée.
2. Versionnez les valeurs Helm
Stockez la configuration Kubecost que vous surchargez dans un fichier values.yaml dédié et conservez-le sous contrôle de version. Les valeurs Helm constituent le mécanisme standard pour surcharger les valeurs par défaut du chart, y compris les paramètres des composants applicatifs, du stockage, de l'ingress et d'autres options de déploiement.
Le contrôle de version fournit un historique des changements de configuration et facilite la revue, la reproduction ou l'annulation des déploiements Kubecost. Évitez de placer des identifiants ou d'autres secrets sensibles directement dans un dépôt ; référencez plutôt un mécanisme de gestion des secrets Kubernetes ou externe adapté.
3. Utilisez des fichiers de valeurs distincts selon les environnements
Maintenez des fichiers de valeurs séparés pour le développement, le staging et la production lorsque ces environnements nécessitent des configurations Kubecost différentes. Helm est conçu pour déployer le même chart avec des valeurs différentes, ce qui évite de maintenir des copies distinctes des manifests Kubernetes sous-jacents.
Par exemple, la production peut utiliser des volumes persistants et des allocations de ressources plus importants, tandis qu'un cluster de développement peut se contenter de paramètres plus modestes. Séparer les surcharges propres à chaque environnement réduit aussi le risque d'appliquer accidentellement une configuration de développement en production.
4. Définissez des requests et limits de ressources adaptés
Configurez les requests et limits CPU et mémoire des composants Kubecost en fonction de la taille et de la charge du cluster. Les requests aident Kubernetes à réserver suffisamment de ressources pour les pods Kubecost, tandis que les limits peuvent empêcher certains composants de consommer une capacité excessive du cluster.
Évitez de simplement recopier la même configuration de ressources sur des clusters de tailles très différentes. Surveillez la consommation réelle de ressources de Kubecost après le déploiement et ajustez les valeurs Helm à mesure que le nombre de nœuds, de workloads et de métriques collectées augmente.
5. Configurez un stockage persistant pour la production
Utilisez un stockage persistant pour les composants Kubecost qui doivent conserver leurs données lors des redémarrages ou des replanifications de pods. Le chart de Kubecost expose la configuration des volumes persistants : activation de la persistance, taille du volume et StorageClass Kubernetes utilisée.
Pour les déploiements en production, choisissez une StorageClass fiable et provisionnez suffisamment de capacité pour la croissance attendue des données. Les paramètres de stockage doivent également s'aligner sur les exigences de sauvegarde, de rétention et de reprise après sinistre de l'organisation.
6. Testez les mises à jour Helm avant la production
Appliquez les mises à jour du chart Kubecost dans un cluster de développement ou de staging avant de mettre à jour la production. Testez à la fois la nouvelle version du chart et vos valeurs personnalisées existantes, car les mises à jour de chart peuvent introduire de nouveaux paramètres, modifier des valeurs par défaut ou changer des ressources Kubernetes.
Helm permet de passer en revue et de contrôler les valeurs de mise à jour, et de revenir à une révision antérieure d'une release si nécessaire. Conservez la version précédente du chart et sa configuration afin de disposer d'un chemin de rollback testé si la mise à jour en production pose problème.
Optimiser les coûts Kubernetes au-delà de Kubecost avec PerfectScale
PerfectScale by DoiT offre une optimisation des coûts responsable qui élimine le gaspillage de ressources sans compromettre la stabilité et les performances de Kubernetes. Kubecost se concentre principalement sur le suivi des coûts Kubernetes. PerfectScale va plus loin : il affine en continu votre environnement pour un équilibre optimal entre performance et coûts, et offre une visibilité et une gouvernance renforcées sur les groupes de nœuds, les namespaces, les conteneurs et les workloads. Le chart Helm de Kubecost déploie et maintient Prometheus et les composants de métriques associés. PerfectScale, lui, fonctionne comme un agent stateless unique à l'empreinte minimale, sans nécessiter Prometheus.
Fonctionnalités clés de PerfectScale :
- Optimisation autonome des coûts : affine de manière autonome votre environnement Kubernetes avec des actions intégrées à GitOps, afin que les économies soient appliquées en continu plutôt que simplement affichées sur des dashboards.
- Right-sizing complet : fournit des recommandations CPU et mémoire pour les requests comme pour les limits. Ces recommandations tiennent compte des changements de code et de la configuration HPA.
- Déploiement d'un agent stateless : s'installe comme un agent léger unique avec une maintenance minimale. Aucune implémentation Prometheus à mettre en place ni à maintenir.
- Visibilité et allocation granulaires des coûts : offre la visibilité et l'allocation des coûts, la prévision des coûts et du gaspillage, et la visibilité sur les workloads éphémères. Il affiche également l'allocation, l'utilisation et la capacité inutilisée des nœuds, prend en charge les groupes de nœuds et permet de regrouper les workloads éphémères de manière personnalisée.
- Détection et remédiation des problèmes de résilience : identifie les événements OOM, le throttling CPU, les fuites mémoire suspectées, les redémarrages fréquents, les évictions et les workloads atteignant leurs limites de réplicas. Il fournit aussi une priorisation automatique des risques de résilience, des alertes personnalisables et une remédiation autonome.
- Fonctionne partout où tourne Kubernetes : prend en charge EKS, GKE, AKS, OpenShift et les clusters on-prem.
Prêt à passer du simple suivi des coûts à l'optimisation autonome de Kubernetes ? Découvrez comment PerfectScale se compare à Kubecost et démarrez un essai gratuit de 30 jours.