Jahrelang glich der Aufbau einer KI-Infrastruktur einem „Wilden Westen“ mit fragmentierten Tools, proprietären Stacks und explodierenden Kosten. Mit dem Kubernetes AI Conformance-Programm steht nun der neue globale technische Standard für den Betrieb von KI auf Kubernetes bereit.

Auf der KubeCon hat die Cloud Native Computing Foundation (CNCF) offiziell das Kubernetes AI Conformance-Programm vorgestellt. Es ist nun der neue technische Standard für den Betrieb von KI auf Kubernetes. Kubermatic ist eine der weltweit ersten Plattformen und die erste in Europa, die offiziell Kubernetes AI-konform für Kubernetes v1.34 ist.

Was „KI-Konformität“ eigentlich bedeutet

Während sich ISO-Normen wie ISO 42001 auf Management und Governance konzentrieren, ist die Kubernetes AI-Konformität rein technischer Natur. Sie definiert die APIs, Funktionen und Konfigurationen, die ein Kubernetes-Cluster unterstützen muss, um KI-/ML-Workloads effizient und sicher auszuführen.

Kurz gesagt: Wenn eine Plattform „KI-konform” ist, können Benutzer darauf Modelle trainieren und bereitstellen und diese dann ohne Neuprogrammierung auf einen anderen, konformen Cluster übertragen. Das bedeutet Herstellerunabhängigkeit und einen klaren Weg zu einer portablen, souveränen KI-Infrastruktur.

Der Weg zur Kubernetes AI-Konformität

Um den Standard für „Kubernetes AI Conformance“ zu definieren, wurde innerhalb des Kubernetes-Projekts eine spezielle Arbeitsgruppe gebildet, gesponsert von den Architecture and Testing Special Interest Groups (SIGs). Kubermatic ist ein aktives Mitglied dieser Gruppe. Seit der KubeCon Europe in London hat die Arbeitsgruppe intensiv daran gearbeitet, die technischen Kernpfeiler zu identifizieren, die zur Bewältigung der besonderen Herausforderungen von KI-Workloads erforderlich sind.

Das Ergebnis dieser Bemühungen war ein Anforderungskatalog, den jede Plattform erfüllen muss, um als Kubernetes AI-konform zu gelten. Kubermatic verfügte bereits über die meisten grundlegenden Komponenten, aber der Konformitätsprozess erforderte es, diese zu validieren, zu dokumentieren und auf Produktionsniveau zu bringen. Kubermatic KKP 2.29 erfüllt nun jede dieser Anforderungen.

Wie Kubermatic die einzelnen Anforderungen umgesetzt hat

1. Effizientes Beschleunigermanagement für KI-Training
In nicht standardisierten Umgebungen kommt es zu zwei Problemen: eine starke „Ressourcenfragmentierung“, bei der große Teile des wertvollen GPU-Speichers ungenutzt bleiben, und „Topologieblindheit“, bei der die Planung nicht für Multi-GPU-Workloads optimiert ist. Dies führt zu einer massiven Überversorgung und explodierenden Kosten.

KKP 2.29 berücksichtigt dies. DRA (Dynamic Resource Allocation) bietet seit der Version Kubernetes 1.34 eine flexible neue Möglichkeit, komplexe Hardwareressourcen anzufordern und gemeinsam zu nutzen. Ähnlich wie das bekannte PersistentVolumeClaim-Modell für Speicher ermöglicht DRA den Benutzern, genau die Ressourcen aus definierten „Klassen” von Geräten „anzufordern”, die sie benötigen, während Kubernetes die gesamte komplexe Planung und Knotenplatzierung automatisch übernimmt.

2. Erweiterte Eingabe für KI-Inferenz
KI-Inferenz-Workloads, also die Modelle in der Produktion, unterscheiden sich grundlegend von herkömmlichen, zustandslosen (stateless) Webanwendungen. Sie sind oft langwierig, ressourcenintensiv und teilweise zustandsbehaftet (stateful), wodurch sie für Standard-Load-Balancer ungeeignet sind.

KKP erfüllt diese Anforderung über das KubeLB 1.2 AI Gateway. Diese Funktion integriert das Open-Source-Kgateway und seine leistungsstarke Inferenz-Erweiterung und bietet optimiertes Routing und Load Balancing speziell für KI-Workloads. Zu den weiteren Funktionen gehören gewichtetes Traffic-Splitting und Header-basiertes Routing, was für OpenAI-Protokoll-Header wichtig ist.

3. Planung und Orchestrierung
Verteilte KI-Trainingsjobs erfordern oft, dass mehrere Komponenten (Pods) gleichzeitig gestartet werden. Ein herkömmlicher Scheduler, der Pods einzeln platziert, kann zu „Deadlocks“ führen. Dies bedeutet, dass ein Job stecken bleibt, weil nicht alle seine Teile Ressourcen finden können, während gleichzeitig die bereits zugewiesenen Ressourcen blockiert werden.

