🥇Überblick über Kubecost zur Kostenersparnis bei Kubernetes in der Cloud

Immer mehr Unternehmen verlagern derzeit ihre Infrastruktur von physischen Servern und eigenen virtuellen Maschinen in die Cloud. Diese Entscheidung lässt sich leicht erklären: Man muss sich nicht um die Hardware kümmern, Cluster können auf viele verschiedene Arten einfach konfiguriert werden… und das Wichtigste ist, dass vorhandene Technologien (wie Kubernetes) eine einfache Skalierung der Rechenleistung je nach Last ermöglichen.

Auch der finanzielle Aspekt ist immer wichtig. Das Werkzeug, über das in diesem Artikel gesprochen wird, soll dazu beitragen, die Budgets bei der Nutzung cloudbasierter Infrastruktur mit Kubernetes zu reduzieren.

Einführung

Kubecost — ein kalifornisches Start-up von ehemaligen Google-Mitarbeitern, das eine Lösung zur Kostenberechnung für die Infrastruktur in Cloud-Services entwickelt (innerhalb des Kubernetes-Clusters + gemeinsame Ressourcen), die Engpässe in den Cluster-Einstellungen identifiziert und entsprechende Benachrichtigungen an Slack sendet.

Wir haben Kunden, die Kubernetes sowohl in den gängigen Clouds AWS und GCP als auch in dem für die Linux-Community weniger verbreiteten Azure nutzen — im Allgemeinen auf allen Plattformen, die von Kubecost unterstützt werden. Für einige von ihnen berechnen wir die Kosten für interne Cluster-Services selbst (nach einer Methode, die der von Kubecost ähnelt), und achten darauf, die Ausgaben für die Infrastruktur zu überwachen und zu optimieren. Daher liegt es nahe, dass wir an der Möglichkeit interessiert sind, solche Aufgaben zu automatisieren.

Der Quellcode des Hauptmoduls von Kubecost ist unter einer Open-Source-Lizenz (Apache License 2.0) verfügbar. Er kann frei verwendet werden, und die verfügbaren Funktionen sollten für kleine Projekte ausreichend sein. Doch das Geschäft ist das Geschäft: Der restliche Teil des Produkts ist geschlossen und kann durch kostenpflichtige Abonnements, die auch kommerzielle Unterstützung beinhalten, genutzt werden. Darüber hinaus bieten die Entwickler eine kostenlose Lizenz für kleine Cluster an (1 Cluster mit 10 Knoten — zum Zeitpunkt der Erstellung dieses Artikels wurde dieses Limit auf 20 Knoten erhöht) oder einen Testzeitraum mit vollen Möglichkeiten von 1 Monat.

Wie alles organisiert ist

Die Hauptkomponente von Kubecost ist also die Anwendung cost-model, geschrieben in Go. Das Helm-Chart, das das gesamte System beschreibt, heißt cost-analyzer und ist im Grunde genommen eine Zusammenstellung aus cost-model mit Prometheus, Grafana und mehreren Dashboards.

Im Allgemeinen hat cost-model eine eigene Weboberfläche, die Grafiken und detaillierte Statistiken zu den Kosten in Tabellenform anzeigt, sowie natürlich Vorschläge zur Kostenoptimierung. Die in Grafana präsentierten Dashboards sind ein früherer Entwicklungsstand von Kubecost und enthalten zu einem großen Teil die gleichen Daten wie das cost-model, ergänzt durch die üblichen Statistiken zu CPU-/Speicher-/Netz-/Festplattenspeicherverbrauch im Cluster und seinen Komponenten.

Wie funktioniert Kubecost?

Das Cost-Model erhält über die API der Cloud-Anbieter die Preise für den Service.
Anschließend wird die Kostenberechnung je nach Hardwaretyp des Knotens und Region durchgeführt.
Basierend auf den Kosten der Knoten erhält jeder End-Pod die Kosten pro Stunde für die Nutzung der CPU, den Verbrauch eines Gigabytes Speicher sowie die Kosten pro Stunde für die Speicherung eines Gigabytes Daten — abhängig von dem Knoten, auf dem er lief, oder der Speicherklasse.
Die Kosten für die Nutzung einzelner Pods werden basierend auf Namespaces, Diensten, Deployments und StatefulSets berechnet.
Für die statistische Erfassung kommen Metriken zum Einsatz, die von kube-state-metrics und node-exporter bereitgestellt werden.

