Kubecost Helm-Chart: 2.x vs. 3.x, Installation und 6 Best Practices

Was ist das Kubecost Helm-Chart?

Sie können Kubecost über das offizielle Helm-Chart aus dem cost-analyzer-Repository installieren. Dieses Chart ist ein Paket, um Kubecost mit Helm in einem Kubernetes-Cluster bereitzustellen. Es definiert die Kubernetes-Ressourcen, die Kubecost benötigt, etwa Deployments, Services, Konfiguration und zugehörige Komponenten. Helm verwaltet diese Ressourcen als ein einziges Release, wodurch sich Kubecost einfacher installieren, aktualisieren, konfigurieren und entfernen lässt.

Was das Chart enthält:

Das Kubecost Helm-Chart bündelt die Kubernetes-Ressourcen und konfigurierbaren Abhängigkeiten, die für den Betrieb von Kubecost erforderlich sind. Je nach konfigurierten Values kann das Kubecost-Anwendungskomponenten, die Prometheus-Integration, Kubernetes-Metrik-Komponenten, persistenten Storage, Services und Ingress, Monitoring-Ressourcen, die Erfassung von Netzwerkkosten, Network Policies sowie Pricing-Integrationen der Cloud-Anbieter umfassen.

Best Practices für die Konfiguration:

• Kubecost Helm-Chart-Versionen pinnen: Geben Sie eine explizite Chart-Version an, um Deployments vorhersehbar zu halten und unerwartete Änderungen durch neuere Releases zu vermeiden.
• Helm-Values in der Versionskontrolle pflegen: Legen Sie Konfigurations-Overrides in einer versionierten values.yaml-Datei ab und halten Sie Zugangsdaten und andere Secrets aus dem Repository heraus.
• Separate Values-Dateien für verschiedene Umgebungen verwenden: Pflegen Sie umgebungsspezifische Konfigurationen für Entwicklung, Staging und Produktion, statt Chart-Manifeste zu duplizieren oder zu verändern.
• Passende Resource Requests und Limits setzen: Dimensionieren Sie die CPU- und Speichereinstellungen der Kubecost-Komponenten entsprechend der Clustergröße und passen Sie sie anhand des beobachteten Ressourcenverbrauchs an.
• Persistenten Storage für die Produktion konfigurieren: Wählen Sie eine geeignete Kapazität für Persistent Volumes und eine zuverlässige StorageClass auf Basis Ihrer Anforderungen an Aufbewahrung, Wachstum, Backup und Wiederherstellung.
• Helm-Upgrades vor der Produktion testen: Validieren Sie neue Chart-Versionen und bestehende eigene Values in einer Nicht-Produktionsumgebung und halten Sie einen getesteten Rollback-Pfad bereit.

In diesem Artikel:

• Die zwei Kubecost Helm-Charts: cost-analyzer vs. kubecost
• Was das Helm-Chart enthält
• So installieren Sie Kubecost mit Helm
• Kubecost Helm-Chart vs. Kubernetes-Manifeste
• Best Practices für das Kubecost Helm-Chart

Die zwei Kubecost Helm-Charts: cost-analyzer vs. kubecost

Kubecost hat inzwischen zwei Helm-Chart-Linien, denen Administratoren begegnen können: das ältere cost-analyzer-Chart für Kubecost-2.x-Deployments und das neuere kubecost-Chart, das mit Kubecost 3.x eingeführt wurde. Das aktuelle Kubecost-Repository weist Version 2.8 als letztes Feature-Release der 2.x-Linie aus, Version 2.9 als Zwischenschritt für das Upgrade und Version 3.0 als erstes Kubecost-3.x-Release.

Das cost-analyzer-Chart ist die Legacy-Deployment-Methode, die durchgängig in Kubecost 2.x verwendet wurde. Bestehende Umgebungen referenzieren möglicherweise weiterhin Befehle wie kubecost/cost-analyzer, und Kubecost pflegt für ältere Deployments und Upgrade-Szenarien nach wie vor die zugehörigen Repositories.

Für Kubecost 3.x heißt das primäre Chart nun kubecost. Neue Installationen nutzen das Chart kubecost/kubecost aus dem Kubecost-Helm-Repository. Kubecost 3.x bringt zudem erhebliche Architekturänderungen mit, darunter ClickHouse-basierten Storage und einen neuen finops-agent, der den bisherigen cost-model-Agent aus 2.x ersetzt.

Organisationen, die ein bestehendes Kubecost-2.x-Deployment aktualisieren, sollten den Wechsel daher nicht als bloße Umbenennung des Charts behandeln. Kubecost empfiehlt, die Agents vor dem Wechsel zu 3.x zunächst auf Version 2.9 zu aktualisieren und die Zwischenversion eine Zeit lang laufen zu lassen, bevor die Migration abgeschlossen wird. Bestehende cost-analyzer-Values sollten außerdem geprüft werden, statt anzunehmen, dass sie sich direkt auf das neue kubecost-Chart übertragen lassen – denn Komponentennamen, Storage-Architektur und Konfigurationsoptionen haben sich geändert.

