Benutzerdefinierte Berichte mit dem Metering-Operator

Der Metering-Operator ist ein Chargeback- und Berichterstellungstool, mit dem Sie nachverfolgen können, wie Ressourcen in einem Kubernetes-Cluster genutzt werden. Cluster-Administrations können Berichte basierend auf historischen Nutzungsdaten nach Pod, Namespace und Cluster planen. 

Bei der Installation des Metering-Operators stehen Ihnen zahlreiche, sofort einsatzbereite Berichtsabfragen zur Verfügung. Wenn Admins beispielsweise die CPU-Auslastung oder Arbeitsspeichernutzung für die Cluster-Knoten oder Pods messen möchten, müssen Sie lediglich den Messoperator installieren und eine benutzerdefinierte Ressource vom Typ Report schreiben, um einen Bericht zu erstellen. Dieser kann monatlich, stündlich oder in anderen Abständen ausgelöst werden.

Use Cases

Die folgenden Anforderungen höre ich immer wieder von Kunden: 

1. Die Workerknoten in einem OpenShift-Cluster für nicht produktive Umgebungen werden möglicherweise nicht immer ausgeführt, etwa wenn Workerknoten je nach verfügbarer Kapazität oder an Wochenenden abgeschaltet werden sollen. Daher wollen die Kunden die CPU-Auslastung oder Arbeitsspeicherauslastung eines Knotens monatlich messen, damit das Infrastrukturteam die tatsächliche Knotennutzung von Nutzenden abrechnen kann.
2. Manche Kunden verfügen über ein Deployment-Modell, bei dem sie einen dedizierten OpenShift-Cluster für bestimmte Teams bereitstellen. Sie könnten den Metering-Operator installieren und die Knotennutzung abrufen, möchten jedoch im Chargeback-Bericht angeben, für welche Teams oder Geschäftsbereiche die Workerknoten verwendet werden. Ein ähnlicher Use Case ist die Nutzung eines gemeinsamen dedizierten Clusters mit „gelabelten“ Knoten. Die einzelnen Labels identifizieren dabei, zu welchen Geschäftsbereichen oder Teams die auf dem Knoten ausgeführten Workloads gehören.
3. In einem gemeinsam genutzten Cluster möchte das Operations-Teams die Chargebacks für andere Teams basierend auf der Laufzeit der Pods (wie CPU-Nutzung oder Arbeitsspeicherauslastung) berechnen. Auch hier möchte das Team den Bericht vereinfachen und angeben, zu welchem Team oder Geschäftsbereich die Pods gehören.

Um diese Anforderungen zu erfüllen, müssen einige benutzerdefinierte Ressourcen im Cluster erstellt werden. Wie das ganz einfach geht, erfahren Sie in diesem Artikel. Die Anleitung zur Installation eines Metering-Operators würde den Rahmen dieses Artikels sprengen. Daher finden Sie die Installationsdokumentation hier. In dieser Dokumentation erfahren Sie mehr über die Verwendung der vorkonfigurierten Berichte.

Wie funktioniert Metering?

Sehen wir uns zunächst an, wie Metering in OpenShift funktioniert, bevor wir mit der Erstellung neuer benutzerdefinierter Ressourcen für unseren Use Case fortfahren. Nach der Installation erstellt der Metering-Operator insgesamt 6 benutzerdefinierte Ressourcen. Einige davon müssen etwas genauer erläutert werden. 

1. ReportDataSources (RDS): Dieser Mechanismus definiert, welche Daten verfügbar sind und von benutzerdefinierten Ressourcen vom Typ „ReportQuery“ oder „Report“ verwendet werden können. Auch das Abrufen von Daten aus verschiedenen Quellen ist damit möglich. In OpenShift werden die Daten von Prometheus sowie aus der benutzerdefinierten RQ-Ressourcen (ReportQuery) abgerufen. 
2. ReportQuery (RQ): RQ enthält die SQL-Abfragen, die durchgeführt werden, um eine Analyse der in RDS gespeicherten Daten durchzuführen. Wenn ein Report-Objekt auf ein RQ-Objekt verweist, verwaltet das RQ-Objekt auch, welche Angaben dieses beim Erstellen des Berichts liefert. Wenn das Report-Objekt auf ein RDS-Objekt verweist, erstellt Metering auf Anweisung des RQ-Objekts in den bei der Metering-Installation erstellten Presto-Tabellen eine Ansicht, die auf der gerenderten Abfrage basiert.
3. Report: Diese benutzerdefinierte Ressource bewirkt, dass Berichte mit der konfigurierten RQ-Ressource (ReportQuery) generiert werden. Dies ist die primäre Ressource, mit der Endbenutzende des Metering-Operators interagieren würden. Der Bericht kann so konfiguriert werden, dass er nach einem Zeitplan ausgeführt wird.

Es gibt viele sofort einsatzbereite RDS und RQ. Da wir uns auf die Messung auf Knotenebene konzentrieren, zeige ich, welche davon wir verstehen müssen, um unsere eigenen benutzerdefinierten Abfragen zu schreiben. Führen Sie im Projekt „openshift-metering“ den folgenden Befehl aus:

Da wir die CPU-Nutzung messen wollen, sollten wir uns auf die folgenden beiden RDS konzentrieren: „node-capacity-cpu-cores“ und „node-cpu-capacity-raw“. Fangen wir mit node-capacity-cpu-cores an. Um zu verstehen, wie Daten von Prometheus erfasst werden, führen wir den folgenden Befehl aus:

