Subaru reduziert KI-Container-Pull-Zeiten um das 60-Fache mit Envoy Gateway

Subaru reduzierte die Container-Pull-Zeit von rund drei Stunden auf drei Minuten. Das ist eine 60-fache Verbesserung bei einer einzigen operativen Kennzahl – und das reichte aus, um den CNCF End User Case Study Contest für KubeCon + CloudNativeCon Japan 2026 zu gewinnen, der am 28. Juli während einer Keynote in Yokohama auf der Bühne bekannt gegeben wurde. Die interessante Zahl ist nicht der Preis, sondern die Ausgangslage: Ein KI-Plattform-Team bei einem Automobilhersteller der Spitzenklasse wartete bis vor Kurzem drei Stunden darauf, dass ein Container bereitgestellt wurde, bevor ein GPU-Job starten konnte.

Was geschah

Die Cloud Native Computing Foundation kürte Subaru zum Gewinner ihres End-User-Case-Study-Contests für Arbeiten an der Infrastruktur hinter der nächsten Generation von EyeSight, dem fortschrittlichen Fahrerassistenzsystem des Unternehmens. Wie PR Newswire berichtete, hielt Ryoji Kobayashi, ein DevOps-Ingenieur in Subarus ADAS-Entwicklungsabteilung, die Keynote und erläuterte die Architektur.

Der vorherige Zustand war, laut Quelle, auf eine sehr spezifische Weise problematisch. KI-Container-Images überschritten 30 GB. Das Laden eines Images dauerte ungefähr drei Stunden, bevor Workloads beginnen konnten. Deployments wurden über manuell ausgeführte Skripte statt über deklarative Konfiguration abgewickelt. Die ML-Pipeline hatte kein einheitliches Orchestrierungsframework. Die On-Premises-GPU-Umgebung, die für kleinere Workloads ausreichend gewesen war, wurde zu einem Engpass, als die Modelltrainings- und Validierungszyklen skalierten.

Der Neuaufbau verwendete Kubernetes plus einen Stack von CNCF-Projekten: Envoy Gateway und Gateway API mit MetalLB für die Netzwerkschicht, Argo CD und Helmfile auf bestehenden Helm-Charts für GitOps-basiertes Deployment sowie Argo Workflows für die Pipeline-Orchestrierung. Die Envoy-Gateway-Arbeit ist es, die die 60-fache Reduzierung der Pull-Zeit bewirkte. GitOps löste das Reproduzierbarkeitsproblem. Argo Workflows löste das Pipeline-Problem.

Chris Aniszczyk, CTO von CNCF, beschrieb den Sieg als Beispiel dafür, wie Kubernetes zusammen mit Argo, Envoy, Helm, Harbor und MetalLB „reale Infrastrukturherausforderungen löst und KI-Innovation beschleunigt." Kobayashis eigene Einordnung war stärker operativ geprägt: Das Team wollte, dass sich Ingenieure auf die Modellgenauigkeit konzentrieren, statt Infrastruktur zu verwalten. Beide Aussagen zeigen auf dasselbe. Der Engpass waren nie die GPUs, sondern alles, was um sie herum lag.

Technische Analyse

Die Zahl „von drei Stunden auf drei Minuten" verdient Beachtung, da die Quelle den genauen Mechanismus innerhalb von Envoy Gateway, der dieses Ergebnis erzeugte, nicht offenlegt. Das ist relevant, weil ein 60x-Faktor bei einem 30-GB-Pull entweder eine Caching-Schicht, eine Änderung der Fan-out-Topologie, ein geändertes Image-Format oder alle drei impliziert. Die Pressemitteilung nennt „die Optimierung der Kubernetes-Netzwerkarchitektur mit Envoy Gateway" sowie Gateway API und MetalLB, benennt aber weder eine Registry (Harbor wird nur im Zitat des CNCF-CTO erwähnt) noch gibt sie an, ob Lazy-Pulling-Technologien beteiligt waren. Eingrenzung des Unbekannten: Die Verbesserung basiert entweder auf einer Netzwegoptimierung (Envoy verarbeitet Pull-Traffic effizienter als der vorherige Ingress), einer Änderung der Registry-Nähe oder beidem. In jedem Fall ist das Delta so groß, dass es fast sicher eine Topologie-Korrektur und keinen Konfigurationsfeinschliff widerspiegelt.

