🥇Überblick über Kubecost zur Kostenersparnis in Kubernetes-Clouds

Derzeit migrieren immer mehr Unternehmen ihre Infrastruktur von physischen Servern und eigenen virtuellen Maschinen in die Cloud. Diese Entscheidung lässt sich leicht erklären: Es ist nicht nötig, sich um die Hardware zu kümmern, der Cluster lässt sich auf viele verschiedene Arten konfigurieren… und das Wichtigste ist, dass die verfügbaren Technologien (wie Kubernetes) eine einfache Skalierung der Rechenleistung je nach Last ermöglichen.

Auch der finanzielle Aspekt ist immer wichtig. Das Tool, über das in diesem Artikel die Rede sein wird, soll dazu beitragen, Budgets bei der Nutzung von Cloud-Infrastrukturen mit Kubernetes zu reduzieren.

Einführung

Kubecost — ein kalifornisches Start-up von ehemaligen Google-Mitarbeitern, das eine Lösung zur Kostenkontrolle von Infrastrukturen in Cloud-Diensten (innerhalb des Kubernetes-Clusters + gemeinsame Ressourcen) entwickelt, Engpässe in den Cluster-Einstellungen aufspürt und entsprechende Benachrichtigungen an Slack sendet.

Wir haben Kunden mit Kubernetes sowohl in den gängigen Clouds AWS und GCP als auch im weniger verbreiteten Azure für die Linux-Community — kurz gesagt, auf allen von Kubecost unterstützten Plattformen. Für einige von ihnen berechnen wir die Kosten für intra-cluster Dienste selbst (nach einer Methode, die der von Kubecost ähnelt), und wir überwachen die Infrastrukturkosten und versuchen, sie zu optimieren. Daher war es naheliegend, dass wir an der Möglichkeit interessiert waren, 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 genutzt werden, und die verfügbaren Funktionen sollten für kleine Projekte ausreichend sein. Aber Geschäft ist Geschäft: Der restliche Teil des Produkts ist geschlossen, darauf kann man zugreifen durch bezahlte Abonnements, die auch kommerzielle Unterstützung beinhalten. Darüber hinaus bieten die Autoren eine kostenlose Lizenz für kleine Cluster an (1 Cluster mit 10 Knoten — zum Zeitpunkt des Schreibens dieses Artikels wurde dieses Limit auf 20 Knoten erhöht) oder einen Testzeitraum mit vollem Funktionsumfang für 1 Monat.

Wie alles funktioniert

Das Hauptteil von Kubecost ist also eine Anwendung cost-model, die in Go geschrieben ist. Das Helm-Diagramm, das das gesamte System beschreibt, heißt cost-analyzer und ist im Wesentlichen eine Sammlung von cost-model mit Prometheus, Grafana und mehreren Dashboards.

Im Allgemeinen hat das Cost-Modell eine eigene Web-Oberfläche, die Diagramme und detaillierte Statistiken zu den Ausgaben in tabellarischer Form anzeigt, sowie natürlich Tipps zur Optimierung der Kosten. Die in Grafana präsenten Dashboards sind ein früherer Entwicklungsstand von Kubecost und enthalten weitgehend dieselben Daten wie das Cost-Modell, ergänzt durch die gewohnte Statistik zu CPU-/RAM-/Netz-/Festplattenspeicherverbrauch im Cluster und seinen Komponenten.

Wie funktioniert Kubecost?

Das Cost-Modell erhält über die API von Cloud-Anbietern die Kosten für den Betrieb.
Anschließend wird, je nach Hardwaretyp des Knotens und Region, die Kosten pro Knoten berechnet.
Basierend auf den Kosten für die Arbeit der Knoten erhält jeder einzelne Pod die Kosten pro Stunde für die Nutzung der CPU, den Verbrauch eines Gigabytes RAM und die Kosten für die Stunde der Speicherung eines Gigabytes Daten — abhängig von dem Knoten, auf dem er gearbeitet hat, oder der Speicherkategorie.
Ausgehend von den Kosten einzelner Pods wird die Zahlung pro Namespaces, Diensten, Deployments, StatefulSets berechnet.
Für die Berechnung der Statistiken werden Metriken verwendet, die von kube-state-metrics und node-exporter bereitgestellt werden.