KKP 2.29 enthält den Kueue-Job-Scheduler in seinem Standard-Anwendungskatalog und sorgt so für eine effiziente Planung verteilter KI-Workloads. Darüber hinaus erfüllt KKP die Anforderungen an die automatische Skalierung und bietet einen voll funktionsfähigen Cluster Autoscaler, der in der Lage ist, Beschleuniger-Knotengruppen zu skalieren, und HorizontalPodAutoscaler (HPA) mit benutzerdefinierten GPU-Metriken zu unterstützen.

4. Überwachung und Metriken
Die neue Generation von KI-Workloads und spezialisierter Hardware schafft eine „blinde Stelle“ bei der Überwachung. Derzeit gibt es keine Standardmethode zum Erfassen von Beschleunigermetriken, und den Betreibern fehlen die Tools, um komplexe Probleme in der KI-Infrastruktur schnell zu beheben.

Der robuste, integrierte Überwachungsstack von KKP für Benutzercluster erfüllt diese Anforderungen. Er ermöglicht die Erfassung detaillierter Leistungsmetriken von unterstützten Beschleunigertypen (z. B. Auslastung, Speicher) über einen standardisierten Endpunkt. Ebenso bietet er ein Überwachungssystem, das Metriken aus jeder Workload erkennen und erfassen kann, die diese in einem Standardformat (z. B. Prometheus-Exposition-Format) bereitstellt.

5. Sicherheit und Ressourcentrennung
Teure Beschleuniger (GPUs) sind eine gemeinsam genutzte Ressource. Ohne strenge Isolierung auf Kernel- und API-Ebene könnten Workloads in einem Container auf die Daten oder Prozesse von Workloads in einem anderen Container zugreifen oder diese stören, was in Multi-Tenant-Umgebungen ein erhebliches Sicherheitsrisiko darstellt.

Der Zugriff auf Beschleuniger muss ordnungsgemäß isoliert und über Kubernetes-Ressourcenmanagement-Frameworks (wie DRA oder Geräte-Plugins) vermittelt werden. Die Implementierung dieser Frameworks durch KKP stellt sicher, dass der Zugriff aus Containern heraus ordnungsgemäß isoliert ist, wodurch unbefugter Zugriff oder Störungen zwischen Workloads verhindert werden – eine Kernanforderung für sichere Multi-Tenant-KI-Plattformen.

6. Robuste Operator-Unterstützung
Moderne KI-Frameworks wie Ray oder Kubeflow sind selbst komplexe, verteilte Systeme, die als „Operatoren” auf Kubernetes laufen. Wenn die Kernplattform (z. B. deren Webhooks, CRD-Verwaltung oder API-Server-Stabilität) nicht robust ist, fallen diese Operatoren aus, wodurch die gesamte KI-Plattform unbrauchbar wird.

KKP 2.29 hat sich hierfür bewährt und bietet vollständige Unterstützung für die zuverlässige Installation und Ausführung komplexer Add-ons, einschließlich Kubeflow. Dazu gehört auch die Überprüfung, ob die Pods, Webhooks und benutzerdefinierten Ressourcenabgleichsfunktionen des Operators korrekt funktionieren.

Bedeutung von KKP 2.29 als Kubernetes AI-konforme Plattform für die Zukunft in Europa

Nach Abschluss der Konformitätsprüfung hat Kubermatic offiziell alle Validierungskriterien für Kubernetes 1.34 erfüllt.
Für europäische Unternehmen geht es hier um digitale Souveränität. Mit einem offenen, gemeinschaftlich entwickelten Standard, der von der CNCF unterstützt wird, können Unternehmen endlich KI-Workloads überall einsetzen: in der Publc Cloud, im privaten Rechenzentrum oder am Netzwerk-Edge, ohne dabei auf Compliance oder Kontrolle verzichten zu müssen.

Wie Sebastian Scheele, CEO von Kubermatic, es ausdrückt: „Die Zukunft der KI wird auf offenen Standards basieren, nicht auf abgeschotteten Systemen. Dieses Konformitätsprogramm ist die Grundlage für diese Zukunft und gewährleistet gleiche Wettbewerbsbedingungen, bei denen Innovation und Portabilität gewinnen. Wir sind bereit, Unternehmen heute dabei zu helfen, diese Zukunft zu gestalten.“

Disclaimer:
„Für den oben stehenden Beitrag sowie für das angezeigte Bild- und Tonmaterial ist allein der jeweils angegebene Nutzer verantwortlich. Eine inhaltliche Kontrolle des Beitrags seitens der Seitenbetreiberin erfolgt weder vor noch nach der Veröffentlichung. Die Seitenbetreiberin macht sich den Inhalt insbesondere nicht zu eigen.“