Sie können die Prometheus-Abfrage beobachten, mit der Daten aus Prometheus abgerufen und in Presto-Tabellen gespeichert werden. Jetzt führen wir dieselbe Abfrage in der Metrikkonsole von OpenShift aus und sehen uns das Ergebnis an. Mein OpenShift-Cluster verfügt über 2 Workerknoten (mit 16 Kernen pro Knoten) und 3 Master-Knoten (mit jeweils 8 Kernen). In der letzten Spalte „value“ werden die den Knoten zugewiesenen Kerne erfasst.

Die Daten werden also in den Presto-Tabellen gesammelt und gespeichert. Sehen wir uns nun einige benutzerdefinierte RQ-Ressourcen (ReportQuery) an:

Wir sollten uns hier auf die rqs „node-cpu-capacity“ und „node-cpu-capacity-raw“ konzentrieren. Sie könnten diese beschreiben und würden herausfinden, dass sie Daten berechnen (wie lange der Knoten aktiv ist, wie viele CPUs zugewiesen sind usw.) und Daten aggregieren. 

Das folgende Diagramm zeigt, das die beiden RDS und die beiden RQS wie in einer Kette verbunden sind.

node-cpu-capacity (RQ) verwendet node-cpu-capacity-raw (RDS) verwendet node-cpu-capacity-raw (RQ) verwendet node-capacity-cpu-cores (RDS)

Anpassen von Berichten

Jetzt befassen wir uns damit, wie wir benutzerdefinierte RDS und RQS schreiben. Zuerst müssen wir die Prometheus-Abfrage ändern, damit sie angibt, ob der Knoten als Master- oder Workerknoten fungiert. Außerdem wird ein entsprechendes Knoten-Label eingefügt, das identifiziert, zu welchem Team der Knoten gehört. Die Prometheus-Metrik „kube_node_role“ hat die Knoten-Rolle wrt (als Master oder Worker). Sehen Sie sich dazu die Spalte „role“ an:

Die Prometheus-Metrik „kube_node_labels“ erfasst die Labels, die auf einen Knoten angewendet werden. Alle Labels werden als „label_“ erfasst. Wenn ich also ein Label mit dem Schlüssel „node_lob“ auf einen Knoten anwende, werden die Daten durch die Prometheus-Metrik als „label_node_lob“ erfasst. 

Jetzt müssen wir nur noch die ursprüngliche Abfrage mit diesen zusätzlichen Prometheus-Abfragen ändern, um relevante Daten zu erhalten. Die Abfrage sieht so aus:

((kube_node_status_capacity_cpu_cores * on(node) group_left(provider_id) max(kube_node_info) by (node, provider_id)) * on(node) group_left (role) kube_node_role{role='worker'}) * on(node) group_right(provider_id, role) kube_node_labels

Wir führen die Abfrage in der Metrik-Konsole aus und verifizieren, dass sowohl das Label (node_lob) als auch die Rolleninformationen abgerufen wurden. Unten sehen Sie „label_node_lob“ als Ausgabe und als Rolle. Die Rolleninformationen werden dabei nicht angezeigt, da die Abfrage sehr viele Spalten ausgibt. Sie werden aber erfasst.

Wir schreiben also 4 benutzerdefinierte Ressourcen. Der Einfachheit halber habe ich diese benutzerdefinierten Ressourcen hier hochgeladen:

1. rds-custom-node-capacity-cpu-cores.yaml: Definiert die Prometheus-Abfrage.
2. rq-custom-node-cpu-capacity-raw.yaml: Referenziert die obige RDS und berechnet Rohdaten.
3. rds-custom-node-cpu-capacity-raw.yaml: Referenziert die obige RQ und erstellt eine Ansicht in Presto.
4. rq-custom-node-cpu-capacity-with-cpus-labels.yaml: Referenziert die unter 3 erwähnte RDS und berechnet Daten anhand der eingegebenen Start- und Enddaten. Dies ist auch die Datei, aus der die Spalten „role“ und „node_label“ abgerufen werden.

Nachdem Sie diese YAML-Dateien geschrieben haben, wechseln Sie zum Projekt „openshift-metering“, wo Sie die folgenden Befehle ausführen:

Jetzt müssen Sie nur noch ein benutzerdefiniertes Report-Objekt schreiben, das auf das letzte, oben erstellte RQ-Objekt verweist. Unten finden Sie ein Beispiel. Der folgende Bericht wird sofort erstellt und zeigt Daten vom 15. bis 30. September.

Nachdem Sie diesen Bericht ausgeführt haben, können Sie die Datei (im Format csv oder json) über diese URL herunterladen (ändern Sie den DOMAIN-NAMEN entsprechend):

https://metering-openshift-metering.DOMAIN_NAME/api/v1/reports/get?name=custom-role-node-cpu-capacity-hourly&namespace=openshift-metering&format=csv

Der folgende CSV-Snapshot zeigt die erfassten Daten, die sowohl die Rolle „role“ als auch die Spalte „node_lob“ enthalten. Die Spalte „node_capacity_cpu_core_seconds“ muss durch „node_capacity_cpu_cores“ geteilt werden, um die Laufzeit des Knotens in Sekunden anzuzeigen:

Zusammenfassung

Der Metering-Operator ist ziemlich cool und kann unabhängig von seiner Umgebung auf OpenShift-Clustern ausgeführt werden. Da die Lösung ein erweiterbares Framework bietet, können Kunden ihre eigenen benutzerdefinierten Ressourcen schreiben und so Berichte anhand ihrer Anforderungen erstellen. Der gesamte oben verwendete Code ist hier verfügbar.