Es ist wichtig zu beachten, dass Kubecost standardmäßig nur die 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 sich in derselben Cloud befinden), sind für ihn nicht sichtbar. Zwar können für GCP und AWS die Schlüssel der eigenen Dienstkonto hinzugefügt werden, um alles zusammen zu berechnen.

Installation

Für die Funktionsweise von Kubecost sind erforderlich:

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

Es kam so, dass in unseren Clustern all diese Bedingungen bereits erfüllt waren, sodass es ausreichend war, nur den richtigen Endpunkt 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 Weise installiert werden:

Auf die Standardinstallation, die auf Anleitung der Website des Entwicklers beschrieben ist. Es ist notwendig, das Helm-Repository cost-analyzer hinzuzufügen, danach das Chart zu installieren. Es bleibt nur noch, sich den Port durchzureichen und die Einstellungen manuell (über kubectl) und/oder mit der Weboberfläche des Cost-Modells in den gewünschten Zustand zu bringen.
Diese Methode haben wir nicht getestet, da wir keine externen vorkonfigurierten Lösungen verwenden, aber sie scheint eine gute Option zu sein, „einfach selbst auszuprobieren“. Wenn Sie bereits Teile der Komponenten des Systems installiert haben oder eine detailliertere Anpassung wünschen, sollten Sie den zweiten Weg in Betracht ziehen.
Im Wesentlichen verwenden das gleiche Chart, aber es selbst konfigurieren und installieren auf jede erdenkliche Weise.
Wie bereits erwähnt, enthält dieses Chart neben kubecost selbst auch die Charts von Grafana und Prometheus, die ebenfalls nach Ihren Wünschen konfiguriert werden können.
Das im Chart enthaltene values.yaml für den Cost-Analyzer ermöglicht die Konfiguration von:
- der Liste der Komponenten des Cost-Analyzers, die bereitgestellt werden sollen;
- Ihrem Endpoint für Prometheus (sofern Sie bereits einen haben);
- Domains und andere Ingress-Einstellungen für das Cost-Model und Grafana;
- Annotationen für Pods;
- die Notwendigkeit der Verwendung von Persistent Storage und deren Größe.
Eine vollständige Liste der verfügbaren Konfigurationsoptionen mit Beschreibungen finden Sie in Dokumentation.
Da kubecost in der Basisversion keinen Zugriff einschränken kann, muss sofort Basic-Auth für das Web-Panel konfiguriert werden.
Installieren nur das Kernsystem — cost-model. Dafür ist es notwendig, dass Prometheus im Cluster installiert ist und die entsprechende Adresse in der Variable prometheusEndpoint für Helm angegeben ist. Danach muss ein Satz von YAML-Konfigurationen angewendet werden. im Cluster.
Wie bereits erwähnt, müssen Sie manuell Ingress mit Basic-Auth hinzufügen. Schließlich müssen Sie auch einen Abschnitt für das Sammeln von Metriken des Cost-Models in extraScrapeConfigs in der Prometheus-Konfiguration hinzufü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 steht uns das Webpanel von kubecost und Grafana mit einer Sammlung von Dashboards zur Verfügung.

Gesamtkosten, die auf dem Hauptbildschirm angezeigt wird, zeigt faktisch die kalkulierten Kosten der Ressourcen für einen Monat an. Dies ist ein geschätzter Preis, der die Kosten der Nutzung des Clusters (pro Monat) bei aktuellem Ressourcenverbrauch anzeigt.