Es ist wichtig zu beachten, dass Kubecost standardmäßig nur Ressourcen berücksichtigt, die in Kubernetes verfügbar sind. Externe Datenbanken, GitLab-Server, S3-Speicher und andere Dienste, die nicht im Cluster vorhanden sind (auch wenn sie im selben Cloud-Umfeld sind), sind für ihn nicht sichtbar. Für GCP und AWS können jedoch Schlüssel für die eigenen Service-Accounts hinzugefügt werden, um alles zusammen zu berechnen.

Installation von

Für den Betrieb von Kubecost sind folgende Voraussetzungen erforderlich:

Kubernetes Version 1.8 oder höher;
kube-state-metrics;
Prometheus;
node-exporter.

Glücklicherweise sind all diese Bedingungen in unseren Clustern bereits erfüllt, weshalb es ausreichend war, lediglich den richtigen Endpoint für den Zugriff auf Prometheus anzugeben. Dennoch enthält das offizielle Helm-Chart von kubecost alles Notwendige, um auch auf einem "nackten" Cluster zu starten.

Kubecost kann auf verschiedene Arten installiert werden:

Die Standardinstallationsmethode wird beschrieben in Anleitung auf der Website des Entwicklers. Es ist erforderlich, das Helm-Repository cost-analyzer hinzuzufügen und anschließend das Chart zu installieren.. Sie müssen nur den Port durchreichen und die Einstellungen manuell (über kubectl) und/oder über die Weboberfläche des cost-models anpassen.
Diese Methode haben wir nicht getestet, da wir keine externen Konfigurationen verwenden, aber es scheint eine gute Option zu sein, um „einfach selbst auszuprobieren“. Wenn Sie bereits Teile der Systemkomponenten installiert haben oder eine detailliertere Anpassung wünschen, sollten Sie den zweiten Weg in Betracht ziehen.
Verwenden Sie im Grunde das gleiche Chart, aber konfigurieren und installieren Sie es selbst auf eine Ihnen genehme Weise.
Wie bereits erwähnt, enthält dieses Chart neben dem eigentlichen kubecost auch die Charts von Grafana und Prometheus, die ebenfalls nach Ihren Wünschen angepasst werden können.
Das im Chart enthaltene values.yaml für den cost-analyzer ermöglicht die Anpassung von:
- der Liste der Komponenten des cost-analyzers, die bereitgestellt werden sollen;
- Ihrem Endpoint für Prometheus (sofern Sie bereits einen haben);
- Domains und weitere Ingress-Einstellungen für das cost-model und Grafana;
- Annotationen für Pods;
- die Notwendigkeit der Verwendung von persistenten Speichern und deren Größe.
Eine vollständige Liste der verfügbaren Konfigurationsoptionen mit Beschreibungen finden Sie in Dokumentation..
Da kubecost in der Grundversion keinen Zugriff einschränken kann, muss immediately basic-auth für das Web-Panel eingerichtet werden.
Installieren nur der Systemkern — cost-model. Dafür muss Prometheus im Cluster installiert sein und die entsprechende Adresse in der Variablen prometheusEndpoint für Helm angegeben werden. Danach müssen die YAML-Konfigurationssets im Cluster angewendet werden.
Wiederum muss manuell ein Ingress mit basic-auth hinzugefügt werden. Schließlich ist es notwendig, einen Abschnitt zur Erfassung der Metriken des cost-model in extraScrapeConfigs in der Prometheus-Konfiguration hinzuzufügen:
```
- 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
```

Was erhalten wir?

Bei einer vollständigen Installation stehen uns das Web-Panel von kubecost und Grafana mit einer Reihe von Dashboards zur Verfügung.

Gesamtkosten, die auf dem Hauptbildschirm angezeigt werden, zeigen tatsächlich die berechneten Kosten der Ressourcen für den Monat an. Dies ist der prognostizierte Preis, der die Kosten für die Nutzung des Clusters (pro Monat) bei der aktuellen Ressourcennutzung anzeigt.

