MLOps-Einführung leicht gemacht mit Kubeflow
In den vergangenen Jahren hat die MLOps-Plattform Kubeflow deutlich an Popularität gewonnen. Nun dürften weitere Unternehmen das Open-Source-Produkt durch seine Aufnahme in das CNCF-Incubator-Projekt und die damit verbundene Entwicklung hin zum Branchenstandard als Grundgerüst ihrer ML-Infrastruktur in Betracht ziehen. Doch wie gelingt die herausfordernde Einführung des hinreichend komplexen Open-Source-Systems? Wie können diverse Aspekte, wie User-Experience, IT-Sicherheitsfragen und Compliance bedarfsgerecht umgesetzt werden?
In diesem Artikel beleuchten wir das Kubeflow-Ökosystem sowie verschiedene Aspekte und Überlegungen, die bei der Einführung der Kubeflow-Plattform berücksichtigt werden müssen. Hierbei berichten wir aus unseren mehrjährigen Erfahrungen des Kubeflow-Cluster-Managements. Dabei gehen wir sowohl auf organisatorische als auch technische Aspekte ein, nennen infrastrukturelle und personelle Anforderungen sowie angemessene Ansätze für das Management von Manifest-Modifikationen und die Bereitstellung von Notebook-Umgebungen für Data Scientists.
Künstliche Intelligenz und Machine Learning mit Kubeflow: Einleitung
Angesichts der allgegenwärtigen und wachsenden Bedeutung von Machine Learning und Künstlicher Intelligenz stehen Unternehmen zunehmend vor der Herausforderung, komplexe ML-Modelle effizient zu entwickeln, bereitzustellen und zu betreiben. In diesem Zusammenhang hat sich die Disziplin der Machine Learning Operations (MLOps) entwickelt, die ähnlich wie die der DevOps darauf abzielt, Prozessoptimierungen im gesamten Lebenszyklus von ML-Anwendungen zu realisieren.
MLOps kann vereinfacht als Continuous Integration und Continuous Deployment (CI/CD) für Künstliche Intelligenz verstanden werden. Dabei sollen alle Aspekte vom Laden und Validieren der Daten bis hin zum Modell-Training, Tuning, Validieren, Model-Serving und dem fortlaufenden Monitoring der Modelle in vollautomatisierten Workflows oder Pipelines verwaltet werden. Diese ermöglichen eine reproduzierbare und effiziente Verwaltung des gesamten Lebenszyklus von der Dateneingabe bis zur Inbetriebnahme des ML-Artefakts.
Kubeflow ist eine ursprünglich von Google entwickelte Open-Source-Plattform, die speziell für die Implementierung von MLOps entwickelt wurde. Sie wird seit vergangenem Jahr vom CNCF gemanagt und kann sich allmählich als Branchenstandard etablieren. Als Cloud-Native-Anwendung basiert sie auf Kubernetes und verbindet dessen Vorteile wie Skalierbarkeit und Ressourcenmanagement nahtlos mit den Anforderungen der Datenwissenschaften. Kubeflows umfassendes Ökosystem unterstützt Data Scientists über alle Phasen der ML-Entwicklung hinweg. Im Kern stehen hierbei Notebooks und Pipelines, die sowohl manuelle als auch vollautomatisierte Entwicklungsschritte unterstützen.
Dieser Artikel basiert auf unseren mehrjährigen Erfahrungen im Kubeflow-Cluster-Management und beschreibt typische Facetten der Einführung und Bereitstellung von Kubeflow in Unternehmen. Im Fokus stehen dabei Überlegungen, die darauf abzielen, die betriebliche und administrative Komplexität von Kubeflow zu reduzieren. Wir werden zeigen, dass Kubeflow iterativ und agil bereitgestellt und weiterentwickelt werden kann. Statt eines großen, teuren Wurfs kann die Plattform so in Inkrementen getestet und auf die Bedürfnisse des Unternehmens und der Data Scientists zugeschnitten werden.
Mit Kubeflow zur eigenen MLOps-Plattform: Der Beginn einer Reise
Kubeflow stellt keine Off-the-shelf-Distribution bereit, sondern verfolgt die Philosophie, dass Unternehmen die Plattform an ihre spezifischen Bedürfnisse anpassen bzw. in ihren Kontext integrieren müssen. Jeder Aspekt der Plattform kann dementsprechend angepasst werden. Hierbei sollten die spezifischen Anforderungen der Data Scientists stets im Vordergrund stehen. Diese ergeben sich jedoch oft erst durch die Nutzung der Plattform in ihrem jeweiligen Kontext.
Folglich kann der Weg zur eigenen MLOps-Plattform als agile Reise verstanden werden, bei der wir iterativ vorgehen und uns dabei nach und nach über die nächsten Schritte und Bedürfnisse klarwerden. Aufgrund der sich ständig verändernden Natur der Bereiche Data Science und Cloud ist zu erwarten, dass diese Reise nie wirklich endet: Kontinuierliche Updates, Weiterentwicklungen, neue Technologien und der Benutzer-Support erfordern fortlaufende Administration und Management.
Unterstützt werden wir in diesem Modus von Kubeflows Eigenschaft, schnell in einer rudimentären Form nutzbar zu sein: Eine bereitgestellte Beispielinstallation im Cluster ermöglicht die Entwicklung innerhalb vorkonfigurierter IDEs und Pipelines. Dadurch können schnell wertvolle Erfahrungen gesammelt werden, die weitere Anpassungen der Plattform leiten. Im Folgenden werden wir die typischen Stationen dieser Reise darlegen und Ihnen Tipps geben, diese zu meistern.
Kubeflow im Kubernetes-Cluster
Um die Komplexität des breiten Kubeflow-Stacks erfolgreich zu bewältigen und die Plattform an die Bedürfnisse der Data Scientists anzupassen, sind fundierte Kenntnisse in Cloud- und Kubernetes-Technologien unerlässlich. Zahlreiche Anpassungen und Modifikationen erfordern zudem ausgeprägte Software-Engineering-Fähigkeiten sowie eine kritische Betrachtung von Security-Aspekten. Ein Verständnis von KI und Data Science ist ebenfalls vonnöten, um die benötigten Funktionen angemessen einzuschätzen. Basierend auf unseren Erfahrungen sollte ein Kubeflow-Team zu Beginn optimalerweise aus zwei Personen bestehen, die sich dediziert und kontinuierlich um den Betrieb der Plattform kümmern. Im weiteren Verlauf, wenn Anpassungen und Weiterentwicklungen abnehmen, kann sich der benötigte Aufwand jedoch erheblich verringern.
Infrastrukturell setzt Kubeflow lediglich ein Kubernetes-Cluster voraus. Die Art des Clusters ist dabei unerheblich; Cloud, lokale oder hybride Cluster können je nach Verfügbarkeit und Anforderungen genutzt werden und geben Freiheit, Kubeflow in verschiedensten Umgebungen einzusetzen. Plattformen wie OpenShift haben sich ebenfalls bewährt, benötigen durch spezielle Konzepte und Policies jedoch meist zusätzliche Anpassungen. Optimalerweise wird der Cluster von einem separaten Team oder Anbieter verwaltet, um sicherzustellen, dass das Kubeflow-Team nicht zusätzlich durch den komplexen Kubernetes-Betrieb belastet wird. Eine enge Zusammenarbeit der Teams ist dennoch von großem Vorteil, da Kubeflow sich in seiner Natur deutlich von einer durchschnittlichen Kubernetes-Anwendung unterscheidet und ML-Workflows die Kapazitäten des Clusters ausreizen bzw. es auf die Probe stellen.
Ein wichtiger Cluster-Aspekt ist die Hardware-Konfiguration, die den Bedürfnissen der Data Scientists entsprechen sollte. Während genügend CPUs und Arbeitsspeicher in der Regel leicht bereitgestellt werden können, gestaltet sich die Einführung von GPUs oft schwieriger. Bei Cloud-Anbietern können Verfügbarkeit und Kosten von GPUs stark variieren. In lokalen Systemen sind Beschaffung und Lizenzierung äußerst kostspielig. Hier sollte zudem die Auslastung der GPUs optimiert werden, insbesondere wenn leistungsfähige Grafikkarten, wie die A100 oder H100, installiert werden. Denn diese können schnell durch einzelne Jobs blockiert, aber nicht voll ausgelastet werden. Funktionen wie Multi-Instance GPU (MIG) oder Time-Slicing können helfen, eine Grafikkarte für mehrere Data Scientists gleichzeitig zugänglich zu machen und damit die Auslastung erhöhen.
Es sei an der Stelle darauf hingewiesen, dass einige Cloud-Anbieter gemanagte Kubeflow-Services anbieten. Diese verringern Betriebsaufwände enorm, indem sie passend vorkonfiguriert sind, benötigte Ressourcen bereitstellen und automatisch skalieren. In diesem Artikel liegt jedoch kein Fokus darauf, da ein gemanagter Service viele Vorteile der Open-Source-Plattform negieren kann, wie beispielsweise ihre Flexibilität oder Erweiterbarkeit.
Kubernetes-Manifest auf GitHub: Das Werkzeug
Steht ein Cluster bereit, so kann Kubeflow mithilfe der auf GitHub bereitgestellten Kubernetes-Manifeste installiert werden [1]. Diese YAML-Ressourcen müssen mittels Kustomize, einem Tool zur Konfigurationsverwaltung von Kubernetes-Ressourcen, gebaut werden, bevor das Cluster sie anwenden kann. Im Unterschied zu Helm, einem ähnlichen Tool, arbeitet Kustomize ausschließlich mit deklarativen Operationen. Das ermöglicht es, durch Overlays und Patches jede beliebige Änderung im umfangreichen Manifest-Repository vorzunehmen und nicht nur solche, die vom Anbieter vorgesehen wurden.
Folglich dient das Manifest-Repository als Startpunkt für jede Kubeflow-Installation und als Ausgangspunkt für alle unternehmensspezifischen Anpassungen. Es empfiehlt sich, ein eigenes Manifest-Repository mit einer Kustomize-Anwendung anzulegen, die auf das Upstream-Kubeflow-Repository als Basis verweist (beispielsweise als Git-Submodule) und alle spezifischen Änderungen vornimmt. Dadurch werden eigene Änderungen von denen des Upstreams getrennt verwaltet. Weiterhin sollte die Komplexität der Modifikationen gering gehalten und gut dokumentiert werden. Beides erweist sich insbesondere beim Aktualisieren auf neue Kubeflow-Versionen als äußerst vorteilhaft. Denn hier ändern sich die Upstream-Manifeste, sodass vorgenommene Overlays und Patches häufig nicht mehr funktionieren.
In den meisten Fällen sind keine weiteren Anpassungen erforderlich, um die Beispielinstallation zu bauen (kustomize build) und auf dem Cluster bereitzustellen (kubectl apply). Nach diesem Schritt ist Kubeflow in seiner Standardkonfiguration einsatzbereit. Weitere Funktionen und Prozessoptimierungen werden hiernach bedarfsgerecht in Iterationen hinzugefügt. Die weitere Arbeit des Kubeflow-Teams wird somit größtenteils in den Manifestdateien stattfinden.
Erfolgreiche Kubeflow-Einführung: User first
Ein zentraler Aspekt für eine erfolgreiche Kubeflow-Einführung und weitere Anpassungen ist die Benutzerfreundlichkeit. Eine klare Fokussierung darauf führt zu erhöhter Zufriedenheit und verringert den organisatorischen Widerstand gegen die Plattform-Einführung. Dabei ist es wichtig zu beachten, dass viele Data Scientists nur begrenzte Erfahrung mit Cloud-Technologien oder Kubeflow haben. Obwohl Kubeflow an vielen Stellen von Kubernetes abstrahiert, gibt es dennoch Bereiche, in denen keine UI-Unterstützungen bereitstehen und Anleitung benötigt wird, um KI-Anwendungen erfolgreich umzusetzen.
Dementsprechend ist eine gut strukturierte und leicht zugängliche Dokumentation wichtig, um Data Scientists zu unterstützen und ein reibungsloses Onboarding zu ermöglichen. Diese Dokumentation kann beispielsweise mithilfe von Tools wie Docusaurus über ein Web-Interface bereitgestellt und direkt in das Frontend von Kubeflow integriert werden, um eine hohe Sichtbarkeit zu gewährleisten. An der Praxis bzw. an Code orientierte Dokumentation ist hierbei besonders hilfreich und dient als Vorlage für neue Pipelines.
Zusätzlich helfen eigens bereitgestellte Packages, beispielsweise für Python, häufig verwendete Code-Fragmente zu standardisieren und Prozesse zu vereinfachen. Zum Beispiel können Methoden zur Authentifizierung am Cluster bereitgestellt werden, die es Data Scientists erlauben, den Cluster ausgehend von ihrer lokalen Maschine anzusprechen und somit das Pipeline-Feature mit einer lokalen Entwicklungsumgebung zu nutzen. Analog dazu kann ein Component-Hub eingerichtet werden, in dem häufig wiederkehrende Pipeline-Schritte zentral bereitgestellt und gewartet werden, um redundante Arbeit in den Teams zu vermeiden und ihre Effizienz zu steigern.
Kubeflow führt Code und Jobs der Data Scientists ausnahmslos in eigenen Containern, Notebooks, Pipelines etc. aus. Daher empfiehlt es sich, Standard-Images bereitzustellen, die für die Ausführung genutzt werden können. Diese bieten auf das Unternehmen zugeschnittene Standardkonfigurationen für IDEs, wie Jupyter oder VSCode, installieren Packages vor sowie Tools wie Pip und Git. Nach Bedarf können sie durch die Teams entsprechend genutzt oder auch erweitert werden. Der Aufwand für das Bauen und Warten dieser Images sollte nicht unterschätzt werden; insbesondere Notebooks bedürfen Kubeflow-spezifischer Konfiguration und müssen aufgrund von Package-Updates und sich ändernden Anforderungen regelmäßig aktualisiert werden.
Trotz aller vorausschauender, unterstützender Vorkehrungen ist es von entscheidender Bedeutung, Feedback-Zyklen einzurichten und regelmäßige Austauschrunden zu organisieren. Durch den Aufbau einer aktiven Community können Fragen, Probleme und Ideen diskutiert werden, um die Plattform kontinuierlich zu verbessern und den Anforderungen der Data Scientists gerecht zu werden.
GitOps-Tools im Backbone: Vereinfachung des Betriebs
Ein weiterer, wesentlicher Faktor für die erfolgreiche Einführung von Kubeflow ist die Vereinfachung der Abläufe und die Reduzierung manueller Prozesse sowie möglicher Betriebsrisiken. ArgoCD kann hier als GitOps-Tool eine Schlüsselrolle als Backbone für die Installations-Prozesse einnehmen. Durch die deklarative Definition der Applikation mithilfe der YAML-Manifeste (Infrastructure as Code; die gesamte Anwendungskonfiguration ist textuell definiert) kann die Anwendung jederzeit wiederhergestellt bzw. auf ein anderes Cluster migriert werden. Die Nutzung von Linting, etwa mit kube-lint und yamllint, sichert die Einhaltung von Best Practices und Qualitätsstandards bei der Konfiguration von Kubernetes-Ressourcen.
Sowohl Kubeflows Artifact Storage als auch seine SQL-Datenbanken sind kritische Komponenten, die gegen Ausfälle gesichert werden müssen. So können extern gemanagte Systeme helfen, Komplexität und Risiken des Betriebs zu minimieren, indem sie Skalierung, Backup-Prozesse und Datensicherheit erleichtern. Zudem sollte der Artifact Storage um Mandantenfähigkeit erweitert bzw. die Artefakte nach ihren Namespaces isoliert werden; ein Feature, das von der Community technisch gelöst, viel diskutiert, aber bisher nicht implementiert wurde.
Des Weiteren sind End-to-End-Tests notwendig, um die Funktionalität und Integrität der gesamten Kubeflow-Plattform sicherzustellen. Durch die Automatisierung dieser Tests können potenzielle Probleme frühzeitig erkannt und behoben werden, bevor sie sich auf die Produktivumgebung auswirken. Solche Tests können beispielsweise als Kubeflow-Pipeline geschrieben werden, um möglichst nutzernahe Szenarien zu testen. Optimalerweise lassen sich Tests und Dokumentation zu einem documentation-driven Testing verbinden, sodass die Dokumentation stets aktuell und von Mehrwert ist.
IT-Sicherheit: Data Science und Security mit Kubeflow
Kubeflow ermöglicht Data Scientists die dynamische und ungeprüfte Ausführung beliebigen Codes sowie die Erstellung von Ressourcen auf einer Kubernetes-Plattform. Um potenzielle Sicherheitsrisiken zu mindern und Compliance-Richtlinien zu erfüllen, ist es ratsam, den bewährten Cloud-Security-Best-Practices zu folgen. So sollten geeignete Policy-Engines wie OPA oder Kyverno eingesetzt werden, die die Erstellung von Ressourcen durch Data Scientists absichern können. Darüber hinaus bietet ein CVE-Scanning Schutz vor schadhaften Containern und kann automatisiert deren Erstellung im Cluster verhindern. Security-Monitoring-Tools wie Falco können zusätzlich beim Security-Monitoring helfen und im Falle sicherheitskritischer Zwischenfälle alarmieren. Es ist darüber hinaus ratsam, sicherheitskritische Komponenten wie Istio regelmäßig zu aktualisieren, gegebenenfalls auch vor der Veröffentlichung des nächsten Upstream-Manifest-Updates.
Bevor Data Scientists Kubeflow nutzen können, muss für sie ein Namespace erstellt werden, dem sie zugeordnet werden und in dem ihre Container ausgeführt werden. Die Automatisierung dieser Namespace-Erstellung ist äußerst empfehlenswert. Zum einen wird dadurch fehleranfälliger, manueller Aufwand vermieden, der erforderlich wäre, wenn einige Ressourcen wie Kubeflow-Profile, RoleBindings usw. manuell erstellt werden müssten. Zum anderen kann hierdurch das Standard-Berechtigungssystem abgelöst werden, in dem Data Scientists sich gegenseitig auf ihre Namespaces berechtigen dürfen. Berechtigte Benutzer werden fortan durch den Operator und Infrastructure-as-Code verwaltet. Alternativ kann der Operator mit externen Berechtigungssystemen synchronisiert werden und auch auf Gruppenbasis berechtigen. Dadurch bleiben Berechtigungen aktuell, der Cluster sicher und bestehende Berechtigungsstrukturen im Unternehmen können nahtlos genutzt werden.
Machine Learning: KI-Modelle bereitstellen
Die reibungslose und möglichst automatisierte Bereitstellung von Modellen markiert einen entscheidenden Schritt im Lebenszyklus von Machine-Learning-Anwendungen. In diesem Prozess spielt Kubeflows KServe-Modul eine wesentliche Rolle, indem es den Data Scientists ermöglicht, lediglich eine InferenceService-Ressource anzulegen, aus der das Serving und die entsprechenden Pods abgeleitet werden. Es ist hier äußerst ratsam, produktive KI-Modelle nicht manuell in User-Namespaces zu serven. Dies liegt daran, dass Data Scientists in diesen Namespaces über weitreichende Rechte verfügen. Mögliche Folgen könnten eine Unterbrechung des "Paper Trails" sein, wenn Pipeline-Läufe oder wichtige Metadaten gelöscht werden, sowie das Risiko menschlicher Fehler, die die Produktionsumgebung beeinträchtigen.
Um mit diesen potenziellen Problemen umzugehen, bieten sich zwei Ansätze an: Entweder werden eigene Namespaces ohne berechtigte Data Scientists erstellt, oder es wird ein neuer Cluster ausschließlich für das Serving eingerichtet. Letzteres bietet den Vorteil, dass Probleme in der Experimentierumgebung keine Auswirkungen auf die Produktivumgebung haben. Allerdings ist damit ein höherer Aufwand verbunden, und es könnte zu einer Verringerung der Ressourcenauslastung kommen. Die Wahl zwischen diesen Optionen hängt von den individuellen Gegebenheiten und Anforderungen des Unternehmens ab.
Unabhängig von der gewählten Lösung lässt sich das Staging von Model-Servings leicht per GitOps realisieren: Die Kubeflow-Administration gibt den Prozess frei und Data Scientists müssen lediglich die KServe InferenceService YAML-Ressource in ein vorgegebenes Git-Repository committen. Anschließend erfolgt die automatische Synchronisierung der Ressource ohne manuelle Interaktion. Dadurch ergeben sich zahlreiche GitOps-Vorteile wie Nachvollziehbarkeit, automatische Mehrweg-Synchronisierung und eine erhöhte Effizienz im Betriebsablauf.
Kubeflow: Updates und Open Source
Kubeflow wird regelmäßig, etwa zweimal im Jahr aktualisiert und mit neuen Funktionen sowie Fehlerkorrekturen versehen. Obwohl sie oft einen erheblichen Aufwand erfordern, der von der Anzahl und Komplexität der bereits vorgenommenen Änderungen abhängt, sollten sie stets eingespielt werden. Eine bewährte Praxis ist es, die Updates bereits in ihrer Pre-Release-Phase in einer Testumgebung zu evaluieren und bei Bedarf Fehler zu melden. Auf diese Weise können Probleme noch vor dem offiziellen Release behoben werden, was zeitaufwändige manuelle Korrekturen überflüssig macht.
Das Unterstützen von Open Source ist darüber hinaus sinnvoll und ein Gewinn für alle Beteiligten. Beigetragene Features helfen dabei, die Community zu stärken, die sich im Gegenzug anschließend um die Wartung kümmert. Dadurch wird der Betrieb der eigenen Plattform vereinfacht. Ein passendes Beispiel hierfür ist die Entwicklung eines PVCViewers durch unser Unternehmen, der mittlerweile ein Standardfeature Kubeflows ist. Zwar war der Weg hin zur Contribution mühsam, doch nun profitiert die Community von dem neuen Feature, während wir es nutzen können, ohne ständig für dessen Wartung aufkommen zu müssen.
Diese fortlaufenden Aufgaben und die sich ändernden Anforderungen und Weiterentwicklungen verdeutlichen, dass die Reise zur eigenen MLOps-Kubeflow-Plattform nie wirklich endet und es in diesem schnelllebigen Bereich immer wieder neue Verbesserungspotenziale gibt.
Fazit: Kubeflow als Backbone einer Künstlichen Intelligenz
Die Einführung von Kubeflow als Backbone der eigenen KI-Infrastruktur bietet für viele Unternehmen immense Vorteile, stellt sie jedoch ebenfalls vor eine Reihe von Herausforderungen, die von technischen Aspekten bis hin zu organisatorischen Anforderungen reichen. In diesem Artikel haben wir, basierend auf mehrjährigen Erfahrungen im Kubeflow-Cluster-Management, einen Einblick in die bedeutsamsten Facetten der Kubeflow-Einführung geboten.
Von der Planung und Bereitstellung bis hin zur fortlaufenden Wartung und Aktualisierung ist die Reise zur eigenen MLOps-Plattform mit Kubeflow eine iterative und agile Entwicklung, die maßgeblich durch die Anforderungen der Data Scientists geprägt ist und somit wohl nie ganz enden wird. Durch eine fundierte Kenntnis der Cloud- und Kubernetes-Technologien sowie eine klare Fokussierung auf Benutzerfreundlichkeit, Betriebsvereinfachung und Sicherheit können Unternehmen jedoch erfolgreich eine maßgeschneiderte MLOps-Plattform aufbauen.