Diese Metrik dient eher der Analyse und Optimierung der Ausgaben. Die Gesamtausgaben für einen hypothetischen Juli in kubecost zu betrachten, ist nicht sehr praktisch: Dafür müssen Sie ins Billing gehen.Sie können jedoch die Ausgaben nach Namespaces, Labels und Pods für 1/2/7/30/90 Tage aufschlüsseln, was Ihnen das Billing nie anzeigen wird.

Übrigens über Labels. Gehe am besten gleich in die Einstellungen und lege die Bezeichnungen der Labels fest, die als zusätzliche Kategorien zur Gruppierung der Ausgaben verwendet werden sollen:

Es können beliebige Labels angehängt werden - praktisch, wenn Sie bereits ein eigenes Markierungssystem haben.

Dort kann auch die Adresse des API-Endpunkts geändert werden, zu dem sich das Cost-Model verbindet, die Rabattgröße in GCP angepasst werden und eigene Preise für Ressourcen und deren Währungsumrechnung festgelegt werden (seltsamerweise hat die Funktion keinen Einfluss auf die Gesamtkosten).

Kubecost kann verschiedene Probleme im Cluster (und sogar Alarm schlagen, wenn Gefahr besteht). Leider ist die Option nicht konfigurierbar, sodass - wenn Sie Entwicklerumgebungen haben, die genutzt werden, - Sie ständig etwas Ähnliches beobachten können:

Ein wichtiges Werkzeug - Cluster Savings. Es misst die Aktivität der Pods (Ressourcenverbrauch, einschließlich Netzwerk) und berechnet, wie viel Geld und wo gespart werden kann.

Es mag erscheinen, dass die Optimierungstipps recht offensichtlich sind, jedoch zeigt die Erfahrung, dass es trotzdem einiges zu beachten gibt. Insbesondere wird die Netzwerkaktivität der Pods überwacht (Kubecost empfiehlt, auf inaktive zu achten), der angeforderte und der tatsächliche Speicher- und CPU-Verbrauch verglichen sowie die von den Clusterknoten verwendete CPU (es wird empfohlen, mehrere Knoten zusammenzulegen), die Last auf den Festplatten und noch ein paar Dutzend weitere Parameter.

Wie bei jeder Frage zur Optimierung sollten die Ressourcenoptimierung auf Basis der Daten von Kubecost mit Vorsicht behandelt werden. Zum Beispiel schlägt Cluster Savings vor, Knoten zu entfernen und behauptet, dass dies sicher sei, berücksichtigt jedoch nicht das Vorhandensein von Node-Selectoren und Taints bei den auf diesen verteilten Pods, die auf anderen Knoten nicht vorhanden sind. Und überhaupt empfehlen sogar die Autoren des Produkts in ihrer einem kürzlichen Artikel (übrigens kann sie für diejenigen, die sich für das Projekt interessieren, sehr nützlich sein) nicht, sich Hals über Kopf auf die Kostenoptimierung zu stürzen, sondern die Angelegenheit durchdacht anzugehen.

Ergebnisse

Nach einem Monat Nutzung von Kubecost in ein paar Projekten können wir festhalten, dass es ein interessantes (und zudem leicht zu bedienendes und zu installierendes) Tool zur Analyse und Optimierung der Ausgaben für Cloud-Dienste ist, die für Kubernetes-Cluster verwendet werden. Die Berechnungen sind sehr genau: In unseren Experimenten stimmten sie mit den tatsächlichen Anforderungen der Anbieter überein.

Es gab auch einige Nachteile: Es gibt einige nicht kritische Bugs, und die funktionalen Möglichkeiten decken in einigen Fällen die spezifischen Anforderungen mancher Projekte nicht ab. Wenn Sie jedoch schnell verstehen möchten, wohin das Geld fließt und was man "einsparen" kann, um die Kosten für Cloud-Dienste stabil um 5-30 % zu senken (so war es in unserem Fall), dann ist dies eine ausgezeichnete Wahl.