close-icon
Abonnieren, um mehr über dieses Thema zu erfahren
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Kubeflow: Noch nicht bereit für Produktion?

Warum wir Kubeflow aus unserer Machine Learning Architektur gestrichen haben.

datarevenue-icon
by
DataRevenue
Markus Schmitt

Wir arbeiten gerade an einer Machine Learning Referenzarchitektur: Eine komplette Sammlung von Architecture-as-Code Skripten und Dokumentation mit denen jeder eine umfassende Machine Learning Architektur aufsetzen kann.

Kubeflow – eine Machine Learning Plattform, die auf Kubernetes basiert und ein ähnliches Ziel verfolgt – schien zunächst hervorragend in die Architektur zu passen. Nachdem wir das Tool einige Wochen lang getestet haben, mussten wir uns nun jedoch dazu entscheiden, es wieder aus unserem Projekt herauszunehmen.

In diesem Artikel schildern wir unsere Erfahrungen mit Kubeflow. Mit dieser Analyse möchten wir anderen dabei helfen, rechtzeitig zu erkennen, dass Kubeflow vielleicht noch nicht ganz das ist, was es zu sein verspricht.

Kurzer Disclaimer: Kubeflow weist einige Schwächen auf, die uns dazu bewegt haben, es nicht weiter in unser Projekt zu integrieren. Trotzdem schätzen wir die Ambitionen von Kubeflow und hoffen, dass es sich ausreichend weiterentwickelt und wir es in Zukunft wieder aufgreifen können.

Die Stärken von Kubeflow

Beginnen wir mit der Frage, warum wir uns anfangs überhaupt für Kubeflow begeistern konnten. Machine Learning Projekte bestehen in der Regel aus vielen verschiedenen Komponenten, die sich grob in drei Kategorien einteilen lassen:

  • Datentransformation: Daten werden vor dem Training aufbereitet und bereinigt;
  • Training des Modells: Das Modell wird anhand der aufbereiteten Daten trainiert;
  • Einsatz des Modells: Anhand des trainierten Modells werden Vorhersagen für neue Daten gemacht.

Wenn wir die Bestandteile von Machine Learning-Projekten so betrachten wie Andreessen Horowitz es beschreibt, kann Kubeflow wichtige Punkte in den drei genannten Kategorien abdecken - zumindest theoretisch. Auf den ersten Blick scheint es durchaus praktisch, ein einziges Tool für all diese verschiedenen Aufgaben einsetzen zu können.

Ein Diagramm, das die Komponenten eines ML-Systems zeigt und sie in die Kategorien Datentransformation, Modelltraining und -entwicklung sowie Modellinferenz einteilt.
Wir haben nach einem Tool gesucht, das viele verschiedene Komponenten vereint. Kubeflow konnte unsere Erwartungen leider nicht erfüllen.

Da wir uns bereits auf Kubernetes festgelegt hatten und ausschließlich Open-Source-Tools verwenden möchten, schien Kubeflow für unser Projekt hervorragend zu passen.

Leider stellte sich schnell heraus, dass Kubeflow schwierig einzurichten, schwer zu konfigurieren und unzuverlässig ist. Außerdem basiert es auf zahlreichen veralteten Komponenten und Bibliotheken. Zusätzlich hat sich ein Großteil der Dokumentation als fehlerhaft oder veraltet herausgestellt. Wir haben es nicht geschafft, es sauber in AWS und GitHub zu integrieren, ohne auf ein paar umständliche Workarounds zurückzugreifen.

Auf jeden dieser Punkte möchten wir an dieser Stelle im Detail eingehen.

Interessierst du dich für neue Artikel?

Melde dich hier für unseren wöchentlichen Newsletter an und erhalte unseren nächsten Artikel zu MLOps Architekturen per Email.

Danke!
Oops! Hier ist etwas schief gelaufen.

Die Schwächen von Kubeflow

Probleme bei der Erstinstallation

Schon bevor wir uns für Kubeflow entschieden haben, wussten wir, dass wir uns auf eine steile Lernkurve einstellen müssen. Da unser Team aber reichlich Kubernetes Erfahrung aufweist, haben wir mit keinen großen Problemen bei der Installation gerechnet.

Selbst Tage nach unserem ersten Anlauf hatten wir noch mit Fehlern mit KFDef und Kustomize-Manifesten zu kämpfen. Die verfügbaren Manifeste schlugen wiederholt und ohne eindeutige Fehlermeldungen fehl, sodass wir jede Installationskomponente manuell überprüfen mussten.

Unser Ziel bestand darin, Kubeflow mit der GitHub-Authentifizierung zu integrieren, aber das für AWS und OpenID Connect (OIDC) bereitgestellte Manifest enthielt einen Fehler, der auch Kubeflow-Ingress betraf. Daher mussten wir Ingress manuell updaten, um die erforderlichen OIDC-Informationen verwenden zu können.

