Im Arbeitspaket 1 des NADIKI-Projekts war vorgesehen, eine Open-Source-Erweiterung für Kubernetes zu entwickeln, die den Ressourcenverbrauch von KI-Anwendungen zur Laufzeit misst. Nach einer eingehenden Analyse bestehender Lösungen haben wir diesen Ansatz verworfen und stattdessen eine Observer-Architektur konzipiert. Dieser Artikel beschreibt die Gründe für diese Entscheidung.

Die Grenzen bestehender Kubernetes-Energiemessung

Zwei Open-Source-Projekte dominieren die Energiemessung in Kubernetes-Umgebungen: Scaphandre und Kepler. Beide stoßen in der Praxis auf dieselben strukturellen Probleme.

Scaphandre misst den Energieverbrauch über Intel RAPL (Running Average Power Limit) und stellt die Daten in Kubernetes bereit. Drei Einschränkungen machen diesen Ansatz für unseren Anwendungsfall ungeeignet:

• Nur CPU-Verbrauch: RAPL erfasst ausschließlich den Energieverbrauch der CPU. GPUs, Netzwerkkarten, Speichermedien und sonstige Peripherie bleiben unsichtbar — gerade bei KI-Workloads, die auf GPU-Beschleunigung angewiesen sind, müssen die GPUs mit erfasst werden können.

• Abhängigkeit vom Cloud-Anbieter: Der Zugriff auf RAPL-Schnittstellen setzt voraus, dass der Infrastrukturanbieter dies in der virtualisierten Umgebung erlaubt und unterstützt. In der Praxis ist das selten der Fall.

• Leistungseinbußen: Bei hochfrequenten Messungen (z. B. alle 5–15 Sekunden) erzeugt Scaphandre (und RAPL) erheblichen Overhead auf dem gemessenen System — besonders problematisch unter hoher Last.

Kepler verfolgt einen ähnlichen Ansatz und stützt sich ebenfalls stark auf RAPL. In virtualisierten Umgebungen — die nach unserer Einschätzung den Großteil der produktiven KI-Workloads ausmachen — greift Kepler auf Schätzmodelle zurück, statt tatsächliche Messwerte zu liefern.

Beide Werkzeuge teilen ein grundsätzliches Architekturproblem: Sie versuchen, die Energiemessung innerhalb der Kubernetes-Umgebung des Kunden zu lösen. Das erfordert entweder privilegierten Zugriff auf Hardware-Schnittstellen oder akzeptiert unpräzise Schätzwerte.

Die Realität der Cloud-Infrastruktur als Ausgangspunkt

Unser Ansatz orientiert sich an der tatsächlichen Beziehung zwischen Infrastrukturanbieter und Kunde. In der Praxis gibt es eine klare Trennung: Der Anbieter betreibt die physische Infrastruktur, der Kunde betreibt seine Workloads in einer virtualisierten Umgebung darauf. Diese Trennung ist gewollt — aus Sicherheitsgründen hat der Kunde keinen Zugriff auf die Hardware-Schnittstellen des physischen Servers.

Die Observer-Architektur respektiert diese Trennung, anstatt sie zu umgehen:

• Auf Seiten des Anbieters installiert dieser einen Exporter auf der physischen Maschine. Dieser registriert den Server beim NADIKI-Registrar gemäß der NADIKI API-Spezifikation und exportiert Metriken direkt über IPMI und NVIDIA's GPU-Power-Tools. Das erfasst den Energieverbrauch des gesamten Servers und aller GPUs — weitaus präziser als RAPL-basierte Messungen.

• Auf Seiten des Kunden wird der Standard-Prometheus-Exporter in Kubernetes genutzt — ohne zusätzliche Plugins oder Erweiterungen. Der Exporter übertragt die Informationen zur Ressourcenauslastung pro Cluster und "Pod" an den Registrar.

• Der Registrar verknüpft die physische Maschine mit den Kubernetes-Metriken und berechnet die Umweltwirkung pro Workload. Die einzige Information, die der Anbieter an den Kunden weitergeben muss, ist die physische Server-ID, die der Registrar bei der Registrierung zuweist.

Vorteile gegenüber einem Kubernetes-Plugin

• Keine Sicherheitsschicht wird geöffnet: Der Kunde benötigt keinen Zugriff auf IPMI oder GPU-Tools. Der Anbieter muss keine Hardware-Schnittstellen in die virtualisierte Umgebung durchreichen.

• Kein zusätzliches Tooling beim Kunden: Standard-Kubernetes-Monitoring reicht aus. Die bestehende Prometheus-Infrastruktur wird genutzt, keine neuen Abhängigkeiten entstehen.

• Vollständige Erfassung: IPMI liefert den Gesamtenergieverbrauch des Servers. NVIDIA SMI erfasst den GPU-Verbrauch. Die Beschränkung auf CPU-Verbrauch via RAPL entfällt.

• Kein Leistungs-Overhead: Die Messungen erfolgen auf der physischen Ebene, nicht innerhalb der virtualisierten Workload. Das gemessene System wird nicht zusätzlich belastet.

• Skalierbar über die Servergrenzen hinaus: Der Registrar aggregiert nicht nur Serverdaten, sondern auch Rack- und Rechenzentrumsmetriken — Kühlung, Wasserverbrauch, Netzstrom-Emissionsfaktoren. Ein Kubernetes-Plugin könnte diese Ebenen nur über komplexe Erweiterungen erreichen.

Weiterführende Quellen

• Scaphandre: GitHub-Repository

• Scaleway: How to measure energy consumption of applications in Kubernetes

• Kepler: Introducing Kepler — Efficient Power Monitoring for Kubernetes

• NADIKI Observer-Architektur: Messung von Umweltwirkungen in Cloud- und IT-Infrastruktur

• NADIKI API: Offene Schnittstelle für Umweltwirkungsdaten aus Rechenzentren