Kubeflow

Kurzfazit

Kubeflow ist die Open-Source-Antwort auf SageMaker und Vertex AI — eine vollständige MLOps-Plattform, die nativ auf Kubernetes läuft. Statt einer einzelnen Anwendung ist es ein Baukasten aus sieben Projekten: Pipelines, KServe, Katib, Training Operator, Spark Operator, Notebooks und Model Registry. Wer ein eigenes Plattform-Team und Kubernetes-Kompetenz hat, bekommt damit eine ernsthafte Alternative zu den großen Cloud-ML-Plattformen — ohne Vendor-Lock-in, on-prem-fähig, Apache 2.0. Wer das nicht hat, läuft in einen monatelangen Aufbauprozess, an dessen Ende eine Plattform steht, die einer einzelner Cloud-Engineer in Tagen mit Vertex AI gehabt hätte. Kubeflow ist mächtig — und unbarmherzig komplex.

Für wen ist Kubeflow?

Plattform- und MLOps-Teams in Konzernen: Wenn dutzende Data-Science-Teams ML-Modelle bauen und ein zentrales Betriebsmodell auf Kubernetes gefragt ist, ist Kubeflow der etablierte Open-Source-Baukasten. Mehrere Mandanten, RBAC über Istio, Notebook-Server pro Nutzerin, geteilte GPU-Pools — solche Setups sind in Kubeflow seit Jahren produktiv erprobt.

On-Prem- und souveränitätsbewusste Organisationen: Banken, Versicherungen, Behörden, Krankenhäuser und Verteidigungsumgebungen, die Modelle nicht in eine fremde Cloud geben dürfen, sind die natürliche Zielgruppe. Kubeflow läuft, wo Kubernetes läuft — im eigenen Rechenzentrum, in privaten Clouds, in Air-Gapped-Umgebungen.

Forschungsinstitute und Universitäten: Wer GPU-Cluster für mehrere Forschungsgruppen bereitstellt und wiederholbare Trainings-Workflows etablieren will, profitiert von Pipelines und Training Operator. Viele europäische HPC-Zentren und KI-Forschungsverbünde setzen Kubeflow ein.

Anbieter eigener ML-Produkte: Unternehmen, die ML-Inferenz als Teil ihres Produkts ausliefern müssen (etwa SaaS-Anbieter mit Modellen pro Mandant), nutzen KServe als Serving-Schicht — multi-framework, Auto-Scaling auf Null, Canary-Deployments. Hier ist Kubeflow oft konkurrenzfähig mit kommerziellen Lösungen.

Weniger geeignet für: Einzelne Data Scientists oder kleine Teams ohne Plattform-Personal (zu komplex), Fachabteilungen ohne Kubernetes-Kompetenz, Projekte mit harten Time-to-Market-Anforderungen (Managed-Services liefern schneller), und alle, die deutschsprachigen Support oder eine fertige UI für Nicht-Techniker erwarten.

Preise im Detail

Variante	Preis	Was du bekommst
Self-Hosted (Vanilla Kubeflow)	0 € (Apache 2.0)	Vollständige Software, alle Komponenten. Du brauchst eigenen Kubernetes-Cluster, betreibst und aktualisierst alles selbst
AWS Kubeflow on EKS	Kosten nur für EKS, EC2, Storage	Distribution mit AWS-Integration (IAM, S3, Sagemaker-Operatoren). Anleitungen offiziell, kein Premium-Support enthalten
Charmed Kubeflow (Canonical)	Support-Vertrag ab ca. 1.500 USD/Knoten/Jahr	Von Canonical gepflegte Distribution, Ubuntu-basiert, mit kommerziellem Support, Updates und Security-Patches
Vertex AI Pipelines (GCP)	Pay-per-Run (rund 0,03 USD pro Komponentenausführung + Compute)	Managed Subset von Kubeflow Pipelines auf Google Cloud. Nur Pipelines, nicht die volle Suite. Läuft in EU-Regionen verfügbar
Amazon SageMaker	nach Verbrauch	Vollständig managed, basiert NICHT auf Kubeflow, ist aber funktionaler Konkurrent. Sagemaker-Operatoren für Kubernetes integrieren mit Kubeflow Pipelines

