Kubeflow Betriebsanleitung

Kapitel 1. Einführung in Kubeflow

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Kubeflow ist eine Open-Source-Kubernetes-Plattform für die Entwicklung, Orchestrierung, Bereitstellung und den Betrieb von skalierbaren und portablen Machine-Learning-Workloads (ML). Es ist eine Cloud-native Plattform, die auf den internen ML-Pipelines von Google basiert. Das Projekt hat sich zum Ziel gesetzt, die Bereitstellung von ML-Workflows auf Kubernetes einfach, portabel und skalierbar zu machen.

In diesem Buch werfen wir einen Blick auf die Entwicklung des maschinellen Lernens in Unternehmen, wie sich die Infrastruktur verändert hat und wie Kubeflow die Anforderungen moderner Unternehmen erfüllt.

Der Betrieb von Kubeflow in einer zunehmenden Multicloud- und Hybrid-Cloud-Welt wird ein zentrales Thema sein, wenn der Markt wächst und die Akzeptanz von Kubernetes zunimmt. Ein einzelner Workflow kann einen Lebenszyklus haben, der vor Ort beginnt, aber schnell Ressourcen benötigt, die nur in der Cloud verfügbar sind. Die Entwicklung von Werkzeugen für maschinelles Lernen auf der aufstrebenden Plattform Kubernetes ist der Ausgangspunkt für Kubeflow, also lass uns dort beginnen.

Maschinelles Lernen auf Kubernetes

Kubeflow begann als einfache Möglichkeit, eine rudimentäre Machine-Learning-Infrastruktur auf Kubernetes zum Laufen zu bringen. Die beiden treibenden Kräfte bei der Entwicklung und Einführung von Kubeflow sind die Entwicklung des maschinellen Lernens in Unternehmen und das Aufkommen von Kubernetes als De-facto-Infrastrukturmanagementschicht.

Werfen wir einen kurzen Blick auf die jüngste Geschichte des maschinellen Lernens in Unternehmen, um besser zu verstehen, wie wir hierher gekommen sind.

Die Entwicklung des maschinellen Lernens in Unternehmen

In den letzten zehn Jahren sind die Popularität und das Interesse am maschinellen Lernen stark gestiegen. Dies kann auf Entwicklungen in der Computerindustrie zurückgeführt werden, wie z. B.:

• Fortschritte bei selbstfahrenden Autos
• Weitverbreitete Einführung von Computer Vision (CV) Anwendungen
• Integration von Tools wie Amazon Echo in das tägliche Leben

Deep Learning wird heutzutage für viele Tools angepriesen, aber im Grunde genommen ist angewandtes maschinelles Lernen die Grundlage für alle Entwicklungen. Maschinelles Lernen kann definiert werden als:

Wenn wir im Alltag von Lernen sprechen, meinen wir so etwas wie "Wissen durch Lernen, Erfahrung oder Unterricht erwerben". Wenn wir unseren Fokus ein wenig schärfen, können wir uns maschinelles Lernen so vorstellen, dass Algorithmen verwendet werden, um strukturelle Beschreibungen aus Datenbeispielen zu gewinnen. Ein Computer lernt etwas über die Strukturen, die die Informationen in den Rohdaten darstellen.

