CNCF Kepler von Grund auf neu gebaut: präzise Energiemessung von Kubernetes-Pods ohne Kernel-Privilegien

Kepler (Kubernetes-based Efficient Power Level Exporter), ein CNCF-Sandbox-Projekt, das seit 2023 den Energieverbrauch in Kubernetes-Clustern misst, hat eine völlig neue Architektur erhalten. Das Team hat ein detailliertes technisches Begründungsschreiben für den Rewrite, Experimentergebnisse und einen Aufruf an die Community zur Mitarbeit veröffentlicht — besonders relevant für Organisationen, die KI- und ML-Workloads betreiben, deren Energieverbrauch zu einer immer wichtigeren Metrik wird.

Warum ist Kubernetes blind für den Energieverbrauch?

Kubernetes bietet von Haus aus keinen Mechanismus, um zu verfolgen, wie viel Energie ein einzelner Pod oder Workload verbraucht. Clusteradministratoren können CPU- und Speicherverbrauch sehen, aber keine Wattzahlen — was zum Problem wird, wenn Organisationen ihren CO₂-Fußabdruck verfolgen, Energiekosten optimieren oder ESG-Berichtspflichten erfüllen möchten. Kepler füllt diese Lücke: Es liest Hardware-Leistungsmesser, schreibt den Verbrauch einzelnen Linux-Prozessen und Pods zu und exportiert die Ergebnisse als Prometheus-Metriken.

Alte Architektur und ihre Probleme

Der ursprüngliche Kepler stützte sich auf eBPF (extended Berkeley Packet Filter) zur Erfassung von Auslastungssignalen. Dieser Ansatz hatte in Produktionsumgebungen mehrere ernsthafte Einschränkungen:

Er erforderte CAP_BPF- und CAP_SYSADMIN-Privilegien — was viele Sicherheitsteams für Standard-Monitoring-Tools nicht erlauben. Produktions-Kubernetes-Cluster haben oft strenge Container-Privilege-Richtlinien, sodass Kepler bereits in der Deployment-Phase blockiert wurde.

Der eBPF-Ansatz verpasste kurzlebige Prozesse, die beendet wurden, bevor der Kernel-Probe sie erfassen konnte. In KI/ML-Workloads, die intensiv kurze Batch-Aufgaben nutzen, konnte diese Ungenauigkeit sich akkumulieren.

Das sichtbarste Symptom war das Auftreten mehrkilowatthoher Messspitzen — Implementierungsartefakte, die den tatsächlichen physischen Verbrauch nicht widerspiegelten, aber Metriken und Dashboards kontaminierten.

Neue Architektur ohne Kernel-Privilegien

Neue Architektur und Präzisionssprung

Das neue Kepler hat eBPF vollständig aufgegeben. Stattdessen liest es standardmäßige /proc- und /sys-Pfade, die der Linux-Kernel für alle Prozesse freigibt — ohne Kernel-Privilegien. Der Zugriff ist read-only: Kepler schreibt nicht in den Kernel und injiziert keinen Code.

Die zentrale Innovation ist die dynamische Erkennung der Leistungsmesserstruktur zur Laufzeit. Die alte Architektur setzte eine feste Hardware-Topologie voraus, was auf Servern mit unterschiedlichen Konfigurationen von DRAM-, Socket- und Package-Ebenen zu Fehlern führte. Die neue Version liest die Struktur beim Start aus /sys und passt sich ohne manuelle Konfiguration an.

Das Deployment wurde auf ein einziges Helm-Chart vereinfacht, was die Lernkurve und die Anzahl der konfigurierbaren Parameter erheblich reduziert hat.

Experimentergebnisse

Das Team führte zwei wichtige Experimente zur Validierung der neuen Architektur durch:

Experiment 1 verglich das neue kepler_node_cpu_watts mit IPMI-Ground-Truth-Messungen (physische Sensoren an Server-Hardware). Ergebnis: Die neue Metrik folgt dem IPMI-Muster ohne die mehrkilowatthohen Spitzen, die die alte Implementierung charakterisierten.

Experiment 2 maß den Leistungsattributionsfehler auf Prozessebene — die Differenz zwischen der Summe der zugeschriebenen Leistung aller Prozesse und der insgesamt gemessenen Knotenleistung. Der Fehler wurde auf Milliwatt-Ebene reduziert (statt Watt oder Kilowatt wie zuvor), was bestätigt, dass die neue Architektur den Gesamtverbrauch konsistent aufteilt.

Die Testabdeckung erreichte 90 %, was für ein Infrastruktur-Tool dieser Art ein hoher Wert ist.

Aufruf an die Community

Das Kepler-Team nennt vier Bereiche, in denen es Beiträge sucht:

GPU-Monitoring für KI/ML-Workloads bleibt ein ungelöstes Problem — die aktuelle Architektur deckt die CPU ab, aber die GPU-Energieattribution pro Pod ist komplexer, da NVIDIA und AMD Metriken unterschiedlich exponieren. Dies ist besonders relevant für Organisationen, die LLM-Inferencing oder Training in Kubernetes betreiben.

Power-Modellierung für VM-Umgebungen erfordert einen ML-Ansatz, da die Virtualisierungsschicht physische Messer verbirgt. Das Team sucht Experten, die Power-Schätzmodelle trainieren können.

Validierung gegenüber physischen Messern (IPMI, externe Wattmeter) und Verbesserung der Idle-Power-Attribution sind zwei weitere offene Probleme.

Für Organisationen, die bereits den Energieverbrauch von KI-Infrastruktur messen, bietet die neue Version von Kepler eine stabilere Grundlage für die Integration in bestehende Prometheus/Grafana-Stacks ohne Kompromisse in den Sicherheitsrichtlinien des Clusters.