Einordnung: Die nominellen Lizenzkosten von 0 € sind irreführend. Realistisch zahlst du für Kubernetes-Cluster (3 bis 6-stellig pro Jahr je nach Größe), GPUs (vier- bis fünfstellig pro Monat bei seriöser Trainings-Last) und vor allem Personal: Eine Vanilla-Kubeflow-Installation, die produktiven Konzernansprüchen genügt, kostet in der Regel 6 bis 12 Monate Aufbauzeit mit einem Plattform-Team von zwei bis drei Personen. Wer diesen Aufwand nicht stemmen kann oder will, sollte ehrlich rechnen: Vertex AI Pipelines oder SageMaker liefern den Großteil der Funktionalität in Tagen statt Monaten — gegen laufende Cloud-Gebühren und Vendor-Bindung. Kubeflow rechnet sich nur, wenn Kubernetes-Souveränität, Multi-Cloud-Strategie oder On-Prem-Pflicht gegeben sind. Charmed Kubeflow von Canonical ist die seriöseste Option für Teams, die Open-Source wollen, aber nicht alles selbst integrieren.

Stärken im Detail

Echte Vollständigkeit des ML-Lebenszyklus. Anders als Einzelwerkzeuge wie MLflow (Tracking) oder Airflow (Orchestrierung) deckt Kubeflow den vollständigen Lebenszyklus ab — von Notebook-basierter Exploration über Trainings-Pipelines, verteiltes Training, Hyperparameter-Tuning, Model Registry bis zum produktiven Serving. Dass alle Komponenten nativ auf Kubernetes laufen, macht Setups reproduzierbar und skalierbar.

KServe als ausgereifte Serving-Schicht. Mit über 2.600 GitHub-Stars und Adoption bei Bloomberg, NVIDIA, IBM und vielen anderen ist KServe eines der ernstzunehmendsten Open-Source-Werkzeuge für Modellauslieferung. Es unterstützt PyTorch, TensorFlow, scikit-learn, XGBoost, ONNX und HuggingFace-Transformers, bietet Auto-Scaling auf Null per Knative, Canary- und Multi-Armed-Bandit-Rollouts, A/B-Tests und Explainability-Plugins. Wer LLMs oder klassische Modelle produktiv ausliefern muss, bekommt hier viel Funktionalität ohne SaaS-Bindung.

Verteiltes Training für moderne LLM-Workloads. Der Training Operator unterstützt PyTorch (DDP, FSDP), TensorFlow (MultiWorkerMirroredStrategy), JAX, MPI, XGBoost und neuerdings auch DeepSpeed-Konfigurationen. Damit lassen sich Trainingsjobs über dutzende GPU-Knoten verteilen — ohne dass jedes Team eigene Infrastruktur-Skripte schreiben muss. Für Modelle, die nicht mehr auf eine einzelne GPU passen, ist das essenziell.

CNCF-Governance schafft Vertrauen. Kubeflow ist seit 2024 ein Cloud-Native-Computing-Foundation-Projekt (Incubating) — derselbe Stiftungs-Rahmen wie Kubernetes selbst, Prometheus oder Argo. Das bedeutet: offene Governance, transparente Entscheidungsprozesse, multi-vendor Steuerung. Für Konzern-Beschaffungsprozesse ist das oft ein wichtigeres Argument als die rein technische Qualität — kein einzelner Anbieter kann das Projekt einseitig richten oder einstellen.

Echte On-Prem-Fähigkeit ist fast einzigartig. Im Markt der ML-Plattformen ist Kubeflow eine der wenigen ernstzunehmenden Optionen, die vollständig in privater Infrastruktur laufen. Sagemaker und Vertex AI sind Cloud-only. Databricks ist Hybrid, aber kommerziell. Für regulierte Branchen, in denen Trainingsdaten das Rechenzentrum nicht verlassen dürfen, ist Kubeflow oft der einzige Weg.

Spark Operator für Big-Data-ML-Workloads. Der Spark Operator (3.100 Stars) macht Apache Spark zu einem first-class Kubernetes-Bürger — Feature-Engineering auf Terabyte-Daten, klassisches ML-Training auf Spark MLlib, alles in derselben Plattform wie das tiefen-neuronale Training. Diese Bandbreite ist bei kommerziellen Plattformen oft fragmentiert.

Schwächen ehrlich betrachtet