Deep Learning von Josh Patterson und Adam Gibson (O'Reilly)

Einige Beispiele für maschinelle Lernalgorithmen sind lineare Regression, Entscheidungsbäume und neuronale Netze. Du solltest maschinelles Lernen als eine Untergruppe des umfassenderen Bereichs der künstlichen Intelligenz (KI) betrachten.

Definition von maschinellem Lernen, Deep Learning und künstlicher Intelligenz

Deep Learning ist ein Teilbereich des maschinellen Lernens (siehe Abbildung 1-1), bei dem neuronale Netze ihre spezielle Architektur nutzen, um automatisiertes Feature-Learning durchzuführen. Typischerweise wird Deep Learning in Bereichen wie Computer Vision, Zeitreihenmodellierung und Audioklassifizierung eingesetzt. Das Training dieser fortschrittlichen neuronalen Netze lässt sich oft am besten mit GPUs durchführen.

Abbildung 1-1. Über die Beziehung zwischen künstlicher Intelligenz, maschinellem Lernen und Deep Learning nachdenken

Künstliche Intelligenz ist schwer zu definieren, da sie oft als Bezeichnung für Dinge verwendet wird, die von grundlegender Optimierung bis hin zu "etwas, das die Öffentlichkeit für Magie hält" reichen.

Beginnen wir damit, was KI nicht ist. KI ist weder lebendig noch selbstbewusst und auch nicht in der Nähe des Medienhypes, der zu überzogenen Erwartungen und Enttäuschungen über die Technologien auf dem Markt führt. Wir haben diese Zyklen, in denen KI übermäßig vermarktet wird und dann abstürzt , schon einmal erlebt (bisher zweimal). Die Fortschritte und Ergebnisse jedes Zyklus sind zwar beeindruckend und treiben neue Industriezweige voran, bleiben aber immer hinter der "Magie" zurück.

Warum tun wir uns das immer wieder an?

KI hat schon lange einen Platz in der kollektiven Vorstellung der Gesellschaft, weil sie eine existenzielle Bedrohung für unsere grundlegende Rolle in der Gesellschaft darstellt. Der Platz und die Identität der Menschen in der Gesellschaft sind eng mit ihrer Arbeitsrolle verbunden. Die Menschen fürchten, durch KI irrelevant zu werden.

Künstliche Intelligenz bedeutet eigentlich "angewandtes maschinelles Lernen" (einschließlich Deep Learning). Diese Definition lässt sich aus Sicht der Automatisierung weiter ausdehnen: "Künstliche Intelligenz ist ein Begriff für Algorithmen, die die Produktivität der Nutzer erhöhen." Wir können diese Definition vornehmen, weil einige Techniken, wie z. B. die Game-State-Suche, nicht als maschinelles Lernen definiert sind, aber dennoch unter den historischen Begriff der KI fallen. Mehr darüber, was KI ist, findest du in Anhang A von Deep Learning (O'Reilly).

Mitte der 2000er Jahre erlebte die Deep-Learning-Forschung einen Aufschwung, der durch die Verfügbarkeit von Grafikprozessoren, besser beschrifteten Datensätzen und besseren Werkzeugen angeheizt wurde. Anfang der 2010er Jahre wurde das Interesse an angewandtem maschinellem Lernen in allen Unternehmen neu entfacht, die Daten und maschinelle Intelligenz nutzen wollten, um "mehr wie Google und Amazon" zu sein.

Viele frühe Bemühungen im Bereich des angewandten maschinellen Lernens konzentrierten sich auf die Apache Hadoop-Plattform, da diese in der ersten Hälfte der 2010er Jahre einen kometenhaften Aufstieg in Unternehmen erlebte. Während Apache Hadoop jedoch auf die Nutzung von Standardhardware mit CPUs und verteilter Verarbeitung ausgerichtet war, konzentrierten sich Deep Learning-Experten auf Einzelrechner mit einem oder mehreren Grafikprozessoren und der Programmierumgebung Python. Apache Spark auf Apache Hadoop bot robuste Optionen für angewandtes maschinelles Lernen auf der JVM, doch die Absolventen waren eher in der Programmiersprache Python ausgebildet.

Die Unternehmen begannen, mehr Fachleute für maschinelles Lernen mit Hochschulabschluss einzustellen, was zu einem großen Zustrom von Nutzern führte, die für ihre angewandten maschinellen Lernprozesse Unterstützung für Python benötigten.

In früheren Jahren war Spark eine Schlüsseltechnologie für die Ausführung von Aufträgen zum maschinellen Lernen, aber in den letzten Jahren sehen wir, dass sich Unternehmen auf GPU-basiertes Training in Containern verlagern, die nicht unbedingt auf einem Hadoop-Cluster laufen. Die DevOps-, IT- und Plattformteams, die mit diesen Datenwissenschaftlern zusammenarbeiten, wollten sicherstellen, dass sie die Teams für den Erfolg vorbereiten und gleichzeitig eine überschaubare Infrastrukturstrategie haben.

Die Verantwortlichen für diese Plattformen wollten die Cloud auf eine Weise nutzen, die nicht zu viel kostet und die Vorteile der Vergänglichkeit von Cloud-basierten Arbeitslasten nutzt.

Es besteht ein wachsender Bedarf, diese Welten in Data Lakes zusammenzubringen - sei es vor Ort, in der Cloud oder irgendwo dazwischen. Einige der größten Herausforderungen im Bereich des maschinellen Lernens in Unternehmen sind heute:

• Datenwissenschaftler bevorzugen in der Regel ihre eigenen Bibliotheken und Tools.
• Diese Art von Tools sind in der Regel heterogen, sowohl innerhalb von Teams als auch organisationsübergreifend.
• Data Scientists müssen mit dem Rest des Unternehmens in Bezug auf Ressourcen, Daten und Modellbereitstellung zusammenarbeiten.
• Viele ihrer Tools sind Python-basiert, wobei sich Python-Umgebungen in einem großen Unternehmen nur schwer verwalten lassen.
• Oft wollen Datenwissenschaftler Container bauen und sie dann einfach "umherbewegen", um von leistungsfähigeren Ressourcen jenseits ihres Laptops zu profitieren, entweder im Rechenzentrum vor Ort oder in der Cloud.

Das macht es schwieriger als je zuvor, eine Plattform zu betreiben, die die verschiedenen Komponenten unterstützt, die das System nutzen.

Was ist ein Data Lake?

Wir verwenden die Definition, die auf der Website von Amazon Web Services (AWS) zu finden ist:

Ein Data Lake ist ein zentraler Speicher, in dem du alle deine strukturierten und unstrukturierten Daten in beliebigem Umfang speichern kannst. Du kannst deine Daten so speichern, wie sie sind, ohne sie erst strukturieren zu müssen, und verschiedene Arten von Analysen durchführen - von Dashboards und Visualisierungen bis hin zu Big Data Processing, Echtzeitanalysen und maschinellem Lernen, um bessere Entscheidungen zu treffen.

Es ist schwieriger denn je, eine Unternehmensinfrastruktur zu betreiben

Wir leben zunehmend in einem Zeitalter, in dem Entwickler und Datenwissenschaftler das Gefühl haben, ihre eigene Infrastruktur in der Cloud aufbauen zu können. Daher ist es für viele Unternehmen widersinnig geworden, strenge Infrastrukturregeln für Machine-Learning-Experten aufzustellen. Wir haben gesehen, dass Kunden am Ende drei oder vier verschiedene Pipelinesysteme für maschinelles Lernen haben, weil sich die Gruppen nicht einigen können (und einfach zu AWS oder GCP rennen, um zu bekommen, was sie wollen, wenn sie ein "Nein" hören).

Hadoop und Spark sind nach wie vor die wichtigsten Werkzeuge für die Speicherung und Verarbeitung von Daten, aber Kubernetes kommt immer mehr ins Spiel, um On-Premise-, Cloud- und Hybrid-Workloads zu verwalten. In den letzten zwei Jahren hat die Verbreitung von Kubernetes rasant zugenommen. Viele Unternehmen haben in früheren Technologiezyklen Investitionen in die Infrastruktur getätigt, wie z. B:

• RDBMs
• Parallele RDBMs
• Hadoop
• Schlüssel-Wert-Läden
• Funke

Genau wie die Systeme vor ihnen haben auch diese Systeme ein gewisses Maß an Trägheit in den Organisationen, die sie übernehmen. Daher ist es leicht vorherzusagen, dass die Integration zwischen Hadoop-Workloads und spezialisierten Kubernetes-basierten Machine-Learning-Workloads bevorsteht - wie wir sehen, dass Cloudera Kubernetes für seine neuen Data-Science-Tools anstelle von YARN verwendet und Google YARN für Spark gegen Kubernetes austauscht.

Weitere Faktoren, die den Betrieb der Infrastruktur komplexer denn je machen, sind die Entwicklung der Open-Source-Akzeptanz in Unternehmen, die sowohl On-Premise- als auch Cloud-Infrastrukturen nutzen. Hinzu kommen die Sicherheitsanforderungen, die notwendig sind, um die Komplexität der verschiedenen Plattformen und der Mandantenfähigkeit zu unterstützen. Schließlich gibt es auch einen Bedarf an spezialisierter Hardware wie GPUs und TPUs.

Einige allgemeine Trends im Bereich der Infrastruktur sind für uns von Interesse, wenn wir weitergehen:

• Mischungen aus On-Premise-, Cloud- und Hybrid-Implementierungen werden bei Unternehmen immer beliebter.
• Die drei großen "Big Cloud"-Anbieter erfassen weiterhin eine Reihe von Arbeitslasten, die in die Cloud verlagert werden; einige dieser Arbeitslasten pendeln zwischen Cloud und On-Premise.
• Docker ist ein Synonym für den Begriff Container.
• Viele Unternehmen nutzen Kubernetes oder ziehen es als Plattform für die Container-Orchestrierung in Betracht.

Über einen On-Premise-Cluster hinaus können Kubernetes-Cluster mit einer Cluster-Föderation innerhalb von Kubernetes verbunden werden. In einer wirklich hybriden Welt können wir eine Auftragsplanungsrichtlinie haben, die bestimmte Aufträge in die Cloud verlagert, weil die On-Premise-Ressourcen überbelegt sind, oder umgekehrt bestimmte Aufträge nur On-Premise ausführen und nie in der Cloud ausführen. Kubernetes macht Workloads auch plattformunabhängiger, weil es die zugrunde liegenden Plattformspezifika abstrahiert und Kubernetes zur zentralen Abstraktion macht.

Es gibt viele Faktoren, die bei einer Cloud-Infrastruktur oder einer hybriden Cluster-Infrastruktur zu berücksichtigen sind, z. B:

• Integration von Active Directory (AD)
• Sicherheitsüberlegungen
• Kostenüberlegungen für Cloud-Instanzen
• Welche Nutzer sollen Zugang zu den Cloud-Instanzen haben?

All diese Themen werden in Kapitel 2 und im Rest des Buches näher betrachtet.

Identifizierung der Kernprinzipien der Infrastruktur der nächsten Generation (NGI)

Im Zeitalter der Cloud-Infrastruktur hat das, was die "Big Cloud" (AWS, Azure, Google Cloud Platform [GCP]) tut, einen großen Einfluss darauf, wie Unternehmen heute ihre eigene Infrastruktur aufbauen. Im Jahr 2018 haben wir gesehen, dass alle drei großen Cloud-Anbieter verwaltete Kubernetes als Teil ihrer Infrastruktur anbieten :

• Google Kubernetes Engine (GKE)
• Amazon Elastic Kubernetes Service (EKS)
• Azure Kubernetes Dienste (AKS)

Nachdem Amazon zunächst einen eigenen Containerdienst angeboten hatte, schloss sich das Unternehmen Ende 2017 den anderen beiden Big Cloud-Mitgliedern an und bot Amazon EKS als unterstützten Bürger erster Klasse auf AWS an.

Alle drei großen Cloud-Anbieter treiben Kubernetes voran, und dieser Rückenwind dürfte das Interesse an Kubernetes und Kubeflow noch steigern. Darüber hinaus haben wir gesehen, dass Container für Datenwissenschaftlerinnen und -wissenschaftler eine Schlüsselrolle spielen, wenn es darum geht, Container von der lokalen Ausführung über die Infrastruktur vor Ort bis hin zur (einfachen und sauberen) Ausführung in der Cloud zu verwalten.

Teams müssen ein Gleichgewicht zwischen Mandantenfähigkeit und dem Zugang zu Speicher- und Rechenoptionen (NAS, HDFS, FlashBlade) und High-End-GPUs (Nvidia DGX-1, etc.) finden. Die Teams brauchen außerdem eine flexible Möglichkeit, ihre Anwendungen für angewandtes maschinelles Lernen vollständig anzupassen, von ETL über Modellierung bis hin zur Modellbereitstellung, und zwar so, dass die oben genannten Anforderungen erfüllt werden.

Wir sehen, dass Cloud-Anbieter einen zunehmenden Einfluss darauf haben, wie Unternehmen ihre Infrastruktur aufbauen, wobei die von ihnen befürworteten Managed Services wahrscheinlich eine schnellere Akzeptanz finden. Die meisten Unternehmen werden jedoch durch die im letzten Abschnitt aufgelisteten Hindernisse davon abgehalten, Ergebnisse aus den Data Science-Bemühungen in ihrem Unternehmen zu erzielen. Wir können diese Hindernisse in die folgenden Schlüsselkomponenten unterteilen :

Zusammensetzbarkeit

Bei dieser Komponente geht es darum, Workflows für maschinelles Lernen in eine Reihe von Komponenten (oder Phasen) aufzuteilen und sie in verschiedenen Formationen zusammenzustellen. Oft sind diese Phasen jeweils eigene Systeme und wir müssen den Output eines Systems als Input in ein anderes System übertragen.

Tragbarkeit

Bei dieser Komponente geht es darum, eine einheitliche Methode zum Ausführen und Testen von Code zu haben:

• Entwicklung
• Inszenierung
• Produktion

Wenn wir Deltas zwischen diesen Umgebungen haben, kann es zu Ausfällen in der Produktion kommen. Ein Stack für maschinelles Lernen, der auf deinem Laptop genauso läuft wie auf einem DGX-1 mit mehreren GPUs und dann in einer öffentlichen Cloud, würde von den meisten Praktikern heute als wünschenswert angesehen werden.

Skalierbarkeit

Die meisten Unternehmen wünschen sich außerdem Skalierbarkeit und sind dadurch eingeschränkt:

• Zugang zu maschinenspezifischer Hardware (z. B. GPUs, TPUs)
• Begrenzte Rechenleistung
• Netzwerk
• Speicherung
• Heterogene Hardware

Leider geht es bei der Skalierung nicht darum, "mehr Hardware hinzuzufügen", sondern in vielen Fällen um die zugrunde liegende Architektur der verteilten Systeme. Kubernetes hilft uns bei diesen Beschränkungen.

GPUs, TPUs und FPGAs

Wir möchten an dieser Stelle kurz auf die Hardware eingehen, mit der einige Leser vielleicht nicht vertraut sind. Anfangs experimentieren die Nutzer/innen auf ihren lokalen Rechnern mit ML-Workflows, aber mit der Zeit werden ihre Workflows immer rechenintensiver und brauchen länger, um abgeschlossen zu werden.

Das führt dazu, dass die Nutzerinnen und Nutzer nach leistungsfähigerer Hardware für maschinelles Lernen suchen, und der Hardwaremarkt hat darauf mit spezialisierten Komponenten wie GPUs, TPUs und FPGAs reagiert.

Ein Grafikprozessor (GPU) wurde entwickelt, um die Art von Mathematik (lineare Algebra) zu verarbeiten, die wir normalerweise in den 3D-Rendering-Pipelines von Videospielen sehen (woher sie stammen). Als maschinelles Lernen immer beliebter wurde, entdeckten die Nutzer, dass GPUs von Natur aus gut in linearer Algebra sind und dass ML-Algorithmen auf denselben GPUs wie Videospiele beschleunigt werden können (mit einigen Softwaretricks). Heute wird die Beschleunigung der Verarbeitung linearer Algebra beim maschinellen Lernen meist mit GPUs in Verbindung gebracht.

Tensor Processing Units (TPUs) sind anwendungsspezifische integrierte Schaltkreise (ASICs), die von Google speziell entwickelt wurden, um das Training von neuronalen Netzwerken für maschinelles Lernen und Inferenzen zu beschleunigen.

Ein Field-Programmable Gate Array (FPGA) schließlich ist ein integrierter Schaltkreis, der vom Kunden mit einer Hardwarebeschreibungssprache (HDL) konfiguriert werden kann. FPGAs werden heute nicht so häufig zur Beschleunigung von ML-Workloads eingesetzt wie GPUs und TPUs.

Kubernetes für die Bereitstellung von Produktionsanwendungen

Kubernetes ist ein Orchestrierungssystem für Container, das dazu dient, Cluster von Knoten in der Produktion auf effiziente Weise zu koordinieren. Kubernetes basiert auf dem Konzept der Pods, die Planungseinheiten (jeder Pod enthält einen oder mehrere Container) im Kubernetes-Ökosystem sind. Diese Pods sind auf die Hosts eines Clusters verteilt, um eine hohe Verfügbarkeit zu gewährleisten. Kubernetes selbst ist keine vollständige Lösung und soll mit anderen Tools wie Docker, einer beliebten Containertechnologie, integriert werden .

Ein Container-Image ist ein leichtgewichtiges, eigenständiges, ausführbares Paket einer Software, das alles enthält, was zur Ausführung benötigt wird (Code, Laufzeit, Systemtools, Systembibliotheken, Einstellungen). Umgangssprachlich werden Container als "Docker" bezeichnet, aber gemeint sind in der Regel Container im allgemeinen Sinn. Docker-Container machen es für Entwickler/innen wesentlich einfacher, ihre lokalen, Test-, Staging- und Produktionsumgebungen gleichwertig zu nutzen. Mit Containern können Teams das gleiche Artefakt oder Image in all diesen Umgebungen ausführen, auch auf dem Laptop eines Entwicklers oder in der Cloud. Diese Eigenschaft von Containern, insbesondere in Kombination mit der Container-Orchestrierung mit einem System wie Kubernetes, treibt das Konzept der Hybrid Cloud in der Praxis voran.

Ein wichtiger Grund für die weite Verbreitung von Containern (z.B. Docker) und Kubernetes ist, dass sie zusammen eine außergewöhnliche Infrastrukturlösung für die Probleme der Kompatibilität, Portabilität und Skalierbarkeit darstellen. Kubernetes glänzt, wenn wir viele Container haben, die auf vielen Rechnern verwaltet werden müssen (vor Ort, in der Cloud oder einer Mischung aus beidem).

Was sind Container?

Ein Container-Image ist ein leichtgewichtiges, eigenständiges, ausführbares Softwarepaket, das den Code, die Laufzeit, die Systemtools und -bibliotheken sowie die Einstellungen enthält, die zur Ausführung benötigt werden. Container und Container-Plattformen bieten mehr Vorteile als die traditionelle Virtualisierung, denn:

• Die Isolierung erfolgt auf der Kernel-Ebene, ohne dass ein Gastbetriebssystem erforderlich ist.
• Container sind viel effizienter, schneller und leichter.

Dadurch können Anwendungen in in sich geschlossenen Umgebungen gekapselt werden. Weitere Vorteile sind die schnellere Bereitstellung, die Skalierbarkeit und die stärkere Angleichung der Entwicklungsumgebungen.

Docker und Kubernetes sind keine direkten Konkurrenten, sondern ergänzende Technologien. Man kann es sich so vorstellen, dass Docker für die Verwaltung von Images und einzelnen Containern zuständig ist, während Kubernetes für die Verwaltung von Pods von Containern zuständig ist. Mit Docker wurde ein offener Standard für die Verpackung und Verteilung von containerisierten Anwendungen geschaffen, aber das Problem der Container-Orchestrierung (Kommunikation untereinander, Skalierung usw.) wurde damit nicht gelöst. Konkurrenten von Kubernetes in diesem Bereich sind Mesos und Docker Swarm, aber wir beobachten, dass sich die Branche auf Kubernetes als Standard für die Container-Orchestrierung zubewegt.

Mit Kubernetes können wir auch Anwendungen in einem Cluster dynamisch skalieren. Mit installierbaren Optionen wie dem Kubernetes Horizontal Pod Autoscaler können wir auch die Cluster selbst skalieren.

Nicht jede Anwendung kann dynamisch skaliert werden

Einige Arten von Anwendungen sind keine Kandidaten für eine dynamische Skalierung. Dafür gibt es mehrere mögliche Gründe, z. B. eine Anwendung, die von der Datenlokalität abhängig ist und deren Daten für einen effektiven Betrieb auf den Laufwerken der lokalen Instanz liegen müssen. Andere Beispiele sind (Legacy-)Anwendungen, die von vornherein monolithisch aufgebaut sind und die aufgrund ihrer Architektur nicht nach außen, sondern nach oben skaliert werden müssen.

Kubernetes ermöglicht die horizontale Skalierung von Anwendungen im Bereich der Nodes und Container (Pods) und bietet gleichzeitig Fehlertoleranz und eine selbstheilende Infrastruktur, die die Zuverlässigkeit verbessert. Kubernetes ermöglicht außerdem die effiziente Nutzung von Ressourcen für Anwendungen, die vor Ort oder in der Cloud eingesetzt werden. Kubernetes ist außerdem bestrebt, jede eingesetzte Anwendung rund um die Uhr verfügbar zu machen, und ermöglicht es Entwicklern, Anwendungen oder Updates mehrmals am Tag ohne Ausfallzeiten bereitzustellen.

Kubernetes eignet sich außerdem hervorragend für Machine Learning Workloads, da es bereits GPUs und TPUs als Ressourcen unterstützt und FPGAs in der Entwicklung sind. In Abbildung 1-2 sehen wir, wie wichtig die Abstraktion von Containern und anderen Schichten ist, um einen Trainingsauftrag für maschinelles Lernen auf GPUs auszuführen, ähnlich wie man denselben Auftrag auf FPGAs ausführen könnte.

Abbildung 1-2. Container und Abstraktion von der Hardware

Wir heben die Abstraktionen in Abbildung 1-2 hervor, weil sie alle Komponenten der Herausforderungen sind, die mit der Portabilität von Workflows verbunden sind. Ein Beispiel dafür ist, dass unser Code zwar lokal auf unserem eigenen Laptop funktioniert, aber auf einer virtuellen Maschine mit GPUs in der Google Cloud fehlschlägt.

Warum stecken wir nicht einfach alle benötigten Fahrer/innen in unsere Container?

Hardwaretreiber sind für die Steuerung der zugrunde liegenden Hardware gedacht, die sie unterstützen sollen. Genauso wie ein spezieller Ethernet-Treiber oder ein spezieller Festplattentreiber eine Netzwerkkarte bzw. eine Festplatte steuert, kontrollieren (und steuern) die GPU-Treiber die GPUs in einem Rechner. Treiber arbeiten normalerweise auf oder nahe der Kernel-Ebene.

Wenn man bedenkt, dass es sich bei Containern um einen Prozess mit Namensräumen handelt (d.h. ein Prozess, der von vielen oder allen anderen Prozessen in einem System isoliert wurde), würde die Installation des Treibers im Container voraussetzen, dass dieser Prozess Elemente in den laufenden Kernel einspeisen und aus ihm entfernen darf, wodurch der Container die exklusive Kontrolle über die Hardware erhält. Der Container müsste mit erhöhten Rechten laufen, wodurch ein Teil der Sicherheitssemantik von Containern aufgehoben würde.

Mit anderen Worten: Wenn ein Container die alleinige Kontrolle über die zugrundeliegende Hardware erhält, wird die Idee des "containerisierten Prozesses" zunichte gemacht. Es bindet ihn an eine ganz bestimmte Hardware und macht ihn damit weniger portabel (was passiert, wenn der Container versucht, den Treiber zu laden, aber die Hardware auf einem anderen Rechner, auf dem der Container läuft, anders ist). Außerdem muss der Container über erhöhte Systemrechte verfügen.

In einer containerisierten Umgebung ist der zugrundeliegende Host in der Regel am besten geeignet, seine eigene Hardware zu kontrollieren und die Verfügbarkeit dieser Hardware für Container offenzulegen.

Kubernetes verfügt außerdem über Controller für Aufgaben wie Batch-Aufträge und die Bereitstellung von langlebigen Diensten für das Modell-Hosting, wodurch wir viele grundlegende Komponenten für unsere Infrastruktur für maschinelles Lernen erhalten. Außerdem bietet Kubernetes als Ressourcenmanager drei Hauptvorteile :

• Vereinheitlichtes Management
• Isolierung von Aufträgen
• Widerstandsfähige Infrastruktur

Die einheitliche Verwaltung ermöglicht es uns, eine einzige Verwaltungsoberfläche für mehrere Kubernetes-Cluster zu verwenden. Die Isolierung von Aufträgen in Kubernetes gibt uns die Möglichkeit, Modelle und ETL-Pipelines (Extrahieren, Transformieren und Laden) von der Entwicklung in die Produktion zu verschieben, ohne dass es zu Problemen mit Abhängigkeiten kommt. Resiliente Infrastruktur bedeutet, dass Kubernetes die Knoten im Cluster für uns verwaltet und dafür sorgt, dass wir genügend Maschinen und Ressourcen haben, um unsere Aufgaben zu erfüllen.

Kubernetes als Plattform ist in der Praxis bis zu Tausenden von Knoten skaliert worden. Auch wenn viele Unternehmen diese Größenordnung nicht erreichen werden, unterstreicht dies die Tatsache, dass Kubernetes (die Plattform selbst) aus Sicht eines verteilten Systems als Plattform keine Skalierungsprobleme haben wird.

Kubernetes ist keine Magie

Jede verteilte Systemanwendung erfordert ein durchdachtes Design. Fallen Sie nicht auf die Vorstellung herein, dass Kubernetes jede Anwendung auf magische Weise skalieren wird, nur weil jemand die Anwendung in einen Container geworfen und in einen Cluster geschickt hat.

Obwohl wir die Probleme mit dem Verschieben von Containern und Machine Learning Workflow Stacks lösen können, sind wir noch nicht ganz aus dem Schneider. Wir müssen immer noch andere Überlegungen anstellen, wie zum Beispiel:

• Die Kosten für die Nutzung der Cloud im Vergleich zu den Kosten vor Ort
• Organisatorische Regeln für den Speicherort von Daten
• Sicherheitsaspekte wie die Integration von Active Directory und Kerberos

Das sind nur ein paar Beispiele. Bei der modernen Rechenzentrumsinfrastruktur sind viele Variablen im Spiel, die einem IT- oder DevOps-Team das Leben schwer machen können. In diesem Buch versuchen wir, dir zumindest einen Angriffsplan an die Hand zu geben, wie du am besten planst und die Bedürfnisse deiner Data-Science-Beteiligten erfüllst, ohne dabei die Unternehmensrichtlinien zu verletzen.

Kubernetes löst viele Infrastrukturprobleme in einer immer komplexeren Infrastrukturwelt, aber es wurde nicht speziell für maschinelle Lernprozesse entwickelt.

Für einen tieferen Einblick in Kubernetes

Sieh dir Anhang B dieses Buches oder eines der anderen O'Reilly-Bücher über Kubernetes an, z. B. Kubernetes: Up and Running, von Brendan Burns et al.

Werfen wir nun einen Blick darauf, wie Kubeflow dazu beiträgt, Workflows für maschinelles Lernen zu ermöglichen.

Eintreten: Kubeflow

Kubeflow wurde entwickelt, um Workflows für maschinelles Lernen in Kubernetes auszuführen und wird in der Regel aus folgenden Gründen eingesetzt:

• Du willst Machine-Learning-Modelle in verschiedenen Umgebungen trainieren/verwenden (z. B. lokal, vor Ort und in der Cloud).
• Du möchtest Jupyter Notebooks verwenden, um Trainingsaufträge für maschinelles Lernen zu verwalten (nicht nur TensorFlow-Aufträge).
• Du möchtest Trainingsaufträge starten, die Ressourcen benötigen (z. B. zusätzliche CPUs oder GPUs, die auf deinem Computer nicht verfügbar sind).
• Du möchtest Code für maschinelles Lernen aus verschiedenen Bibliotheken kombinieren.

Manchmal, wie im letzten Beispiel beschrieben, wollen wir unseren TensorFlow-Code mit anderen Prozessen kombinieren. In diesem Beispiel könnten wir TensorFlow/Agenten verwenden, um Simulationen durchzuführen und Daten für das Training von Reinforcement-Learning-Modellen (RL) zu erzeugen. Mit Kubeflow Pipelines können wir diese beiden unterschiedlichen Teile eines Machine-Learning-Workflows miteinander verknüpfen.

Für unsere Plattform für maschinelles Lernen wünschen wir uns in der Regel ein Betriebsmuster, das dem Muster "Labor und Fabrik" ähnelt. Auf diese Weise sollen unsere Datenwissenschaftler/innen in der Lage sein, neue Datenideen im "Labor" zu erforschen, und sobald sie ein Setup gefunden haben, das ihnen gefällt, können sie es in die "Fabrik" verlagern, damit der Modellierungsworkflow konsistent und reproduzierbar abläuft. In Abbildung 1-3 sehen wir eine verallgemeinerte Darstellung eines gängigen Workflows für maschinelles Lernen.

Abbildung 1-3. Der verallgemeinerte Arbeitsablauf des maschinellen Lernens

Kubeflow wurde entwickelt, um Machine-Learning-Workflows wie den in Abbildung 1-3 dargestellten über die vielen verschiedenen Einschränkungen hinweg zu betreiben, die wir in diesem Kapitel bisher genannt haben. Zwei Schlüsselsysteme (die in Kapitel 2 im Detail beschrieben werden), die den Wert von Kubeflow über Kubernetes hinaus verdeutlichen, sind das Notebook-System in Kubeflow und die Kubeflow Pipelines. Wir werden im Laufe des Buches mehrmals auf dieses Diagramm zurückgreifen, um zu verdeutlichen, wie die Teile von Kubeflow als Ganzes zusammenwirken, um die Ziele der DevOps- und Data Science-Teams zu erreichen.

Kubeflow ist eine großartige Option für die Infrastruktur der Fortune 500, denn es ermöglicht die einfache Integration eines Notebook-basierten Modellierungssystems mit den ETL-Operationen eines lokalen Data Lakes oder in der Cloud. Außerdem unterstützt es die Mandantenfähigkeit über verschiedene Hardware hinweg, indem es den Aspekt der Container-Orchestrierung in der Infrastruktur verwaltet. Kubeflow bietet uns großartige Möglichkeiten für eine mandantenfähige "Labor"-Umgebung und stellt gleichzeitig eine Infrastruktur zur Verfügung, mit der wir konsistente Produktionsworkflows für maschinelles Lernen in der "Fabrik" planen und aufrechterhalten können.

Zwar können sich Teams heute potenziell einen Server teilen, aber wenn wir versuchen, 5 oder 10 Server mit jeweils mehreren GPUs zu verwalten, entsteht schnell eine Situation, in der Multitenancy unübersichtlich werden kann. Die Nutzer/innen müssen auf Ressourcen warten und kämpfen möglicherweise auch mit Abhängigkeiten oder Bibliotheken, die andere Nutzer/innen bei früheren Aufträgen hinterlassen haben. Außerdem ist es schwierig, die Nutzer voneinander zu isolieren, damit sie die Daten der anderen nicht sehen können.

Versteckte technische Schulden in maschinellen Lernsystemen

Die meisten Anwendungen, die für Schlagzeilen sorgen, sind wunderbare (visuelle) Anwendungen von Deep-Learning-Modellen. Bei den meisten Pipelines für maschinelles Lernen gehört jedoch viel mehr zur Erstellung eines Modells als nur eine Trainingsschleife und eine hübsche Darstellung in einem Jupyter Notebook. Abbildung 1-4 aus dem Artikel "Hidden Technical Debt in Machine Learning" von D. Sculley et al. gibt einen besseren Überblick darüber, was alles zum Aufbau einer Machine-Learning-Pipeline gehört.

Abbildung 1-4. Nur ein kleiner Teil eines realen ML-Systems besteht aus dem ML-Code, wie die kleine schwarze Box in der Mitte zeigt; die erforderliche umgebende Infrastruktur ist riesig und komplex

Dieses Diagramm ist eine großartige visuelle Metapher dafür, warum Plattformen wie Kubeflow heute für Unternehmenspraktiker wichtig (und beliebt) sind.

Wenn wir die Hoffnung haben, eine robuste Data Science-Praxis in einem Cluster mit heterogener Hardware aufrechtzuerhalten, müssen wir ein System wie Kubeflow und Kubernetes verwenden. Abgesehen von den Hindernissen, die wir hier erwähnen, neigen Workflows für maschinelles Lernen dazu, direkt unter der sichtbaren Oberfläche viele technische Schulden zu haben.

Welche Probleme werden mit Kubeflow gelöst?

Das Ziel von Kubeflow ist es, den Einsatz von Machine Learning Workflows in Kubernetes zu vereinfachen. Das Problem bei der direkten Nutzung der Kubernetes-API ist, dass sie für die meisten Datenwissenschaftler zu einfach ist. Ein Datenwissenschaftler muss bereits eine Reihe von Techniken und Technologien kennen, ohne dass er die Komplexität der Kubernetes-API zu seiner Liste hinzufügen muss.

Viele Menschen beginnen damit, ihre ersten Modelle in die Produktion zu überführen, indem sie Python-Modelle für maschinelles Lernen in Container verpacken. Von diesem Punkt aus ist die Bereitstellung des Containers in einem Pod auf Kubernetes ein natürlicher nächster Schritt (wie wir an den Markttrends sehen können). Je mehr Anwendungen für maschinelles Lernen auf Kubernetes bereitgestellt werden, desto stärker zieht dieser Gravitationseffekt auch die maschinelle Lernarbeit an. Aus der Sicht von DevOps bedeutet das jedoch, dass du bald eine komplette mandantenfähige Data-Science-Plattform auf Kubernetes implementierst.

Es gibt viele zusätzliche Details, um die man sich kümmern muss, wie z.B. den "Glue"-Code, der dafür sorgt, dass Notebook-Server und Pipelines konsistent und sicher als verteiltes System funktionieren. Oftmals besteht die Arbeit in der Datenwissenschaft aus Skripten und nicht aus vollwertigen Anwendungen, was den Einsatz als Produktionsworkflow von Grund auf erschwert. Neben der Kubernetes-API musst du auch eigenen Code schreiben, um die verschiedenen laufenden Komponenten zu integrieren und die Komponenten für Dinge wie die Workflow-Orchestrierung zu orchestrieren.

Es ist nicht immer einfach, Kubernetes-Knoten hinzuzufügen und zu erwarten, dass sie als zusammenhängende Plattform funktionieren. Häufig stellen Unternehmen Automatisierungsskripte zusammen, mit denen sie schnell einen Benutzer in einer Cloud-Umgebung einrichten, einen oder mehrere Aufträge ausführen und dann die Umgebung wieder abbauen. Dies ist jedoch sehr mühsam, da es nicht immer einfach ist, die Integration von Active Directory (Benutzerverwaltung) oder Kerberos zu gewährleisten.

Du willst, dass sich ein Datenwissenschaftler auf die Entwicklung, das Training, das Testen und den Einsatz von Modellen konzentriert und weniger darauf, wie er die Kubernetes-API so zum Laufen bringt, dass seine Hauptarbeit möglich wird. Die Probleme, die Kubeflow über die Kubernetes-Kern-API hinaus löst, sind:

• Schnellere und einheitlichere Bereitstellung
• Bessere Kontrolle über Ports und Komponentenzugriff für mehr Sicherheit
• Schutz vor übermäßiger Ressourcenbereitstellung, Kosteneinsparungen
• Schutz davor, dass Aufgaben nach ihrer Erledigung nicht wieder freigegeben werden, was Kosten spart
• Workflow-Orchestrierung und Sammlung von Metadaten
• Zentralisierte Überwachung und Protokollierung
• Infrastruktur, um Modelle sicher und in großem Maßstab in die Produktion zu bringen

Der Name Kubeflow ist ein Portmanteau aus Kubernetes und TensorFlow. Alle drei Projekte wurden von Teams bei Google als Open-Source-Projekte ins Leben gerufen. Obwohl Kubeflow als eine Möglichkeit begann, TensorFlow-Workflows und -Modelle in die Produktion zu überführen, hat es sich über den ursprünglichen Zustand hinaus entwickelt.

Kubeflow bindet dich nicht an TensorFlow

Deine Nutzerinnen und Nutzer können das Framework für maschinelles Lernen für ihre Notizbücher oder Arbeitsabläufe nach Belieben auswählen.

Heute kann Kubeflow Workflows für Container orchestrieren, auf denen viele verschiedene Arten von Machine-Learning-Frameworks (XGBoost, PyTorch usw.) laufen. In manchen Fällen möchte ein Team Kubeflow nutzen, um Notebook-Server für eine mandantenfähige Umgebung zu verwalten, die sich nicht einmal auf maschinelles Lernen konzentriert.

Ein Auftrag in Kubeflow kann ein Jupyter-Notebook oder ein Python-Skript in einer Reihe von Pipeline-verbundenen Aufträgen sein. Ein Auftrag in Kubeflow kann auch so einfach sein wie die Ausführung eines Python-Skripts in einem Container auf einem Pod in Kubernetes über kubectl. Wir verwenden Notebooks, die CLI oder Pipelines, um Machine-Learning-Workflows einzurichten, die einen Auftrag oder eine Reihe von Aufträgen ausführen, um Machine-Learning-Modelle zu erstellen.

Für jeden dieser Workflows nutzen wir Kubeflow als Infrastruktur, die über die Kubernetes-API hinausgeht, um heterogene Machine-Learning-Workflows sicher über heterogene Hardware zu orchestrieren, die von Kubernetes verwaltet und geplant wird. Kubeflow ist die Schicht zwischen dem Nutzer und der Kubernetes-API, die es ermöglicht, diese konsequent als skalierbare, mandantenfähige Machine-Learning-Plattform zu betreiben.

In Kapitel 2 werden wir uns die Architektur von Kubeflow und seine Subsysteme genauer ansehen. Wir werden sehen, wie die Architektur bestimmte Probleme in diesem Bereich löst und wie die Komponenten zusammenpassen, um die Plattformlösung für maschinelles Lernen zu bilden, die Kubeflow ist.

Ursprung von Kubeflow

Auf der Google Next im Jahr 2016 kündigte Google Cloud Machine Learning (Cloud ML) auf der Google Cloud Platform (GCP) an. Cloud ML nutzt GKE, einen Vorläufer dessen, was wir heute als Kubeflow kennen. Im Dezember 2017 wurde auf der KubeCon die erste Version von Kubeflow angekündigt und von David Aronchick und Jeremy Lewi vorgestellt. Diese Version enthielt:

• JupyterHub
• TFJob v1alpha1
• TFServing
• GPUs arbeiten mit Kubernetes

Im Januar 2018 wurde der Kubeflow Governance Proposal veröffentlicht, um die Arbeit der Community rund um das Projekt zu steuern. Im Juni 2018 wurde die Version 0.1 von Kubeflow eingeführt, die einen erweiterten Satz von Komponenten enthält, darunter:

• JupyterHub
• TFJob mit verteilter Ausbildungsunterstützung
• TFServing
• Argo
• Seldon Kern
• Botschafter
• Bessere Kubernetes-Unterstützung

Nur zwei Monate später, im August 2018, wurde die Version 0.2 von Kubeflow angekündigt, die u.a. folgende Neuerungen enthält:

• TFJob v1alpha2
• PyTorch und Caffe Operatoren
• Zentrale UI

Das Projekt wächst immer noch (zum Zeitpunkt der Erstellung dieses Buches) und Kubeflow entwickelt sich ständig weiter. Heute arbeiten über 100 Ingenieurinnen und Ingenieure an dem Projekt (im Vergleich zu den 3 am Anfang) und 22 Mitgliedsorganisationen sind daran beteiligt.

Wer nutzt Kubeflow?

Einige der Schlüsselpersonen in Unternehmen, die das größte Interesse an Kubeflow haben, sind:

• DevOps-Ingenieure
• Plattform Architekten
• Datenwissenschaftler/innen
• Daten-Ingenieure

DevOps- und Plattformarchitekten müssen jeden mit der richtigen Infrastruktur an den richtigen Stellen unterstützen, sei es in der Cloud oder vor Ort, um die Ingest-, ETL-, Data Warehouse- und Modellierungsarbeiten anderer Teams zu unterstützen. Dateningenieure nutzen diese Infrastruktur, um Datenwissenschaftlern die besten denormalisierten Datensätze für die Vektorisierung und die Modellierung von maschinellem Lernen bereitzustellen. Alle diese Teams müssen zusammenarbeiten, um in einem modernen Data Warehouse zu arbeiten, und Kubernetes gibt ihnen eine große Flexibilität, wie dies geschehen kann.

Teamausrichtung für die Geschäftsbereiche, DevOps, Data Engineering und Data Science

Eine weitere Herausforderung für Unternehmen im Bereich der Infrastruktur für maschinelles Lernen besteht darin, wie vielfältig die Bemühungen sind, diese Pipelines aufzubauen und zu unterstützen. Wie wir in Abbildung 1-4 gesehen haben, gibt es in den meisten Workflows für maschinelles Lernen eine Menge "versteckter technischer Schulden", und die Komponenten dieser Workflows gehören mehreren Teams. Zu diesen Teams gehören :

Geschäftszweig

Der Teil des Unternehmens, der die Ergebnisse des maschinellen Lernmodells nutzen will, um Einnahmen für das Unternehmen zu erzielen

DevOps

Die Gruppe, die dafür verantwortlich ist, dass die Plattform betriebsbereit und sicher ist

Datentechnik

Die Gruppe, die dafür verantwortlich ist, Daten aus dem System of Record (oder Data Warehouse) zu holen und sie in eine Form zu bringen, die das Data Science Team nutzen kann

Datenwissenschaft

Das Team, das für die Erstellung und Prüfung des maschinellen Lernmodells verantwortlich ist

Jedes dieser Teams muss an einem Strang ziehen, sonst wird das Unternehmen wahrscheinlich keinen Nutzen aus ihren individuellen Bemühungen ziehen können. Werfen wir nun einen Blick auf einige spezifische Szenarien, in denen Kubeflow für die oben genannten Teams eingesetzt werden könnte.

Häufige Kubeflow Anwendungsfälle

Konkrete Szenarien für den Einsatz einer Technologie sind immer wichtig, denn sonst ist es nur "mehr Infrastruktur, die wir verwalten müssen". In diesem Abschnitt sehen wir uns einige konkrete Anwendungsfälle an, wie Kubeflow eingesetzt werden kann und wie jedes der Teams aus dem vorherigen Abschnitt involviert sein könnte.

Betrieb von Notebooks auf GPUs

Die Nutzer beginnen in der Regel auf lokalen Plattformen wie Anaconda und entwickeln erste Anwendungsfälle. Wenn ihre Anwendungsfälle mehr Daten, eine leistungsfähigere Verarbeitung oder Daten benötigen, die nicht auf ihren lokalen Laptop kopiert werden können, stoßen sie oft auf Hindernisse, wenn sie ihre Modellaktivitäten vorantreiben wollen.

Wir weisen auch darauf hin, dass die lokale Installation von Jupyter dem Nutzer das gleiche Erlebnis bietet wie die Remote-Installation auf Kubeflow, da eine lokale Installation eine Serverinstallation ist, die nur auf dem Desktop läuft. So gesehen genießen die Nutzer von Jupyter Notebooks auf ihrem Desktop das gleiche Nutzungserlebnis wie auf der Kubeflow-Notebook-Plattform.

Häufige Nutzungsmuster von Notebooks für neue Nutzer

Die Jupyter Notebook App ist eine Client-Server-Anwendung, die das lokale Ausführen von Notebooks unterstützt. Sie ermöglicht es uns, in einem Webbrowser mit dem aktuell laufenden Notebook zu interagieren.

Für Desktop-Nutzer wird die Jupyter Notebook App in der Regel über eine Python-Distribution installiert. Das ist für die meisten Nutzer einfacher, weil die Abhängigkeiten von allen benötigten Python-Paketen nicht so komplex sind. Die beliebteste Distribution ist die Anaconda Distribution.

Notebooks sind beliebt, weil sie Datenwissenschaftlern eine hohe Flexibilität bei der Nutzung der Bibliothek (auch sprachunabhängig) ihrer Wahl in einem Notebook oder außerhalb eines Notebooks auf Kubeflow bieten. Dies ist ein überzeugendes Angebot, da ein Datenwissenschaftler einen in der Sprache seiner Wahl erstellten Workload schnell von seinem Laptop in eine On-Premise Enterprise Cloud oder eine Public Cloud verschieben und mehr Hardware nutzen kann. Dies entspricht dem Muster, dass Aufträge für maschinelles Lernen in der Regel auf dem Laptop des Nutzers prototypisiert und nach der Validierung auf ein leistungsfähigeres System übertragen werden, um dort zu trainieren und dann das Modell einzusetzen.

Vorteile von Notebooks mit GPUs

Angesichts der Tatsache, dass viele Notebook-Benutzer/innen lokal auf ihrem Laptop starten, führt uns das natürlich zu der Frage: "Warum Kubeflow für eine gehostete Notebook-Infrastruktur verwenden?" Maschinelles Lernen und insbesondere Deep-Learning-Trainingsalgorithmen benötigen für ihre linearen Algebra-Routinen notorisch viel Rechenleistung. Grafikprozessoren (GPUs) sind zum Industriestandard geworden, um die Verarbeitung linearer Algebra beim maschinellen Lernen zu beschleunigen. Die meisten Laptops haben keine GPUs an Bord, also müssen die Nutzer/innen nach einem Ort suchen, an dem sie ihren Modellierungscode ausführen können. Eine gängige Plattform, auf die sich die Nutzer geeinigt haben, ist diese:

• Jupyter Notebook
• Python-Code
• Abhängigkeitsmanagement mit Containern, typischerweise Docker

Diese Entwickler sind gut darin, den Stack so zu gestalten, wie sie ihn auf ihrem Laptop haben wollen. Aber wenn man in einem Fortune 500-Unternehmen so arbeitet, hat das Nebenwirkungen wie zum Beispiel:

• Sicherheit
• Datenzugang
• Fahrer Management
• Modellintegration

Die IT-Organisationen der meisten Fortune-500-Unternehmen nehmen Sicherheit und Datenzugriff ernst. Der Gedanke, dass Doktoranden auf ihren Laptops mit sensiblen Unternehmensdaten experimentieren, steht in direktem Widerspruch zu den meisten IT-Sicherheitsrichtlinien, was zu einem natürlichen Konflikt im Unternehmen führt. Dieser Streit dreht sich um das Bedürfnis der Geschäftsbereiche, mehr Wert aus ihren Daten zu schöpfen, und um die Aufgabe der IT-Informationssicherheit, die wichtigen Informationen zu schützen.

Da Unternehmen ihre Sicherheitsanforderungen nicht aufgeben werden, müssen wir Wege finden, wie wir Datenwissenschaftler/innen und ihre Arbeitsweise besser unterstützen können, ohne die Sicherheitsrichtlinien zu verletzen. Kubeflow ist eine großartige Option für dieses Szenario, denn es ermöglicht Datenwissenschaftlern, ihre bevorzugte Arbeitsumgebung in einem Container beizubehalten und in einer Umgebung auszuführen, die von der IT-Unternehmenssicherheit abgesegnet ist.

Diese interne Infrastruktur kann mit Active Directory und Kerberos gesichert werden, während sie gleichzeitig GPUs (z.B. Nvidias DGX-1) und große Speicher-Arrays mit Objektspeichern, proprietärer Speicherung (z.B. FlashBlade von Pure, NetApps Speicherung) oder HDFS bietet.

GPUs und Modellgenauigkeit

Wir möchten klar unterscheiden, was wir von GPUs profitieren, da dies im Marketing für maschinelles Lernen oft vermischt wird. Unter "Vorhersagegenauigkeit des Modells" verstehen wir, wie genau die Vorhersagen des Modells in Bezug auf die jeweilige Aufgabe sind (und es gibt mehrere Möglichkeiten, Modelle zu bewerten).

Eine weitere Facette des Modelltrainings ist die "Trainingsgeschwindigkeit", d.h. wie lange wir brauchen, um eine bestimmte Anzahl von Epochen (Durchläufe über einen gesamten Eingabedatensatz) oder eine bestimmte Genauigkeit/Kennzahl zu trainieren. Wir nennen diese beiden spezifischen Definitionen, weil wir sichergehen wollen, dass du sie verstehst:

1. GPUs werden dein Modell nicht genauer machen.
2. Mit GPUs können wir jedoch ein Modell schneller trainieren und bessere Modelle (die vielleicht genauer sind) schneller finden.

GPUs können also indirekt zur Modellgenauigkeit beitragen, aber wir wollen hier trotzdem Erwartungen setzen.

Teamausrichtung für Notebooks auf GPUs

In diesem Szenario kann das DevOps-Team den Datenwissenschaftlern ermöglichen, mit Kubeflow schneller Modelle zu erstellen. So können die Datenwissenschaftler schneller mehr Konzepte für die Branche erforschen und schlecht geeignete Anwendungsfälle schneller ausschließen.

Wenn die Geschäftsleitung mit dem Data-Science-Team schneller Anwendungsfälle validieren kann, kann sie die besten Lösungen für das Unternehmen finden, um das meiste Geld aus den Daten zu machen.

Gemeinsam genutzte, mandantenfähige Umgebung für maschinelles Lernen

Oft gibt es in einem Unternehmen entweder mehrere Datenwissenschaftler, die sich einen Cluster mit hochwertigen Ressourcen (z. B. GPUs) teilen müssen, oder es gibt mehrere Teams von Datenwissenschaftlern, die denselben Zugang zu gemeinsamen Ressourcen benötigen. In diesem Fall muss ein Unternehmen eine mandantenfähige Plattform für maschinelles Lernen aufbauen, und Kubeflow ist ein guter Kandidat für dieses Szenario.

Oft sehen wir, dass Unternehmen Maschinen mit einem oder mehreren Grafikprozessoren kaufen, die an spezielle Hardware wie eine Nvidia DGX-1 oder DGX-2 angeschlossen sind (z. B. acht Grafikprozessoren pro Maschine). Diese Hardware ist wesentlich teurer als ein herkömmlicher Server, deshalb wollen wir, dass möglichst viele Datenwissenschaftler/innen sie für das Modelltraining nutzen.

Vorteile einer mandantenfähigen On-Premise-Umgebung

Jeder Datenwissenschaftler hat seinen eigenen Modell-Workflow und seine eigenen Code-Abhängigkeiten, wie weiter oben in diesem Kapitel beschrieben. Wir brauchen ein System wie Kubeflow, das den Workflow jedes Nutzers ausführen kann und dabei die Workflow-Abhängigkeiten und Daten von der Arbeit anderer Nutzer an denselben Ressourcen trennt (z. B. Isolation).

Kubeflow und Kubernetes erfüllen diese Anforderungen mit ihren Zeitplanungs- und Containerverwaltungsfunktionen. Ein gutes Beispiel ist, dass wir drei verschiedene Datenwissenschaftler haben, die alle ihr eigenes Notebook auf einer einzigen GPU ausführen müssen. Kubernetes mit Kubeflow behält den Überblick darüber, wer welchen Code auf welchem Rechner ausführt und welche GPUs gerade genutzt werden. Kubernetes behält auch den Überblick darüber, welche Aufträge in der Warteschlange warten, und plant die wartenden Aufträge ein, sobald ein laufender Auftrag beendet ist.

Teamausrichtung

Multitenant-Systeme machen das Leben von DevOps-Teams viel einfacher, weil sie einen Großteil der Infrastrukturkomplexität für uns übernehmen. DevOps können sich darauf konzentrieren, den Kubernetes-Cluster und die Kubeflow-Anwendung in Betrieb zu halten, wodurch wir alle Vorteile der Zeitplanung, des Container-Schedulings und der Ressourcenverwaltung in Kubernetes nutzen können.

Wenn Datenwissenschaftler/innen flexibleren Zugang zu den benötigten Ressourcen (z. B. GPUs) haben, können sie schneller Modelle erstellen. Das wiederum ermöglicht es der Geschäftsleitung, ein Datenprodukt schneller zu bewerten, um zu sehen, ob es effektiv genug ist, um für das Unternehmen rentabel zu sein .

Aufbau einer Transfer Learning Pipeline

Um besser zu verstehen, wie Kubeflow zur Lösung eines realen Problems eingesetzt werden kann, wollen wir ein Computer-Vision-Szenario verwenden. Ein realistisches Beispiel wäre ein Team, das eine Transfer-Learning-Pipeline für Computer Vision in Betrieb nehmen möchte, um ein benutzerdefiniertes Computer-Vision-Modell zur Erkennung bestimmter Artikel in einem Einzelhandelsgeschäft zu erstellen.

Der Grundplan des Teams besteht aus:

• Ein grundlegendes Computer Vision Modell aus dem TensorFlow Modell-Zoo zum Laufen bringen
• Aktualisierung des Modells mit einem Beispieldatensatz, um das Transferlernen zu verstehen
• Verlagerung des Modelltrainingscodes nach Kubeflow, um die Vorteile der GPUs vor Ort zu nutzen

Das Team experimentiert zunächst mit dem Beispiel-Notebook zur Objekterkennung, das im TensorFlow-Tutorial zur Objekterkennung bereitgestellt wird. Sobald sie dieses Notebook lokal ausgeführt haben, wissen sie, dass sie mit einem vorgefertigten TensorFlow-Computer-Vision-Modell Rückschlüsse auf Objekte in einem Bild ziehen können.

Als Nächstes möchte das Team ein Computer-Vision-Modell aus dem Modell-Zoo mit ihrem eigenen Datensatz anpassen, aber zuerst müssen sie ein Gefühl dafür bekommen, wie Transfer Learning in der Praxis funktioniert. Das Team schaut sich die TensorFlow-Dokumentation zum Transfer-Lernen an, um mehr über die Erstellung eines eigenen Computer-Vision-Modells zu erfahren.

Sobald sie das Transfer-Learning-Beispiel mit dem benutzerdefinierten Datensatz zum Laufen gebracht haben, sollte es nicht schwer sein, einige ihrer eigenen Produktdaten zu beschriften, um die Annotationen zu erstellen, die für das weitere Training ihres eigenen benutzerdefinierten Computer-Vision-Modells benötigt werden.

Das ursprüngliche Flower-Beispiel zeigt, wie das Notebook in der Google Cloud als Google Colab-Notebook verwendet wird, aber das Team möchte einen Cluster von Grafikprozessoren in seinem eigenen Rechenzentrum nutzen. An diesem Punkt richtet das Team Kubeflow auf seinem internen Kubernetes-Cluster ein und führt das Transfer-Learning-Notebook als Jupyter-Notebook auf Kubeflow aus. Das Team hatte zuvor einen eigenen annotierten Datensatz erstellt, den es nun für die Erstellung von Modellen auf seinem eigenen internen Kubeflow-Cluster verwenden kann.

Vorteile der Computer Vision Pipeline auf Kubeflow

Die Hauptgründe, warum das Team seine Pipeline auf Kubeflow umstellt, sind:

• Sicherer Zugang zu sensiblen Daten für mehrere Benutzer (Daten, die nicht auf den Laptops der Benutzer gespeichert werden dürfen)
• Kosteneinsparungen durch den Einsatz von GPUs vor Ort
• Mehrere Nutzer können sich denselben Cluster von GPUs teilen

Das Team begründet dies damit, dass Kubeflow in einigen Trainingsszenarien vor Ort pro GPU-Stunde kostengünstiger sein kann als GPUs in der Cloud. Außerdem wollen sie sicher kontrollieren, wo sich der zentrale Trainingsdatensatz befindet, und sie wollen mehreren Datenwissenschaftlern die Möglichkeit geben, denselben konsistenten Trainingsdatensatz gemeinsam zu nutzen, während sie verschiedene Modellvarianten ausprobieren.

Team Alignment für Computer Vision Pipeline

Dieses Transfer-Learning-Szenario auf Kubeflow ermöglicht es dem DevOps-Team, genauer zu kontrollieren, wer eine Kopie der sensiblen Trainingsdaten hat. Die Geschäftsleitung hat das Data-Science-Team beauftragt, ein Modell zu erstellen, das einen mAP-Score hat, der so niedrig ist, dass es für die Geschäftseinheit wirtschaftlich rentabel ist.

Um dieses Modellierungsziel zu erreichen, muss das Data-Science-Team (in Zusammenarbeit mit dem Data-Engineering-Team) viele Variationen von Hyperparametern und Merkmalsauswahlen ausprobieren, um die Effektivität des Modells zu erhöhen. Je schneller das Data Science Team Modelle trainieren kann, desto mehr Variationen von Trainingsläufen kann das Team ausprobieren. Im Fall von Deep Learning und Computer Vision verkürzen GPUs die Trainingsläufe erheblich, so dass sie eine wichtige Ressource für das Data Science Team sind.

Die Geschäftseinheit möchte ihr Ziel einer minimalen Modelleffektivität erreichen, muss dies aber innerhalb eines bestimmten Budgets tun. Die Verwendung von Kubeflow vor Ort mit GPUs ist eine kostengünstigere Möglichkeit, Modelle für das Data-Science-Team zu erstellen, so dass die Kosten am Ende niedriger sind. Die Kosten werden von der Geschäftseinheit als billiger eingeschätzt, weil das Data Science Team prognostiziert, dass es über einen langen Zeitraum hinweg viele Male pro Woche Modelle erstellen muss.

GPUs in der Cloud

GPUs in der Cloud geben uns mehr Flexibilität als GPUs vor Ort, weil wir sie ad hoc und nach Bedarf einrichten können, was es bequemer macht, neue Ideen zu testen.

Diese Bequemlichkeit kann jedoch mehr kosten, als wenn wir eine GPU kaufen und sie die ganze Zeit vor Ort nutzen würden.

Der Kompromiss zwischen Kosten und Flexibilität ist etwas, das wir immer im Hinterkopf behalten sollten, wenn wir entscheiden, wo wir unsere Aufträge ausführen.

Die Verwendung von Kubeflow vor Ort mit GPUs ermöglicht es dem Data-Science-Team außerdem, schneller zu modellieren und gleichzeitig mehrere Computer-Vision-Aufträge auf dem Cluster auszuführen, und zwar im Rahmen der Mandantenfähigkeit des Systems .

Modelle für die Anwendungsintegration in der Produktion bereitstellen

Sobald ein Modell trainiert ist, liegt es normalerweise als einzelne Datei auf einem Laptop oder einem Server vor. Dann müssen wir eine der folgenden Maßnahmen ergreifen:

• Kopiere die Datei auf den Rechner mit der zu integrierenden Anwendung.
• Lade das Modell in einen Serverprozess, der Netzwerkanfragen zur Modellinferenz annehmen kann.

Wenn wir uns dafür entscheiden, die Modelldatei auf einen einzigen Anwendungshost zu kopieren, ist das kein Problem. Wenn jedoch viele Anwendungen die Ergebnisse eines Modells abrufen wollen, wird es komplexer.

Ein großes Problem ist die Aktualisierung des Modells, sobald es in die Produktion überführt wurde. Das macht mehr Arbeit, da wir die Modellversion auf mehreren Rechnern verfolgen und uns daran erinnern müssen, welche davon aktualisiert werden müssen.

Ein weiteres Problem ist die Rückgängigmachung eines Modells, nachdem es eingesetzt wurde. Wenn wir ein Modell bereitgestellt haben und dann feststellen, dass wir die Version auf die vorherige Modellversion zurücksetzen müssen, ist das eine Menge Arbeit, wenn wir viele Kopien des Modells auf verschiedenen Hosts im Umlauf haben. Werfen wir nun einen Blick auf die Vorteile, die sich ergeben, wenn wir ein Modell-Hosting-Muster für die Bereitstellung eines Modells in der Produktion mit Kubeflow verwenden.

Vorteile der Bereitstellung von Modellen für die Produktion auf Kubeflow

Ein großer Vorteil eines Modells für maschinelles Lernen, das in einem Modellserver auf Kubeflow geladen ist, besteht darin, dass wir Aktualisierungen und Rollbacks von einem einzigen Punkt aus durchführen können (z. B. dem Serverprozess). So können wir ein Modell eher wie eine Datenbanktabelle behandeln, indem wir Operationen auf das Modell anwenden und alle Client-Anwendungen, die das Modell nutzen, erhalten die Aktualisierungen, sobald die Update-Transaktion abgeschlossen ist und sie ihre nächste Inferenzanfrage stellen.

Teamabstimmung für die Einführung des Modells

Das Modellserver-Muster macht das Leben des DevOps-Teams erheblich einfacher, da es nicht mehr viele Modellkopien manuell verfolgen muss. Das Anwendungsentwicklungsteam kann sich darauf konzentrieren, das Modell als interne REST-Ressource im Netzwerk zu nutzen, und muss weniger spezifischen API-Code für maschinelles Lernen schreiben, um ein Modell zu integrieren.

Sobald das Data-Science-Team Modelle entwickelt hat, die die Geschäftsbereiche in die Produktion überführen möchten, kann das Modellserver-Muster dem DevOps-Team übergeben werden, das das Modell auf dem Modellserver in Produktion bringt. Auf diese Weise muss sich das Data Science Team nicht mehr um einzelne Modelle in der Produktion kümmern, sondern kann sich darauf konzentrieren, die nächste Runde von Modellen mit den Geschäftsbereichen zu entwickeln.

Komponenten von Kubeflow

Die logischen Komponentengruppen von Kubeflow sind:

• ML-Tools
• Anwendungen und Gerüste
• Plattformen/Wolken

Die Beziehungen zwischen den Komponentengruppen sind in Abbildung 1-5 zu sehen.

Abbildung 1-5. Überblick über die Kubeflow-Plattform (Quelle: Kubeflow-Dokumentation)

Diese Komponenten arbeiten zusammen, um ein skalierbares und sicheres System für die Ausführung von Aufträgen des maschinellen Lernens (notebookbasierte Aufträge und auch Aufträge außerhalb von Notebooks) bereitzustellen.

Angesichts des Aufstiegs von Kubernetes als Management-System für Unternehmensplattformen ist es sehr sinnvoll, eine Möglichkeit zu haben, unsere Machine Learning-Workloads auf ähnliche Weise zu verwalten. Im weiteren Verlauf dieses Abschnitts werfen wir einen Blick auf die einzelnen Komponentengruppen, einige ihrer Komponenten und wie sie in der Kubeflow-Plattform verwendet werden.

Machine Learning Tools

Viele Frameworks für maschinelles Lernen werden von Kubeflow unterstützt. Theoretisch könnte ein Nutzer einfach ein beliebiges Framework in einen Container packen und es einem Kubernetes-Cluster zur Ausführung übergeben. Kubeflow macht die Kubernetes-Cluster jedoch auf die Besonderheiten aufmerksam, die jede Bibliothek für maschinelles Lernen erwartet oder benötigt, z. B. paralleles Training auf mehreren Kubernetes-Knoten oder die Verwendung von GPUs auf bestimmten Knoten.

Die aktuellen von Kubeflow unterstützten Trainingsframeworks sind :

• TensorFlow
• XGBoost
• Keras
• scikit-learn
• PyTorch
• MXNet
• MPI
• Chainer

Als Nächstes geben wir einen kurzen Überblick über einige Frameworks und wie sie verwendet werden.

TensorFlow Training und TFJob

TensorFlow wird von Kubeflow unterstützt und ist heute die weltweit beliebteste Bibliothek für maschinelles Lernen. Da TensorFlow, Kubernetes und Kubeflow ursprünglich von Google entwickelt wurden, ist es nur logisch, dass diese Bibliothek auch von Kubeflow unterstützt wird.

Wie bereits erwähnt, ist TFJob eine benutzerdefinierte Komponente für Kubeflow, die einen benutzerdefinierten Kubernetes-Ressourcen-Deskriptor (CRD) und einen zugehörigen Controller(tf-operator) enthält. Der TFJob CRD ermöglicht es Kubernetes, verteilte TensorFlow-Aufträge auszuführen. Der TFJob-Controller (tf-operator) ist Teil der unterstützenden Anwendungen und des Gerüsts, das in Kubeflow enthalten ist, um Bibliotheken für maschinelles Lernen in Kubernetes zu ermöglichen.

Schau dir die Kubeflow-Dokumentationsseite zu TensorFlow an.

Keras

Keras wird im Kubeflow-Projekt unterstützt und kann auf verschiedene Arten verwendet werden :

• Einzelprozessauftrag, der als benutzerdefinierte Ressourcendefinition (CRD) ausgeführt wird
• Einzelprozess-GPU-Auftrag, der als CRD ausgeführt wird
• TFJob als Einzelarbeitsplatz
• TFJob als Auftrag mit verteilten Mitarbeitern (über die Estimator API)
• Jupyter Notebook (CPU oder GPU)
• Kubeflow Pipelines-konfigurierter Auftrag

Oftmals möchte ein Nutzer einfach nur verstehen, wie er einen Auftrag schnell auf den Cluster bringen kann. In Beispiel 1-1 zeigen wir den einfachsten Weg, einen Keras-Job auf Kubernetes als Job von der Kommandozeile mit kubectl auszuführen.

Beispiel 1-1. Auftragsbeispiel YAML zur Ausführung eines Keras-Python-Skripts

apiVersion: batch/v1
kind: Job
metadata:
  name: keras-job
spec:
  template:
    spec:
      containers:
      - name: tf-keras-gpu-job
        image: emsixteeen/basic_python_job:v1.0-gpu
        imagePullPolicy: Always
      volumes:
      - name: home
        persistentVolumeClaim:
          claimName: working-directory
      restartPolicy: Never
  backoffLimit: 1

Im vorangegangenen Beispiel würde Kubernetes das Container-Image aus dem Standard-Container-Repository ziehen und es dann als Pod auf dem Kubernetes-Cluster ausführen.

In diesem Beispiel überspringen wir alle anderen, komplexeren Möglichkeiten, Kubeflow zu nutzen, und führen das Keras-Skript als einfachen und direkten Kubernetes-Pod aus. Dadurch verlieren wir jedoch die Vorteile von Kubeflow in Bezug auf die Workflow-Orchestrierung und die Sammlung von Metadaten.

Der Vorteil von Kubeflow gegenüber Kubernetes

Ohne die Orchestrierung von Workflows und die Nachverfolgung von Metadaten verlieren wir die Möglichkeit, Workflows für maschinelles Lernen zuverlässig und konsistent auszuführen und zu verstehen, wie sie sich entwickeln, wenn wir unseren Trainingscode ändern.

Beispiel 1-1 zeigt, dass du zwar einfache Skripte für maschinelles Lernen in Kubernetes ausführen kannst, Kubeflow aber noch weitere Vorteile für Kubernetes bietet, die vielleicht nicht sofort erkennbar sindd.

Anwendungen und Gerüste

Die Verwaltung der Infrastruktur für maschinelles Lernen unter all den Einschränkungen und Zielen, die wir in diesem Kapitel beschrieben haben, ist ein hoher Berg, den es zu erklimmen gilt. Kubeflow bietet viele Unteranwendungen und Gerüstkomponenten, die dabei helfen, den gesamten Machine-Learning-Workflow zu unterstützen.

Einige der "Gerüst"-Komponenten, die sich aus Sicht der meisten Nutzer "unter der Haube" befinden, sind :

• Operatoren des maschinellen Lernens
• Metadaten
• PyTorch dient
• Seldon Kern
• TensorFlow Servieren
• Istio
• Argo
• Prometheus
• Spartakus

Viele der oben genannten Komponenten werden nie direkt von einem normalen Nutzer verwendet, sondern unterstützen stattdessen Kernfunktionen in Kubeflow. So unterstützt Istio beispielsweise den Betrieb der verteilten Microservice-Architektur von Kubeflow, indem es Funktionen wie die rollenbasierte Zugriffskontrolle (RBAC) für Netzwerkendpunkte und Ressourcen bereitstellt. Argo bietet kontinuierliche Integrations- und Bereitstellungsfunktionen für Kubeflow. Prometheus bietet Systemen in Kubeflow die Überwachung von Komponenten und die Möglichkeit, vergangene Ereignisse in Überwachungsdaten abzufragen.

In den folgenden Unterkapiteln werden wir uns einige der wichtigsten Anwendungen und Komponenten von Kubeflow genauer ansehen.

Kubeflow UI

Die Kubeflow-Benutzeroberfläche ist der zentrale Knotenpunkt für die Aktivitäten eines Benutzers auf der Kubeflow-Plattform. Der Hauptbildschirm von Kubeflow ist in Abbildung 1-6 zu sehen.

Abbildung 1-6. Die Kubeflow-Benutzeroberfläche

Von der Kubeflow-Benutzeroberfläche aus können wir Aufgaben wie das Erstellen von Pipelines, das Ausführen von Hyperparameter-Optimierungsaufträgen mit Katib und das Starten von Jupyter Notebook-Servern visuell durchführen.

Jupyter Notebooks

Jupyter Notebooks sind als Kernkomponente in der Kubeflow-Plattform enthalten. Diese Notebooks sind aufgrund ihrer Benutzerfreundlichkeit sehr beliebt und werden (vor allem beim maschinellen Lernen) häufig mit der Programmiersprache Python in Verbindung gebracht. Notebooks enthalten in der Regel Code (z. B. Python, Java) und andere visuelle Rich-Text-Elemente, die eine Webseite oder ein Lehrbuch nachahmen.

Notebooks und verschiedene Programmiersprachen

Ein Notebook-Kernel ist das, was den Code in einem Notizbuch ausführt. Es kann verschiedene Kernel geben, je nachdem, welche Art von Sprache in das Dokument eingebettet ist.

Der Name Jupyter ist ein Portmanteau aus Julia, Python und R, den drei ursprünglichen Sprachen, die vom Jupyter-Ökosystem unterstützt werden. Obwohl Jupyter Notebooks nur lose mit Python verbunden sind, verwendet ein Python-basiertes Notebook zum Beispiel den IPython-Kernel. Die Jupyter Notebook App erkennt automatisch die Sprache, die für das aktuell laufende Notebook verwendet wird, und lädt den entsprechenden Kernel für uns.

Ein neuer Aspekt von Notizbüchern ist, dass sie das Konzept eines Computerprogramms mit den Notizen kombinieren, die wir normalerweise mit komplexer Logik in unseren Programmen verbinden. Diese Eigenschaft der Inline-Dokumentation ermöglicht es den Nutzern von Notizbüchern, nicht nur zu dokumentieren, was sie tun, sondern es auch anderen Nutzern mitzuteilen, die unseren Code ausführen möchten. Angesichts der Komplexität des Codes für maschinelles Lernen ist diese Eigenschaft einer der Gründe für die explosionsartige Beliebtheit der Notebooks im Bereich des maschinellen Lernens.

Jupyter Notebook Integration mit Kubeflow

Die Kubeflow-Anwendungsbereitstellung umfasst Unterstützung für das Erzeugen und Betreiben von Jupyter Notebooks. Die Vorteile der Integration von Jupyter Notebooks in die Kubeflow-Plattform sind unter anderem:

• Gute Integration mit dem Rest der Kubeflow-Infrastruktur im Hinblick auf Authentifizierung und Zugriffskontrolle
• Möglichkeit der gemeinsamen Nutzung von Notizbüchern durch andere Nutzer

Notebooks und Verkleidung

Jupyter-Notebooks in Kubeflow haben auch Zugriff auf die Fairing-Bibliothek, sodass die Notebooks Trainingsaufträge vom Notebook aus an Kubernetes senden können. Das ist besonders interessant, weil der Code in einem Jupyter-Notebook standardmäßig nur im Einzelprozessmodus ausgeführt wird. Durch die Möglichkeit, Aufträge vom Notebook aus an Kubernetes zu senden, können wir TFJob nutzen, um verteilte Trainingsaufträge auszuführen.

Manchmal wollen wir für jeden Nutzer oder für ein Team eigene Notebook-Server. Kubeflow ermöglicht es uns, mehrere Notebook-Server für eine bestimmte Kubeflow-Installation einzurichten. Jeder Notebook-Server gehört zu einem Namensraum und kann mehrere Notebooks bedienen und ausführen. Namensräume in Kubeflow ermöglichen auch die Isolierung mehrerer Benutzer. Das bedeutet, dass wir mehrere Benutzer haben können, die die Ressourcen der anderen nicht sehen können, damit sie sich nicht gegenseitig die Arbeitsbereiche in der gemeinsamen mandantenfähigen Infrastruktur blockieren.

Kubeflow startet für jeden Notebook-Server ein Container-Image in Kubernetes. Das Notebook-Image enthält Abhängigkeiten wie die Bibliotheken für ML und die CPU- oder GPU-Unterstützung im Notebook.

Operatoren für Frameworks für maschinelles Lernen

Jedes unterstützte Machine-Learning-Framework auf Kubeflow hat einen zugehörigen Controller (z.B., tf-operator). Die TFJob CRD ermöglicht es Kubernetes zum Beispiel, verteilte TensorFlow-Aufträge auszuführen. Der TFJob-Controller (tf-operator) ist Teil der unterstützenden Anwendungen und des Gerüsts, das Kubeflow enthält, um Machine-Learning-Bibliotheken auf Kubernetes zu ermöglichen.

Metadaten und Artefakte

Die Metadatenkomponente in Kubeflow hilft Nutzern, ihre ML-Workflows zu verfolgen und zu verwalten, indem sie die von den Workflows erzeugten Metadaten sammelt und speichert. Die Informationen, die das Metadatensystem in Kubeflow über einen Workflow sammelt, umfassen Ausführungen, Modelle, Datensätze und andere Artefakte. Kubeflow definiert Artefakte in diesem Zusammenhang als die Objekte und Dateien, die die Eingaben und Ausgaben der Komponenten in einem Machine-Learning-Workflow bilden, was wir in Kapitel 2 näher erläutern.

Sobald ein Code ausgeführt wird, bei dem die kubeflow-metadata API Metadaten für einen Workflow sammelt, kannst du die Registerkarte "Artefakte" in deiner Kubeflow-Benutzeroberfläche aufrufen und die pro Ausführungslauf gesammelten Metadaten sehen, wie in Abbildung 1-7 dargestellt.

Abbildung 1-7. Die Registerkarte "Artefakt" in der Kubeflow-Benutzeroberfläche

Abstimmung der Hyperparameter

Beim Hyperparameter-Tuning geht es darum, den Hyperparameter-Suchraum zu erkunden, um einen optimalen (oder nahezu optimalen) Satz von Hyperparametern für das Training eines Machine-Learning-Modells zu finden. Datenwissenschaftler/innen verbringen eine nicht unerhebliche Zeit damit, Kombinationen von Hyperparametern auszuprobieren, um zu sehen, wie viel genauer ihr Modell dadurch wird.

Maschinelles Lernen, Parameter und Hyperparameter

Machen wir einen kurzen Abstecher und definieren wir einige Begriffe aus dem Bereich des maschinellen Lernens. In diesem Kapitel haben wir maschinelles Lernen definiert als:

Verwendung von Algorithmen zur Erfassung von Strukturbeschreibungen aus Datenbeispielen.

Beim maschinellen Lernen suchen wir nach einer Reihe von Funktionskoeffizienten, die die Genauigkeit (oder den Wert) unseres Modells in Bezug auf eine Reihe von Grundwahrheiten maximieren. Dieser Satz von Funktionskoeffizienten wird manchmal als Parameter bezeichnet. In neuronalen Netzen sind Parameter zum Beispiel die Gewichte der Verbindungen zwischen den künstlichen Neuronen in den Schichten.

Aus dem Kontext des maschinellen Lernens können wir sagen:

Beim maschinellen Lernen gibt es sowohl Modellparameter als auch Parameter, die wir einstellen, damit Netzwerke besser und schneller trainieren. Diese Tuning-Parameter werden Hyperparameter genannt und dienen der Steuerung von Optimierungsfunktionen und der Modellauswahl während des Trainings mit unserem Lernalgorithmus.

Deep Learning von Josh Patterson und Adam Gibson (O'Reilly)

Beispiele für Hyperparameter sind:

• Lernrate
• Regulierung
• Momentum
• Sparsamkeit
• Art der Verlustfunktion
• Optimierungsalgorithmus

Bei der Abstimmung der Hyperparameter werden verschiedene Kombinationen der oben genannten Trainingsoptionen ausprobiert, um eine Kombination von Parametern für unser Modell zu finden, die uns die beste Modellgenauigkeit für unser Zielproblem liefert.

Die in Kubeflow enthaltene Hyperparametersuchanwendung heißt Katib. Katib wurde ursprünglich von einem Google-internen System namens Vizier inspiriert und ist unabhängig von einem Machine Learning Framework. Mit Katib können wir eine Reihe von Experimenten erstellen, um Versuche für die Bewertung von Hyperparametern zu testen. Derzeit unterstützt Katib Explorationsalgorithmen wie die Zufallssuche, die Gittersuche und mehr.

Pipelines

MitKubeflow Pipelines können wir Workflows für maschinelles Lernen erstellen und sie als logische Einheit auf Kubeflow bereitstellen, um sie als Container auf Kubernetes auszuführen. Oft sehen wir Beispiele für maschinelles Lernen in einem einzelnen Jupyter-Notebook oder Python-Skript, aber Workflows für maschinelles Lernen sind in der Regel nicht ein einzelnes Skript oder ein Auftrag.

Zuvor haben wir in diesem Kapitel Abbildung 1-8 aus "Versteckte technische Schulden beim maschinellen Lernen" vorgestellt.

Abbildung 1-8. Diagramm aus dem Papier "Hidden Technical Debt in Machine Learning"

Viele der Kästchen in diesem Diagramm werden in der Praxis in einem Produktionssystem für maschinelles Lernen zu eigenen Sub-Workflows. Beispiele dafür sind die Datensammlung und das Feature-Engineering, die jeweils eigene Arbeitsabläufe darstellen können, die von anderen Teams als dem Data Science Team erstellt werden. Die Modellevaluierung ist eine weitere Komponente, die nach der Trainingsphase oft als eigener Workflow durchgeführt wird.

Kubeflow Pipelines (siehe Abbildung 1-9) vereinfachen die Orchestrierung dieser Pipelines als Container in der Kubernetes-Infrastruktur. So können unsere Teams komplexe Pipelines für maschinelles Lernen auf modulare Weise neu konfigurieren und bereitstellen, um die Modellbereitstellung und die Zeit bis zur Produktion zu verkürzen.

Abbildung 1-9. Pipeline-Benutzeroberfläche

Grundlegende Konzepte der Kubeflow Pipeline

Eine Kubeflow-Pipeline ist ein gerichteter azyklischer Graph (DAG), der alle Komponenten des Workflows darstellt. Pipelines definieren die Eingabeparameter, die für die Ausführung der Pipeline erforderlich sind, und legen fest, wie die Ausgabe jeder Komponente als Eingabe für die nächste Stufe im Graphen verdrahtet wird.

Eine Pipeline-Komponente wird als Docker-Image definiert, das den Benutzercode und die Abhängigkeiten für die Ausführung in Kubernetes enthält. In Beispiel 1-2 sehen wir ein Beispiel für eine Pipeline-Definition in Python.

Beispiel 1-2. Kubeflow-Pipeline in Python definiert

@dsl.pipeline(
  name='XGBoost Trainer',
  description='A trainer that does end-to-end distributed training for XGBoost models.'
)
def xgb_train_pipeline(
    output,
    project,
    region='us-central1',
    train_data='gs://ml-pipeline-playground/sfpd/train.csv',
    eval_data='gs://ml-pipeline-playground/sfpd/eval.csv',
    schema='gs://ml-pipeline-playground/sfpd/schema.json',
    target='resolution',
    rounds=200,
    workers=2,
    true_label='ACTION',
):
    delete_cluster_op = DeleteClusterOp('delete-cluster', 
      project, region).apply(gcp.use_gcp_secret('user-gcp-sa'))
    with dsl.ExitHandler(exit_op=delete_cluster_op):
    create_cluster_op = CreateClusterOp('create-cluster', project, region, 
      output).apply(gcp.use_gcp_secret('user-gcp-sa'))

    analyze_op = AnalyzeOp('analyze', project, region, create_cluster_op.output, \ 
       schema,
      train_data, '%s/{{workflow.name}}/analysis' % \ 
         output).apply(gcp.use_gcp_secret('user-gcp-sa'))

    transform_op = TransformOp('transform', project, region, create_cluster_op.output,
      train_data, eval_data, target, analyze_op.output,
      '%s/{{workflow.name}}/transform' %  \ 
         output).apply(gcp.use_gcp_secret('user-gcp-sa'))

    train_op = TrainerOp('train', project, region, create_cluster_op.output, \ 
       transform_op.outputs['train'],
      transform_op.outputs['eval'], target, analyze_op.output, workers,
      rounds, '%s/{{workflow.name}}/model' % \ 
         output).apply(gcp.use_gcp_secret('user-gcp-sa'))
...

Wenn wir uns dieses Diagramm in der Pipelines UI in Kubeflow ansehen, sieht es ähnlich aus wie Abbildung 1-10.

Abbildung 1-10. Visualisierung einer Pipeline in Kubeflow

Die Kubeflow Pipelines UI ermöglicht es uns außerdem, Eingabeparameter pro Lauf zu definieren und den Job zu starten. Zu den gespeicherten Ergebnissen der Pipeline gehören Diagramme wie eine Konfusionsmatrix und Receiver-Operating-Characteristics (ROC)-Kurven.

Kubeflow-Pipelines erzeugen und speichern sowohl Metadaten als auch Artefakte aus jedem Lauf. Die Metadaten aus den Pipeline-Läufen werden in einer MySQL-Datenbank gespeichert und die Artefakte in einem Artefakt-Speicher wie dem MinIO-Server oder einer Cloud-Speicherung. Sowohl MinIO als auch MySQL werden durch PersistentVolumes (PV) in Kubernetes gesichert.

Die gespeicherten Metadaten ermöglichen es Kubeflow, bestimmte Experimente und Aufträge zu verfolgen, die auf dem Cluster ausgeführt werden. Die Artefakte speichern Informationen, mit denen wir die Laufleistung eines einzelnen Jobs untersuchen können .

Modellinferenz beim maschinellen Lernen mit KFServing

Sobald wir ein Modell erstellt haben, müssen wir das gespeicherte Modell in unsere Anwendungen integrieren. Kubeflow bietet mehrere Möglichkeiten, gespeicherte Modelle in einen Prozess zu laden, um externe Anwendungen mit Live-Modellinferenzen zu versorgen. Diese Optionen umfassen :

• KFServing
• Seldon Core Serving
• BentoML
• Nvidia Triton Inference Server
• TensorFlow Servieren
• TensorFlow Batch-Vorhersage

Die oben genannten Optionen unterstützen unterschiedliche Bibliotheken für maschinelles Lernen und haben ihre eigenen spezifischen Funktionen. In der Regel gibt es für jede Option ein Docker-Image, das du als Kubernetes-Ressource ausführen und dann ein gespeichertes Modell aus einem Modell-Repository laden kannst.

KFServing wurde so konzipiert, dass Model Serving in einer standardisierten Weise über verschiedene Frameworks hinweg betrieben werden kann. Es bestand Bedarf an einem Model-Serving-System, das problemlos auf bestehenden Kubernetes- und Istio-Stacks ausgeführt werden kann und darüber hinaus die Erklärbarkeit von Modellen, Inferenzgraphenoperationen und andere Modellmanagementfunktionen bietet. Kubeflow sollte es sowohl Datenwissenschaftlern als auch DevOps/MLOps-Teams ermöglichen, von der Modellproduktion bis zum modernen Produktionsmodelleinsatz zusammenzuarbeiten.

Der Kernwert von KFServing kann folgendermaßen ausgedrückt werden:

• Unterstützung bei der Standardisierung der Modellbereitstellung in verschiedenen Organisationen mit einer einheitlichen Datenebene und vorgefertigten Modellservern
• Ein einziger Weg zur Bereitstellung, Überwachung von Inferenzdiensten/Servern und Skalierung der Inferenzauslastung
• Drastische Verkürzung der Zeit für den Datenwissenschaftler, um das Modell in der Produktion einzusetzen

Was ist eine Modellinferenz?

Ein Inferenzserver für maschinelles Lernen nimmt neue Eingabewerte auf und übergibt sie als Vektoren an ein gespeichertes Modell, um eine Ausgabe zu erzeugen. Diese Ausgabe wird als "Modellinferenz" bezeichnet.

In einigen Fällen kann ein Framework-spezifischer Inferenzserver (z. B. TensorFlow Serving) spezielle Funktionen für ein zugehöriges Framework haben.

Viele Teams werden jedoch andere Frameworks verwenden und brauchen mehr Flexibilität für ihre Model Inference Serving-Infrastruktur. In diesem Fall solltest du KFServing oder Seldon Core in Betracht ziehen, wie bereits beschrieben. In Kapitel 8 befassen wir uns ausführlich mit KFServing, angefangen bei den grundlegenden Konzepten für den Einsatz eines Basismodells auf KFServing bis hin zum Aufbau von benutzerdefinierten Modellservern für den Einsatz von Modellen auf KFServing.

Plattformen und Clouds

Kubeflow kann überall dort eingesetzt werden, wo Kubernetes eingesetzt werden kann, von einer großen öffentlichen Cloud über einen Kubernetes-Cluster vor Ort bis hin zu einem lokalen Kubernetes-Einsatz auf einem einzelnen Rechner.

Öffentliche Wolken

Da alle drei großen Cloud-Anbieter sowohl verwaltetes Kubernetes als auch die manuelle Bereitstellung von Kubernetes auf VMs unterstützen, kann Kubeflow in jeder der großen Clouds eingesetzt werden, einschließlich :

• Google Cloud Platform (GCP)
• Amazon Web Services (AWS)
• Azure Cloud Plattform

Spätere Kapitel gehen auf die Besonderheiten der Installation und der Konfigurationen jeder dieser Clouds ein. Wir informieren dich auch darüber, was die einzelnen großen Clouds anbieten und wie sie mit dem verwalteten Kubernetes-Angebot für die Cloud zusammenarbeiten. So bekommst du einen soliden Überblick darüber, wie gut deine bevorzugte Cloud für den Betrieb ihrer Kubernetes- und Kubeflow-Infrastruktur geeignet ist.

Für die Installation von Kubeflow in einer öffentlichen Cloud sind einige Dinge erforderlich, darunter:

• Verstehen, wie der Cloud-Anbieter mit deiner eigenen Infrastruktur zusammenarbeitet
• Sicherstellen, dass es die richtige Version von Kubernetes (und anderen Unterkomponenten) für dein Unternehmen ist
• Themen der Sicherheitsintegration

Abgesehen von den dogmatischen Themen der Anbieter geht es bei der Infrastruktur vor allem darum, wie ein System als Legacy-Momentum in die Unternehmensinfrastruktur integriert werden kann. Wenn dieses Konzept gut umgesetzt wird, schafft es einen beständigen Wert für jedes Unternehmen.

Erwäge die Optionen für Cloud-basiertes Kubeflow

Die manuelle Ausführung deiner eigenen Kubeflow-Installation kann komplex sein. Wenn du eine einzelne Cloud mit Standard-Kubeflow verwendest, sollte dein Team den Einsatz von verwalteten Notebooks, serverlosen Trainings und Vorhersagen sowie einen präskriptiven Pipeline-Ansatz wie TFX in Betracht ziehen, der die Pipeline-Schritte auf einer serverlosen Infrastruktur durchführt. Beispiele wären SageMaker auf AWS oder CAIP auf GCP.

Wenn deine Installation komplexe Anpassungen erfordert (z. B. eigene Container-Images oder eigene Netzwerkanforderungen), kann es sinnvoller sein, deine eigene Kubeflow-Installation in der Cloud zu verwalten.

Verwaltetes Kubernetes in der Cloud

Wie bereits in diesem Kapitel erwähnt, bieten alle drei großen Clouds eine Open-Source-kompatible Version von verwalteten Kubernetes an:

• Google Kubernetes Engine (GKE)
• Azure Kubernetes Dienste (AKS)
• Amazon Kubernetes Engine (AKE)

Jedes System hat Ähnlichkeiten und Unterschiede in der Art und Weise, wie wir Kubeflow installieren und integrieren. Natürlich gibt es für jede Cloud unterschiedliche Vorgehensweisen bei der Installation von Kubeflow, z. B:

• Arten und Strategien der Speicherung
• Einrichtung und Verwaltung von Identitäten
• Strategien für das Containermanagement
• Integration von ETL-Pipelines
• Planung der Infrastruktur und Modellierung der Kosten

Im Laufe dieses Buches werden wir dich in die Kernkonzepte der einzelnen Cloud-Angebote einführen und dir dann zeigen, wie du Kubeflow speziell für jede der Cloud-Plattformen installierst.

Vor-Ort

Kubeflow wird unterstützt, wenn es in einem Kubernetes-Cluster vor Ort eingesetzt wird. Der größte Unterschied zwischen Kubeflow auf einem On-Premise-Cluster und Kubeflow auf einer großen Cloud ist, dass ein On-Premise-Cluster mehr Einschränkungen bei der dynamischen Skalierung von Ressourcen hat. Allerdings wird ein On-Premise-Cluster nicht stundenweise abgerechnet, sodass jedes Unternehmen einen Kompromiss eingehen muss.

Wie wir im Laufe dieses Buches sehen werden, gibt es auch unterschiedliche Strategien für die Identitätsintegration von On-Premise-Kubernetes und Cloud-Kubernetes.

Lokales

In manchen Fällen - vor allem bei Tests, Entwicklung und Evaluierung - möchtest du Kubeflow vielleicht auf einem lokalen Rechner oder einer VM ausführen. In diesem Fall kannst du entweder VMs verwenden, um einen kleinen Kubernetes-Cluster lokal einzurichten, oder du kannst ein vorgefertigtes Kubernetes-System mit einem Knoten wie Minikube verwenden.

Der lokale Betrieb von Kubeflow kann eine Menge Ressourcen beanspruchen

In der Regel benötigt ein Kubeflow on Minikube-Einsatz mindestens 12 GB Arbeitsspeicher und 4 CPUs, die für Minikube reserviert sind. Du solltest auch bedenken, wie viele Ressourcen dein Computer zusätzlich zu diesen Anforderungen benötigt, um normal zu funktionieren.

In Kapitel 8 führen wir eine Übung durch, in der wir KFServing als Einzelplatzversion auf Minikube einsetzen, um die Modellbereitstellung zu testen.

Zusammenfassung

In diesem Einführungskapitel haben wir den Anstoß für Kubeflow als Plattform für maschinelles Lernen gegeben. Im weiteren Verlauf dieses Buches erfahren wir, wie wir die Kubeflow-Plattform als wichtigen Eckpfeiler unserer Machine-Learning-Infrastruktur planen, installieren, warten und entwickeln. Im nächsten Kapitel führen wir dich durch die Sicherheitsgrundlagen und die Architektur von Kubeflow, um die operativen Inhalte für den Rest des Buches vorzubereiten.