Alles in allem läuft Kubeflow zwar auf Kubernetes und hat den Anspruch, Cloud-unabhängig zu sein; Wir sind jedoch auf viele Probleme gestoßen, als wir Kubeflow auf AWS nutzen wollten. Wahrscheinlich wäre dieser Prozess reibungsloser verlaufen, wenn wir uns stattdessen für Google Cloud (GCP) entschieden hätten. Da Kubeflow von Google entwickelt wurde, ist es oft auf GCP ausgerichtet und funktioniert noch nicht so gut mit anderen Cloud-Anbietern - vor allem, wenn es um Authentifizierung und das Einrichten verschiedener Berechtigungen geht.

Probleme bei der Integration der Komponenten

Kubeflow besteht aus vielen verschiedenen, lose miteinander verbundenen Bestandteilen. Diese lose Verknüpfung ist praktisch, weil wir dadurch theoretisch selbst entscheiden können, welche Komponenten wir verwenden möchten. Es bringt allerdings auch Nachteile mit sich: Unterschiedliche Komponenten benötigen unterschiedliche Versionen der gleichen Software-Module, wodurch weitere Probleme entstehen.

Bei unseren Testläufen haben wir festgestellt, dass ein Upgrade einer Komponente oft eine andere Komponente unbrauchbar macht. Das Upgrade der KFServing-Komponente erforderte zum Beispiel ein Upgrade von Istio - der Mesh-Service-Plattform, die Kubernetes-Dienste für den Datenaustausch untereinander nutzen. Nach diesem Upgrade konnten wir nicht mehr auf das Dashboard zugreifen, da die neuere Istio-Version nicht mit der AWS-Authentifizierung kompatibel ist.

So entstand eine Reihe inkompatibler Versionen, und die einzige Abhilfe bestand darin, Kubeflow noch einmal komplett neu zu installieren. 

Außerdem wollten wir unsere Pipelines direkt aus Notebooks heraus erstellen, was sich jedoch selbst mit einigen Workarounds als unmöglich herausstellte – es gab trotzdem noch Schwierigkeiten mit Kubeflow. Ein AWS Entwickler hat es auf GitHub passend ausgedrückt: “In-Cluster-Kommunikation von Notebooks zu Kubeflow Pipeline wird in dieser Phase nicht unterstützt.” 

Probleme mit der Dokumentation

Viele der Dokumentationsseiten sind als "out of date" gekennzeichnet, darunter auch wichtige Kubeflow-Komponenten wie Jupyter Notebooks.

Einige alte Dokumentationsseiten sind nicht einmal als “out of date” gekennzeichnet. Dadurch war es sehr schwer herauszufinden, wann wir der Dokumentation bei der Fehlersuche vertrauen konnten - um zu wissen, ob der Fehler an uns oder an der veralteten Dokumentation lag. 

Viele der Links in der Dokumentation lieferten auch Meldungen wie "Seite nicht gefunden" oder "Diese Seite existiert nicht". Das hat für einiges an Frust gesorgt und den Prozess weiter verlangsamt.

Die Zukunft von Kubeflow?

Im Oktober wurde ein Artikel mit dem Titel “Is Kubeflow Dead?” veröffentlicht, der beschreibt, dass sich Kubeflow vermutlich deshalb aktuell langsamer entwickelt, weil einige der leitenden Entwickler das Team verlassen haben.

Der Artikel beschreibt außerdem, dass sich die Entwicklung aus dem Haupt-Repository in die Unter-Repositories verlagert und deshalb langsamer vorangeht. Allerdings konnten wir auch viele unserer eigenen Erfahrungen in den Beschreibungen anderer Community Mitgliedern wieder finden. Luke Marsden schreibt zum Beispiel:

“Ich komme mit Kubeflow 1.1 nur schwer zurecht. Meiner Meinung nach fehlt der Fokus auf die User Experience, die viel komplizierter ist, als sie sein müsste.”

Auch Clive Clox schreibt:

“Kubeflow ist ein gesamtes Ökosystem, in dem bestimmte Projekte mehr genutzt werden als andere. Ich glaube, dass es für die Entwickler eine Herausforderung darstellt, alles in ein einheitliches Gesamtbild zu bringen.”

Kann man mit einzelnen Kubeflow Komponenten arbeiten?

Der Schwerpunkt von Kubeflow liegt auf Kubeflow Pipelines, das man auch einzeln verwenden könnte. Aber selbst damit hatten wir Probleme. Es ist nämlich nicht immer eindeutig, welche Komponenten unbedingt notwendig und welche lediglich optional sind. Angesichts der mangelhaften Dokumentation ist es sehr zeitaufwändig und fehleranfällig, das selbst herauszufinden.

Aus diesen Gründen haben wir uns entschieden, vorerst keine Kubeflow-Komponenten mehr zu verwenden. Stattdessen verwenden wir Prefect als Workflow-Tool verwenden - unsere Erfahrungen damit kannst du hier nachlesen.

Setze deine MLOps-Infrastruktur auf

Wir können dir helfen, deine Machine Lösungen in Produktion zu bringen. Kontaktiere uns wenn du hands-on Beratung für deine MLOps-Infrastruktur suchst.

Bekomme immer die neusten Artikel

Trag dich mit deiner E-Mail ein, um du bekommst jede Woche unseren neusten Artikel.

Ich danke Ihnen! Ihre Einreichung ist eingegangen!
Oops! Something went wrong while submitting the form.