Die Komplexität ist nicht zu unterschätzen. Eine Produktiv-Installation erfordert tiefes Wissen in Kubernetes (Networking, Storage, RBAC, Custom Resources), Istio (Service Mesh, Traffic Management), Knative (Serverless), Argo Workflows (DAGs für Pipelines) und den sieben Kubeflow-Komponenten selbst. Das ist nicht „in einer Woche” lernbar — Plattform-Engineers brauchen typischerweise drei bis sechs Monate, um sicher zu werden. Wer eine ML-Plattform mit weniger Lernkurve sucht, ist mit kommerziellen Alternativen besser bedient.

Komponenten sind lose gekoppelt. Die sieben Projekte haben eigene Maintainer, eigene Release-Zyklen, eigene Dokumentationen. Versionssprünge müssen oft komponentenweise nachgezogen werden, Inkompatibilitäten zwischen Pipeline-Version X und Training-Operator-Version Y sind nicht selten. Das „Manifests-Repo” als zentrale Installations-Quelle hat in der Vergangenheit immer wieder Probleme bei größeren Versionssprüngen verursacht. Wer eine kohärente Out-of-the-Box-Plattform erwartet, wird enttäuscht.

Vertex AI Pipelines ist kein vollwertiger Managed-Kubeflow. Google Cloud bietet Pipelines als Managed-Service — aber nur diese eine Komponente, nicht die volle Suite. Wer KServe oder Katib „managed” will, findet bei keinem Hyperscaler eine direkte Entsprechung. Charmed Kubeflow von Canonical ist die einzige seriöse kommerzielle Distribution, aber kein Hyperscaler-Service mit globaler Verfügbarkeit.

Keine deutschsprachigen Ressourcen. Dokumentation, Community-Foren, Konferenz-Talks, Bücher — alles auf Englisch. Für deutsche Engineering-Teams meist akzeptabel, aber bei Schulungen oder bei Compliance-Dokumentationen für deutsche Auditoren spürbarer Mehraufwand.

Hoher Personalbedarf trotz Open-Source-Lizenz. Die ehrliche Rechnung: Vanilla-Kubeflow on-prem mit GPU-Cluster benötigt typischerweise ein Plattform-Team von zwei bis vier Personen plus Bereitschaft. Personalkosten dafür liegen bei 300.000 bis 600.000 Euro pro Jahr — die „kostenlose” Lizenz ist also relativ. Bei Vertex AI oder SageMaker bekommt man Vergleichbares ohne dieses Personal, dafür mit laufenden Cloud-Gebühren und Vendor-Bindung. Welche Rechnung günstiger ausgeht, hängt stark von Größe und Workload ab.

Roadmap ist langsamer als bei kommerziellen Plattformen. SageMaker und Vertex AI veröffentlichen wöchentlich neue Features, Kubeflow alle paar Monate ein Komponenten-Release. Wer die neueste Funktionalität (etwa generative-AI-spezifische Werkzeuge) zeitnah braucht, ist in den Hyperscaler-Plattformen schneller bedient.

Alternativen im Vergleich

Wenn du…	…nimm stattdessen
Eine vollständig managed ML-Plattform auf AWS willst	Amazon SageMaker
Eine Hybrid-Plattform für Data + ML aus einer Hand willst	Databricks
Nur ML-Pipelines orchestrieren willst, keine ganze Plattform	Apache Airflow
Einen LangChain-/LlamaIndex-Stack für GenAI bauen willst	Hugging Face als Modell-Hub

Erwähnenswert ohne eigene Tool-Seite oder als Subset: Vertex AI Pipelines (Google) bietet ein Managed-Subset von Kubeflow Pipelines, deckt aber nur einen Teilbereich ab. Azure ML ist Microsofts Managed-Konkurrent mit eigener API, nicht Kubeflow-kompatibel. MLflow (von Databricks) ist deutlich schlanker — Tracking, Registry, Modell-Packaging — und wird oft mit Kubeflow oder Airflow kombiniert, nicht als Konkurrenz. Ray (von Anyscale) ist Kubeflow-Konkurrent vor allem für verteiltes Training und Inferenz, mit modernerer Python-API, aber kleinerer Suite. Im Open-Source-MLOps-Markt bleibt Kubeflow trotz aller Komplexität der breiteste Baukasten.

So steigst du ein