Was das Helm-Chart enthält

Das Kubecost Helm-Chart enthält die Kubernetes-Templates und konfigurierbaren Abhängigkeiten, die für den Betrieb von Kubecost erforderlich sind. Welche Ressourcen genau bereitgestellt werden, hängt von der Chart-Version und den aktivierten Values ab, in der Regel deckt das Chart jedoch folgende Komponenten ab:

• Kubecost-Anwendungskomponenten: Deployments, Services, ConfigMaps, Secrets, Service Accounts und weitere Ressourcen, die für den Betrieb von Kubecost und seine Funktionen zum Kosten-Monitoring erforderlich sind.
• Metrik-Erfassung (finops-agent): Das Chart stellt den finops-agent bereit, einen schlanken Agent, der die Cluster-Metriken erfasst, die Kubecost für die Kostenzuordnung nutzt – ohne separates Prometheus-Deployment.
• Kubernetes-Metrik-Komponenten: Je nach Konfiguration kann das Chart unterstützende Komponenten wie kube-state-metrics und den Node Exporter bereitstellen, die Metriken zu Kubernetes-Objekten und Nodes liefern.
• Persistenter Storage: Über Helm-Values lassen sich Persistent Volume Claims für Kubecost- und Prometheus-Daten anlegen, mit konfigurierbaren Speichergrößen und StorageClasses.
• Ingress- und Service-Konfiguration: Das Chart bietet Einstellungen, um Kubecost über Kubernetes Services verfügbar zu machen – und, wenn aktiviert, über einen Ingress mit konfigurierbaren Hosts, Pfaden, Annotations und TLS-Einstellungen.
• Monitoring-Ressourcen: Optionale Ressourcen wie ServiceMonitor und PrometheusRule können für Umgebungen mit dem Prometheus Operator erstellt werden.
• Optionale Features und Integrationen: Über Helm-Values lassen sich zusätzliche Funktionen wie die Erfassung von Netzwerkkosten, Network Policies, Pricing-Integrationen der Cloud-Anbieter und weitere Kubecost-Features aktivieren – ohne die generierten Kubernetes-Manifeste manuell zu verändern.

Da diese Komponenten über die values.yaml des Charts gesteuert werden, können Organisationen gezielt nur die benötigten Ressourcen aktivieren oder Kubecost in bereits vorhandene Monitoring- und Infrastrukturkomponenten im Cluster integrieren.

Passender Lesetipp: Unser Leitfaden zur Kubernetes-Kostenoptimierung

So installieren Sie Kubecost mit Helm

Kubecost lässt sich mit Helm installieren, indem Sie das offizielle Kubecost-Chart-Repository hinzufügen und das Chart in einem dedizierten Namespace bereitstellen. Das aktuelle Helm-Chart-Repository von Kubecost stellt das Chart kubecost/kubecost für Kubecost 3.x bereit.

Fügen Sie zunächst das Kubecost-Helm-Repository hinzu und aktualisieren Sie Ihren lokalen Chart-Index:

helm repo add kubecost https://kubecost.github.io/kubecost/
helm repo update

Installieren Sie Kubecost anschließend in einem kubecost-Namespace:

helm install kubecost kubecost/kubecost \
  --namespace kubecost \
  --create-namespace

Kubecost unterstützt auch die Installation direkt über die Repository-URL. Das offizielle Beispiel setzt global.clusterId, um den Cluster zu identifizieren:

helm install kubecost \
  --repo https://kubecost.github.io/kubecost kubecost \
  --namespace kubecost \
  --create-namespace \
  --set global.clusterId=my-cluster

Vor dem Deployment in die Produktion können Sie die von einer bestimmten Chart-Version unterstützten Values einsehen:

helm show values kubecost/kubecost --version <chart-version>

Anschließend können Sie die benötigte Konfiguration in einer eigenen values.yaml-Datei ablegen und Kubecost so installieren:

helm install kubecost kubecost/kubecost \
  --namespace kubecost \
  --create-namespace \
  --values values.yaml

Eine Values-Datei erleichtert es, Konfigurationen für Storage, Ressourcenzuweisung, Monitoring und Kubecost-Komponenten zu versionieren und zu reproduzieren. Das offizielle Kubecost-Repository empfiehlt außerdem, bei der Wahl eines Releases die Kompatibilität von Chart- und Kubernetes-Version zu prüfen; so zielen die Kubecost-3.0-Charts beispielsweise auf neuere Kubernetes-Versionen ab als die letzten Kubecost-2.x-Releases.