Das Problem beginnt mit einem klaren betrieblichen Widerspruch: In der Adobe-Umgebung wurden GPU-Nutzungsdaten jede Sekunde in einem zentralen Prometheus gesammelt, doch die Teams, die die Kosten dieser GPUs tragen, konnten ihre Metriken nicht direkt einsehen. Laut den Ingenieuren Bingi Narasimha Karthik und Ramkumar Nagaraj führte dies zur Entdeckung einer GPU, die 11 Tage lang eine Auslastung von null aufwies und zugewiesen sowie in Betrieb war, für das zuständige Team jedoch unsichtbar blieb.
Der am 9. September 2026 im CNCF-Blog veröffentlichte Beitrag stellt kein neues kommerzielles Produkt vor, sondern erläutert ein praktisches Muster für den eigenständigen und sicheren Zugriff auf Metriken in mandantenfähigen Kubernetes-Clustern. Die Grundidee besteht darin, eine mandantenbewusste Vermittlungsschicht vor den zentralen Prometheus zu setzen und anschließend jedem Team einen ausgewählten Ausschnitt seiner Daten bereitzustellen, mit der Möglichkeit, diese Daten in einen eigenen Prometheus zu kopieren.
Warum reicht es nicht aus, den zentralen Prometheus zu öffnen?
Die Autoren sind der Ansicht, dass die Erteilung von Leseberechtigungen für den zentralen Prometheus-Abfrageendpunkt auf zwei Probleme stößt. Das erste ist ein Sicherheitsproblem, da der Prometheus-Abfrageendpunkt keine Kenntnis von Namespaces hat. Wer PromQL-Abfragen ausführen kann, könnte theoretisch Daten anderer Teams anfordern, etwa Anfrageraten oder Kapazitätspläne.
Das zweite Problem betrifft die Leistung. Der zentrale Speicher bedient die Metriken der gesamten Flotte, und lange oder schlecht optimierte Abfragen von Hunderten Ingenieuren könnten Ressourcen verbrauchen und die Antwortzeit für alle erhöhen. Das Öffnen des gemeinsam genutzten Speichers löst daher das Sichtbarkeitsproblem nicht, sondern kann der Architektur zusätzlich das Risiko von Datenlecks und das Problem eines störenden Nachbarn hinzufügen.
Eine Vermittlungsschicht mit drei Aufgaben
Der Entwurf sieht eine schlanke Schicht vor Prometheus vor, die drei miteinander verbundene Funktionen übernimmt:
- Identifikation: Authentifizierung des Anfragenden und Ermittlung des Mandanten, dem er angehört.
- Isolation: Beschränkung jeder Abfrage auf den Namespace des Mandanten, wobei die Einschränkung angewendet wird, bevor die Abfrage Prometheus erreicht, sodass sie nicht über PromQL umgangen werden kann.
- Zustellung: Regelmäßiges Kopieren einer ausgewählten Gruppe von Mandantenmetriken in einen eigenen Prometheus, sofern erforderlich.
Der Lesepfad verwendet Nginx zur Lastverteilung, anschließend kube-rbac-proxy für Authentifizierung und Autorisierung. Danach erreichen die Anfragen den Proxy, der Prometheus-Server über die Kubernetes API erkennt und die Ergebnisse der gesunden Server zusammenführt. Der Schreibpfad nutzt Remote Write, um die ausgewählten Metriken an den Prometheus des Mandanten zu senden. In Hochverfügbarkeitsumgebungen werden die Daten über die DNS-Namen der Pods an alle Replikate gesendet.
Die Isolation beginnt bei der Identität und endet bei den Daten
kube-rbac-proxy verwendet die Kubernetes-Identität und RBAC, um den Anfragenden zu bestimmen, und übergibt die Identität des Mandanten als Namespace-Assertion. prom-label-proxy setzt die Isolation zum Zeitpunkt der Abfrage durch, indem es die Anfrage umschreibt und vor der Weiterleitung an Prometheus einen Namespace-Selektor hinzufügt. Dadurch ist die Isolation nicht nur eine dem Nutzer empfohlene Richtlinie, sondern eine auf jede Abfrage angewendete Einschränkung.
Die Quelle verweist außerdem auf Härtungsmaßnahmen für den Proxy selbst. Dazu gehören der Betrieb als Nicht-root-Benutzer mit der UID 65534, die Verwendung eines schreibgeschützten Root-Dateisystems, die Entfernung aller zusätzlichen Berechtigungen, die Verhinderung einer Rechteausweitung sowie die Verwendung eines Dienstkontos mit möglichst wenigen Berechtigungen.
Was ändert sich praktisch bei Kosten und Leistung?
Die Isolation beschränkt sich nicht darauf, die Sichtbarkeit der Daten anderer zu verhindern. Die Einstellung metricIsolation ermöglicht die Anwendung eines Namespace-Filters bereits während der Metrikerfassung, sodass der Prometheus des Mandanten nur die ihm zugehörigen Zeitreihen speichert. Nach dem Versuch der Autoren kann die Zahl der für einen typischen Mandanten gespeicherten Zeitreihen um etwa 97 % sinken, von mehr als 10.000 Zeitreihen auf einige Hundert.
Diese Reduzierung bedeutet einen kleineren Speicher, schnellere Abfragen und geringere Speicherkosten. Außerdem wird das Risiko eines Datenlecks verringert, da nicht benötigte Metriken den privaten Speicher gar nicht erst erreichen. Der Entwurf reduziert auch die Belastung des zentralen Prometheus, da Dashboards und tägliche Alarme in die Speicher der Mandanten verlagert werden, anstatt fortlaufend auf den gemeinsamen Speicher zurückzugreifen.
Der eigenständige Betrieb braucht klare Grenzen
Das Team definiert eine benutzerdefinierte Kubernetes-Ressource namens MetricAccess, die den Namespace, die benötigten Metriken, das Remote-Write-Ziel und das Erfassungsintervall festlegt. Mandanten können bestimmte Metriknamen, reguläre Ausdrücke oder PromQL-Selektoren auswählen. Beim Ziel-Prometheus muss der Empfang von Remote Write über web.enable-remote-write-receiver aktiviert werden, während der übrige Aufbau auf den üblichen Prometheus- und Kubernetes-Komponenten basiert.
Der Beitrag stellt sechs nützliche Abfragetypen vor, darunter die durchschnittliche GPU-Auslastung pro Namespace, die Anzahl der GPUs mit einer Auslastung von unter 5 % innerhalb einer Stunde, den Anteil des genutzten Speichers, den Energieverbrauch, die Erkennung belegter GPUs ohne Anfrageaktivität sowie das Vorhandensein von Anfragen bei gleichzeitig ungenutzten GPUs. Das Beispiel basiert auf Metriken des Typs DCGM, wobei darauf hingewiesen wird, dass die Namen an den tatsächlich verwendeten Exporter angepasst werden müssen.
Die Erfahrung bestätigt, dass eigenständiger Betrieb nicht bedeutet, Barrieren zu entfernen. Die ausgewählten Metrikgruppen und unterschiedlichen Erfassungsintervalle wirken als Quoten und begrenzen die Last. Außerdem sollte die Option Remote Write Teams vorbehalten bleiben, die tatsächlich über Dashboards und Alarme verfügen, während für kleinere Teams ein eingeschränkter Zugriff zum Abfragezeitpunkt ausreichen kann.
Lesart von certi.news
Die wichtige Änderung besteht hier nicht darin, ein weiteres Monitoring-Tool hinzuzufügen, sondern die Kontrolle über die Sichtbarkeit vom Plattformteam allein auf den Mandanten zu verlagern und die Isolation weiterhin unter der Kontrolle der Infrastruktur zu belassen. Damit werden gleichzeitig ein Sicherheits-, ein Kosten- und ein Leistungsproblem behandelt. Die Lösung ist jedoch nicht automatisch: Die Auswahl der Metriken, die Kontrolle der Cardinality, der Umgang mit Wiederholungsversuchen, das Schreiben in Hochverfügbarkeitsreplikate und das Fixieren der Exporter-Versionen sind fortlaufende betriebliche Aufgaben.
Auch die genannten Zahlen, darunter die Reduzierung der Zeitreihen um etwa 97 %, beziehen sich auf den Versuch der Autoren und einen „typischen Mandanten“ und sind keine allgemeine Garantie für jeden Cluster. Daher sollte das Muster vor einer breiten Einführung mit den Metriknamen, der Zeitreihengröße und den Erfassungsintervallen der jeweiligen Umgebung getestet werden. Das Projekt ist unter Apache 2.0 verfügbar; der Beitrag enthält einen Link zum Repository prometheus-multi-tenant-proxy auf GitHub.