Zum Hintergrund, warum 30-GB-Images überhaupt existieren: ML-Container-Images bündeln CUDA-Toolkits, Framework-Binärdateien (PyTorch oder TensorFlow mit GPU-Unterstützung), Modellgewichte, Vorverarbeitungsabhängigkeiten und oft Datensatzproben zur Validierung. Es ist einfach, die 20-GB-Grenze zu überschreiten, bevor eine einzige Zeile Anwendungscode geschrieben wird. Dockers eigene Anleitungen zu Multi-Stage-Builds und Layer-Caching helfen nur begrenzt, wenn der CUDA-Basis-Layer allein schon mehrere Gigabyte groß ist.

Der GitOps-Anteil mit Argo CD und Helmfile adressiert eine andere Fehlerquelle. Im vorherigen Zustand wurden manuell ausgeführte Skripte verwendet. Das bedeutet Environment-Drift, stille Abweichungen zwischen dem, was läuft, und dem, was committet ist, sowie keine saubere Rollback-Möglichkeit. Argo CD auf Helm-Charts aufzusetzen – mit Helmfile als Kompositionsschicht – liefert einen deklarativen Graphen, was wo deployed sein soll, der kontinuierlich abgeglichen wird. Das Reproduzierbarkeitsargument, das Kobayashi anführt, ist kein Marketing. Für ML-Trainingsläufe, die auditierbar sein müssen (und für ADAS ist das absolut notwendig), ist es eine entstehende regulatorische Anforderung – keine optionale Komfortfunktion –, genau zu wissen, welcher Container, welche Konfiguration und welche Pipeline-Version einen bestimmten Modell-Checkpoint erzeugt hat.

Argo Workflows übernimmt die DAG-Orchestrierung für die Pipeline selbst: Datenverarbeitung, Training, Validierung, Inferenz. Zuvor, laut Quelle, „fehlte komplexen ML-Pipelines ein einheitliches Orchestrierungsframework." Übersetzung: wahrscheinlich eine Mischung aus Cron-Jobs, Bash-Klebecode und Stammwissen.

Prognose: Wenn die gemeldete Architektur im Produktivbetrieb standhält, sollte Subarus Modelliterationsrhythmus (abgeschlossene Trainingsläufe pro Woche) in den nächsten zwei Quartalen spürbar zunehmen. Die Einsparung bei der Pull-Zeit allein gibt pro Job-Start rund 2 Stunden und 57 Minuten frei. In einem Cluster, der täglich Dutzende von Jobs ausführt, summiert sich das schnell.

Wer unter Druck gerät

Die Teams, die durch diese Fallstudie am stärksten exponiert sind, sind jene, die ML-Plattformen betreiben, bei denen niemand die Cold-Start-Kosten kürzlich gemessen hat. Das ist eine große Gruppe. Wenn Ihre Data Scientists klagen, dass „der Cluster langsam ist", und Ihr Plattform-Team mit GPU-Auslastungs-Dashboards antwortet, besteht eine gute Chance, dass der eigentliche Schmerz in der Image-Pull-Latenz, dem Sidecar-Start oder der PVC-Mount-Zeit liegt – nichts davon erscheint in einer GPU-Metrik.

Automobil- und Industrie-ML-Teams befinden sich in einer besonders unbequemen Lage. ADAS-, Robotik- und industrielle Inspektions-Workloads teilen Subarus Profil: große Images (CUDA plus proprietäre CV-Stacks), On-Premises-GPU-Cluster (Data Gravity und Latenzanforderungen halten sie aus der Public Cloud) sowie strenge Reproduzierbarkeitsanforderungen. Jeder Wettbewerber, der noch manuelle Deployment-Skripte gegen On-Prem-GPUs ausführt, liegt bei operativen Werkzeugen nun sichtbar zurück. Der CNCF-Award verleiht Subarus Ansatz für die nächsten 12 Monate impliziten Referenzarchitektur-Status in Beschaffungsgesprächen.

Fintech- und iGaming-Plattform-Teams sind weniger direkt betroffen, sollten aber auf den GitOps-Anteil achten. Das Muster, Argo CD und Helmfile auf bestehende Helm-Charts zu schichten (anstatt Helm herauszureißen), ist ein risikoarmer Migrationspfad, den viele Teams noch nicht beschritten haben. Wenn Ihre Produktions-Deployments noch damit verbunden sind, dass jemand ein Skript vom Laptop ausführt, befinden Sie sich auf der falschen Seite dieses Trends.