Schritt 1: Lokal mit Minikube oder Kind starten. Bevor du einen Cluster aufsetzt, installiere Kubeflow lokal mit der kfctl-CLI oder dem offiziellen Manifests-Repo auf Minikube oder Kind. Verstehe die Komponenten-Architektur: Was macht der Central Dashboard, wie funktionieren Notebook-Server, was ist eine Pipeline-Komponente. Dieser Schritt dauert ein bis zwei Wochen — ohne ihn lohnt der Sprung in einen Produktiv-Cluster nicht.

Schritt 2: Eine Distribution wählen, nicht Vanilla. Für Produktiv-Setups ist Vanilla-Kubeflow ohne Distribution selten die richtige Wahl. Wähle stattdessen eine vorintegrierte Variante: Charmed Kubeflow (Canonical) bietet kommerziellen Support, AWS-Distribution liefert IAM- und S3-Integration, GCP bietet zumindest Pipelines als Managed Vertex AI. Die Distribution erspart dir Wochen Integrationsarbeit und liefert getestete Konfigurationen.

Schritt 3: Mit einem konkreten Use Case beginnen. Setze nicht „eine Plattform” auf, sondern wähle eine erste echte ML-Pipeline (etwa: täglich Bestelldaten extrahieren, Feature Engineering mit Spark, Modell trainieren mit PyTorch, deployen mit KServe). Baue diese End-to-End auf Kubeflow. Erst wenn ein Workflow läuft, skaliere auf weitere Teams. Plattformen, die ohne ersten konkreten Anwender aufgebaut werden, scheitern überdurchschnittlich oft.

Ein konkretes Beispiel

Eine deutsche Versicherung in Stuttgart (1.200 Mitarbeitende, eigenes Rechenzentrum) baut eine zentrale ML-Plattform für drei Data-Science-Teams. Anforderung: Alle Modelle müssen auf konzerneigener Infrastruktur trainiert und ausgeliefert werden — Cloud-Hosting ist aus regulatorischen Gründen ausgeschlossen. Das Plattform-Team aus drei Personen baut über sechs Monate eine Kubeflow-Installation auf einem hauseigenen OpenShift-Cluster mit 32 GPU-Knoten. Resultat nach einem Jahr: 18 produktive Modelle (Schadenklassifikation, Betrugserkennung, Kündigungsprädiktion) auf KServe ausgeliefert, wöchentliche Re-Trainingspipelines über Kubeflow Pipelines orchestriert, Notebook-Server für jede Data Scientist mit GPU-Quota. Die anfängliche Aufbauinvestition (rund 600.000 Euro Personalkosten plus Hardware) hat sich bilanziell durch eingesparte Cloud-Kosten bei ähnlichem Workload nach circa zwei Jahren amortisiert — und die Aufsichtsbehörde-Auditierung läuft sauber, weil alle Daten das Haus nicht verlassen.

DSGVO & Datenschutz

• Datenhosting: Vollständig in deiner Hand. Kubeflow ist Software, kein Service — sie läuft, wo du sie installierst (on-prem, eigene Cloud, jeder Kubernetes-Cluster). Keine Telemetrie an Dritte in der Standardkonfiguration.
• Datennutzung: Apache 2.0-Software ohne Anbieter-Phone-Home. Bei Distributionen prüfen: Charmed Kubeflow von Canonical sendet Telemetrie für Subscription-Management, lässt sich aber abschalten.
• Auftragsverarbeitung (AVV): Nicht relevant für Self-Hosting (du verarbeitest nicht im Auftrag von Kubeflow). Bei Managed-Subsets: Vertex AI Pipelines fällt unter den Google-Cloud-AVV; Charmed Kubeflow Support unter den Canonical-Vertrag.
• Sensible Daten in Pipelines: Nutze Kubernetes-Secrets, externe Secret-Manager (HashiCorp Vault, Sealed Secrets) und konfiguriere Pipeline-Logs sauber — Trainingslogs können personenbezogene Daten enthalten, wenn Rohdaten gedruckt werden.
• Empfehlung für DSGVO-sensible Branchen: Kubeflow ist genau für diesen Anwendungsfall gebaut. On-Prem-Installation auf eigenem OpenShift- oder Vanilla-Kubernetes-Cluster ist der sauberste Pfad. Vor Produktiveinsatz Datenschutz-Folgenabschätzung durchführen, besonders bei Trainingsdaten, die personenbezogene Informationen enthalten. Die Modell-Auslieferung über KServe lässt sich vollständig im internen Netz halten — kein API-Aufruf verlässt das Haus.

