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.
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.
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.