Das Unbekannte, das es wert ist, hervorgehoben zu werden: Die Quelle legt weder Clustergröße, GPU-Anzahl, Migrationskosten noch den Zeitaufwand offen. Ohne diese Zahlen ist der ROI von außen nicht quantifizierbar. Eine vernünftige Obergrenze ist, dass das Projekt mehrere Ingenieur-Quartale in Anspruch nahm, denn Envoy Gateway, Argo CD, Helmfile und Argo Workflows integriert gegen einen bestehenden On-Prem-GPU-Cluster aufzubauen, ist kein Zwei-Sprint-Job. Jeder CTO, der das liest und eine Replikation in einem Monat erwartet, wird enttäuscht werden.

Leitfaden für Engineering-Teams

Beginnen Sie mit Messung, nicht mit Tooling. Messen Sie Container-Pull-Latenz, Image-Größenverteilung und die Zeit von Job-Start bis zur ersten GPU-Operation in Ihren ML-Clustern. Wenn Sie diese Metriken noch nicht exportieren, installieren Sie diese Woche OpenTelemetry-Collectoren auf Ihren Node-Agents. Sie können keine 60-fache Verbesserung bei etwas beanspruchen, das Sie nicht als Ausgangspunkt gemessen haben.

Überprüfen Sie Image-Größen ehrlich. Wenn Ihre Trainings-Images über 20 GB liegen, teilen Sie sie auf: CUDA- und Framework-Basis-Layer in einem selten wechselnden Parent-Image, Anwendungscode und Konfigurationen in einem schlanken Child-Image. Das ist grundlegende Hygiene, die die meisten ML-Teams überspringen, weil „es auf meinem Laptop funktioniert."

Für die Deployment-Schicht: Wenn Sie noch Skripte ausführen, wechseln Sie schrittweise zu GitOps. Argo CD auf bestehenden Helm-Charts ist der reibungsärmste Weg. Helmfile als Kompositionsschicht kommt als Nächstes. Sie müssen nichts neu schreiben, um Reproduzierbarkeitsgewinne zu erzielen – Sie müssen eine Reconciliation-Schleife vor das stellen, was Sie bereits haben.

Für die Pipeline-Orchestrierung ist Argo Workflows eine von mehreren Optionen (Kubeflow Pipelines, Flyte, Dagster). Die spezifische Wahl ist weniger wichtig als die Entscheidung für eine und deren Standardisierung. Fragmentierte Orchestrierung über Teams hinweg ist ein größeres Problem als die Wahl des „falschen" Werkzeugs.

Überprüfbare Prognose: Jedes Team, das in diesem Quartal Pull-Latenz und Image-Größe misst, wird mindestens einen Workload finden, bei dem ein 10-fache Verbesserung mit einem Wochenende Arbeit erreichbar ist. Wenn sich Ihre Ausgangslage als bereits eng herausstellt – herzlichen Glückwunsch, Sie sind besser aufgestellt als Subarus Ausgangspunkt.

Wichtigste Erkenntnisse

• Subaru reduzierte die KI-Container-Pull-Zeiten von rund drei Stunden auf drei Minuten – eine 60-fache Verbesserung – durch Optimierung des Kubernetes-Netzwerks mit Envoy Gateway, Gateway API und MetalLB.
• Der Ausgangszustand (Images über 30 GB, manuelle Deploy-Skripte, kein einheitliches Pipeline-Orchestrierungsframework) ist auf ML-Plattformen verbreiteter, als die meisten CTOs zugeben.
• Die GitOps-Migration verwendete Argo CD und Helmfile auf bestehenden Helm-Charts – ein risikoarmes Muster, das jedes Team, das noch Deploy-Skripte ausführt, übernehmen sollte.
• Die Quelle legt weder Clustergröße, Kosten noch den Migrations-Zeitplan offen, daher ist der ROI von außen nicht quantifizierbar; ein mehrere Quartale umfassender Engineering-Aufwand ist die realistische Untergrenze.
• Wenn Ihr ML-Team „langsame GPUs" beklagt, ohne Pull-Latenz und Job-Start-Zeit zu messen, diagnostizieren Sie den falschen Engpass.