Gut kombiniert mit

• Apache Airflow — viele Teams nutzen Airflow als übergreifende Daten-Orchestrierung (ETL, Vorbereitung, Trigger) und Kubeflow Pipelines speziell für ML-Trainings-DAGs. Airflow ruft via Operator Kubeflow-Pipeline-Runs auf, Status fließt zurück. Saubere Trennung zwischen Daten-Pipelines und ML-Workflows.
• Hugging Face — als Modell-Hub und Tokenizer-Quelle. Modelle aus Hugging Face werden im Training Operator feingetuned und über KServe mit dem HuggingFace-Backend ausgeliefert. Diese Kombination ist Standard für moderne Open-Source-LLM-Stacks.
• MLflow (kein eigener Tool-Eintrag) — wird oft als Experiment-Tracking und Model Registry parallel zu Kubeflow eingesetzt, weil Kubeflows eigene Model Registry vergleichsweise jung ist (0.1K Stars, 2024 ergänzt). MLflow hat hier deutlich mehr Reife. Beide Welten lassen sich integrieren, sind aber organisatorisch zu klären.

Unser Testurteil

Kubeflow verdient 3 von 5 Sternen. Die Funktionalität ist beeindruckend — eine vollständige Open-Source-MLOps-Plattform mit verteiltem Training, Pipelines, AutoML, Serving und Notebooks gibt es sonst nirgends in dieser Tiefe. Aber die Einstiegshürden sind hoch, die Integration der sieben Komponenten ist Eigenarbeit, und die Roadmap geht langsamer als bei kommerziellen Konkurrenten. Wer Kubeflow erfolgreich betreibt, hat ein dediziertes Plattform-Team und eine echte On-Prem- oder Souveränitäts-Anforderung — für diese Zielgruppe sind 5 Sterne gerechtfertigt. Für alle anderen ist die ehrliche Empfehlung: SageMaker oder Vertex AI prüfen, dort schneller produktiv werden, Vendor-Bindung als Preis akzeptieren. Den Mittelweg — „mal eben Kubeflow ausprobieren” — gibt es kaum; entweder du investierst ernsthaft, oder du wählst etwas anderes.

Was wir bemerkt haben

• Mai 2026 — Aktuelle stabile Version ist Kubeflow 1.10. Die Entwicklung läuft kontinuierlich, aber langsamer als bei kommerziellen Konkurrenten — typisches Tempo für CNCF-Projekte mit Multi-Vendor-Governance.
• 2024 — Kubeflow ist offiziell unter das CNCF-Dach (Incubating) gewandert. Vorher wurde das Projekt von Google initiiert und maßgeblich gepflegt. Die Übergabe an die CNCF schafft mehr Vendor-Neutralität, was für Konzern-Beschaffungen ein wichtiges Signal ist.
• 2024–2025 — Model Registry ist als siebte Hauptkomponente offiziell ergänzt worden. Vorher war diese Lücke ein häufiger Kritikpunkt — viele Teams haben MLflow parallel betrieben. Die Kubeflow-eigene Registry ist allerdings noch jung und an Reife mit MLflow nicht gleichauf.
• 2025 — Spark Operator wurde formal Teil der Kubeflow-Familie (vorher unter Google-Cloud-Plattform geführt). Damit deckt Kubeflow auch Big-Data-orientiertes Feature-Engineering nativ ab — eine Lücke, die in der Vergangenheit oft mit Workarounds geschlossen wurde.
• 2024–2026 — Vertex AI Pipelines (Google Cloud) hat sich als de-facto Managed-Kubeflow-Pipelines etabliert, deckt aber nur diese eine Komponente ab. Eine vollwertige Managed-Kubeflow-Plattform bei einem Hyperscaler gibt es weiterhin nicht — das bleibt eine Lücke, die Charmed Kubeflow von Canonical teilweise kommerziell schließt.
• Mai 2026 — Die offizielle Distribution-Liste auf kubeflow.org enthält weiterhin AWS, GCP, Azure, Red Hat OpenShift und Charmed Kubeflow. Die Auswahl wirkt stabil, aber wenig erweitert — viele Teams setzen am Ende doch auf Vanilla-Kubeflow plus Eigenintegration, weil Distributionen oft Versionen hinterherhängen.