Diese Metrik dient mehr zur Analyse der Ausgaben und deren Optimierung. Die Gesamtausgaben für den abstrakten Juli in kubecost zu betrachten, ist nicht sehr praktisch: dafür muss man ins Billing gehen. Stattdessen kann man die Ausgaben nach Namespaces, Labels und Pods für 1/2/7/30/90 Tage betrachten, was Ihnen das Billing niemals zeigen wird.

Apropos Labels. Es ist ratsam, sofort in die Einstellungen zu gehen und die Namen der Labels festzulegen, die als zusätzliche Kategorien zur Gruppierung der Kosten verwendet werden sollen:

Sie können beliebige Labels verwenden — das ist praktisch, wenn Sie bereits ein eigenes Markierungssystem haben.

Dort können Sie auch die API-Endpunkt-Adresse ändern, mit der das Kostenmodell verbunden ist, die Rabattgröße in GCP einstellen und eigene Preise für Ressourcen und Währungen zur Messung festlegen (diese Funktion hat aus irgendeinem Grund keinen Einfluss auf die Gesamtkosten).

Kubecost kann verschiedene Probleme im Cluster anzeigen (und sogar bei Gefahr alarmieren). Leider ist diese Option nicht konfigurierbar, daher können Sie, wenn Sie Entwicklerumgebungen haben und diese genutzt werden, ständig etwas Ähnliches beobachten:

Ein wichtiges Werkzeug — Cluster-Einsparungen. Es misst die Aktivität der Pods (Ressourcennutzung, einschließlich Netzwerk), und berechnet auch, wie viel Geld und wofür eingespart werden kann.

Es mag scheinen, dass die Optimierungstipps recht offensichtlich sind, jedoch zeigt die Erfahrung, dass es dennoch einiges zu beachten gibt. Insbesondere wird die Netzwerkaktivität der Pods überwacht (Kubecost empfiehlt, auf inaktive Pods zu achten), der angeforderte und tatsächliche Speicher- sowie CPU-Verbrauch wird verglichen, ebenso wie die CPU-Nutzung durch die Knoten des Clusters (es wird empfohlen, einige Knoten zusammenzuführen), die Belastung der Festplatten und eine Handvoll weiterer Parameter.

Wie bei jedem Thema der Optimierung sollte die Ressourcenoptimierung basierend auf den Daten von Kubecost mit Vorsichtangegangen werden. Zum Beispiel schlägt Cluster Savings vor, Knoten zu entfernen, indem behauptet wird, dass dies sicher sei, jedoch berücksichtigt es nicht die Existenz von Node-Selectors und Taint-Einstellungen, die bei den darauf bereitgestellten Pods vorhanden sind und bei anderen Knoten fehlen. Und überhaupt, selbst die Autoren des Produkts einem kürzlichen Artikel (übrigens kann sie sehr hilfreich sein für diejenigen, die sich für das Thema des Projekts interessieren) empfehlen, nicht kopflos in die Kostenoptimierung zu springen, sondern die Angelegenheit überlegt anzugehen.

Ergebnisse

Nach einem Monat Nutzung von kubecost in einigen Projekten können wir festhalten, dass es ein interessantes (und zudem leicht zu erlernendes sowie zu installierendes) Tool zur Analyse und Optimierung der Ausgaben für Cloud-Anbieter, die für Kubernetes-Cluster verwendet werden, ist. Die Berechnungen sind recht genau: In unseren Experimenten stimmten sie mit dem überein, was die Anbieter tatsächlich verlangten.

Es gab jedoch auch einige Nachteile: Es gibt einige kleinere Bugs, und die Funktionalitäten decken nicht immer die spezifischen Anforderungen einiger Projekte ab. Wenn man jedoch schnell verstehen möchte, wohin das Geld fließt und was man "kürzen" kann, um die Rechnung für Cloud-Dienste stabil um 5-30 % zu senken (was in unserem Fall tatsächlich auch so war), ist es eine hervorragende Option.