Kapitel 4. Installation von Kubeflow On-Premise

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com

In diesem Kapitel werfen wir einen Blick auf die Grundlagen für die Installation von Kubeflow auf einem bestehenden Kubernetes-Cluster vor Ort. In diesem Kapitel wird davon ausgegangen, dass du bereits über ein gewisses Hintergrundwissen zu Kubernetes verfügst und dass du Zugang zu einem bestehenden Kubernetes-Cluster hast, der entweder vor Ort oder in der Cloud verwaltet wird. Es gibt auch Optionen für Lernumgebungen wie Minikube, kubeadm-dind.

Wir gehen außerdem davon aus, dass du dich mit der Installation von Software-Infrastrukturen auskennst und mit einer Befehlszeile arbeiten kannst. Wenn du eine kurze Auffrischung brauchst, gehen wir im nächsten Abschnitt auf einige grundlegende Befehle für Kubernetes ein.

Kubernetes-Operationen über die Kommandozeile

Da Kubeflow eng mit Kubernetes integriert ist, müssen wir einige Kubernetes-Kernbefehle kennen, um jede Art von Installation durchzuführen. In diesem Abschnitt gehen wir auf diese Befehle ein:

  • kubectl
  • docker

In diesem Kapitel erfährst du, um welche Teile von Kubernetes wir uns bei einer Vor-Ort-Installation kümmern müssen. Beginnen wir damit, einige unserer wichtigsten Kommandozeilen-Tools zu installieren.

Installieren von kubectl

kubectl steuert den Kubernetes-Cluster-Manager und ist eine Befehlszeilenschnittstelle für die Ausführung von Befehlen für Kubernetes-Cluster. Wir verwenden , um Anwendungen auf Kubernetes zu verteilen und zu verwalten. Mit können wir: kubectl kubectl

  • Cluster-Ressourcen inspizieren
  • Komponenten erstellen
  • Komponenten löschen
  • Komponenten aktualisieren

Eine vollständige Liste der Funktionen in kubectl findest du in diesem Spickzettel.

kubectl ist ein grundlegendes Werkzeug für den Betrieb von Kubernetes und Kubeflow und wir werden es im Laufe der Bereitstellung von Komponenten und der Ausführung von Aufträgen auf Kubeflow häufig verwenden.

Installation von kubectl unter macOS

Eine einfache Möglichkeit, kubectl auf macOS zu installieren, ist der Befehlbrew:

brew install kubernetes-cli

Sobald wir kubectl haben, brauchen wir die Erlaubnis, um mit unserem Kubernetes-Cluster zu kommunizieren.

Verstehen von kubectl und Kontexten

kubectl weiß, wie sie mit entfernten Clustern kommunizieren kann, und zwar auf der Grundlage einer lokalen Kontextdatei, die auf der Festplatte gespeichert ist. Wir definieren einen kubectl Kontext als einen Eintrag in einer kubectl Datei, der dazu dient, eine Gruppe von Zugriffsparametern unter einer gemeinsamen ID zu identifizieren. Jede dieser Gruppen von Zugriffsparametern, oder Kontexte, hat drei Parameter :

  • Cluster
  • Namensraum
  • Benutzer

Der Standardspeicherort für die lokale kubeconfig Datei ist ~/.kube/config (oder $HOME/.kube/config). Wir können diesen Ort auch mit der Umgebungsvariablen KUBECONFIG oder durch Setzen des --kubeconfig Flagge.

Wir können auch mehrere Konfigurationsdateien verwenden, aber im Moment betrachten wir den Fall der Standardkonfigurationsdatei. In einigen Fällen wirst du mit mehreren Clustern arbeiten, deren Kontextinformationen ebenfalls in dieser Datei gespeichert werden.

Um die aktuelle kubectl Konfiguration anzuzeigen, verwende den Befehl:

kubectl config view

Die Ausgabe sollte in etwa so aussehen:

apiVersion: v1
clusters:
- cluster:
    certificate-authority: /home/ec2-user/.minikube/ca.crt
    server: https://172.17.0.3:8443
  name: kubeflow
contexts:
- context:
    cluster: kubeflow
    user: kubeflow
  name: kubeflow
current-context: kubeflow
kind: Config
preferences: {}
users:
- name: kubeflow
  user:
    client-certificate: /home/ec2-user/.minikube/profiles/kubeflow/client.crt
    client-key: /home/ec2-user/.minikube/profiles/kubeflow/client.key

Die Ausgabe kann variieren, je nachdem, wie viele Kontexte sich gerade in deiner lokalen Datei befinden, aber sie verrät uns zum Beispiel, welche Cluster wir angehängt haben und wie die Konfiguration für den aktuellen Kontext aussieht. Weitere Informationen zu den Operationen, die wir mit dem Kontextsystem für kubectl durchführen können, findest du in der Online-Ressource.

Wir verwenden kubectl Kontextdateien, um Informationen zu organisieren:

  • Clusters
  • Benutzer
  • Namensräume
  • Authentifizierungsmechanismen

Schauen wir uns nun ein paar konkrete Möglichkeiten an, wie du die Kontextdatei und kubectl nutzen kannst.

Den aktuellen Kontext abrufen

Wenn wir wissen wollen, was der aktuelle Kontext ist, würden wir den Befehl verwenden:

kubectl config current-context

Die Ausgabe sollte in etwa so aussehen wie die folgende Konsolen-Log-Ausgabe:

kubeflow

Dadurch erhalten wir die ID der Kontextgruppe in unserer Kontextdatei. kubectl sendet derzeit Kubernetes-Befehle an den Cluster, der durch diese ID repräsentiert wird.

Hinzufügen von Clustern zu unserer Kontextdatei

Um einen neuen Kubernetes-Cluster zu unserer lokalen Kontextdatei hinzuzufügen, verwenden wir die Befehle set-cluster, set-credentials und set-context, wie im folgenden Beispiel zu sehen ist:

kubectl config \
set-cluster NAME \
[--server=server] \
[--certificate-authority=path/to/certificate/authority] \
[--insecure-skip-tls-verify=true]

kubectl config \
set-credentials NAME \
[--client-certificate=path/to/certfile] \
[--client-key=path/to/keyfile] \
[--token=bearer_token] \
[--username=basic_user] \
[--password=basic_password] \
[--auth-provider=provider_name] \
[--auth-provider-arg=key=value] \
[--exec-command=exec_command] \
[--exec-api-version=exec_api_version] \
[--exec-arg=arg][--exec-env=key=value] \
[options]

kubectl config \
set-context [NAME | --current] \
[--cluster=cluster_nickname] \
[--user=user_nickname] \
[--namespace=namespace] \
[options]

Beachte, dass im Befehl set-context der Parameter NAME der Name des Berechtigungsnachweises ist, der mit dem Befehl set-credentials eingegeben wurde.

Im nächsten Kapitel schauen wir uns an, wie wir Anmeldeinformationen für eine öffentliche Cloud abrufen und den Kubernetes-Kontext automatisch zu unserer lokalen Kontextdatei hinzufügen.

Kontexte wechseln

Um den Standardkontext so zu ändern, dass er auf einen anderen Kubernetes-Cluster verweist, verwendest du den Befehl:

kubectl config use-context [my-cluster-name]

Alle Befehle, die über kubectl ausgegeben werden, sollten nun an den Cluster weitergeleitet werden, den wir zuvor mit der ID [my-cluster-name].

Verwendung von kubectl

Gewöhnen wir uns an die Verwendung von kubectl, indem wir ein paar Befehle ausprobieren, um Informationen aus dem Cluster zu erhalten, wie zum Beispiel die folgenden:

  • Die aktuell laufenden Dienste
  • Die Cluster-Informationen
  • Die aktuell laufenden Aufträge

Dienste zum Laufen bringen

Um zu bestätigen, dass unser Cluster betriebsbereit ist und die Komponenten laufen, versuche den folgenden Befehl:

kubectl -n kubeflow get services

Es sollte eine Liste der Komponenten angezeigt werden, die mit den Komponenten übereinstimmen, die wir gerade in unserem Cluster installiert haben (siehe Beispiel 4-1).

Beispiel 4-1. Liste der Dienste aus der Kommandozeile
NAME                                          TYPE        PORT(S)             AGE
admission-webhook-service                     ClusterIP   443/TCP             2d6h
application-controller-service                ClusterIP   443/TCP             2d6h
argo-ui                                       NodePort    80:30643/TCP        2d6h
centraldashboard                              ClusterIP   80/TCP              2d6h
jupyter-web-app-service                       ClusterIP   80/TCP              2d6h
katib-controller                              ClusterIP   443/TCP,8080/TCP    2d6h
katib-db-manager                              ClusterIP   6789/TCP            2d6h
katib-mysql                                   ClusterIP   3306/TCP            2d6h
katib-ui                                      ClusterIP   80/TCP              2d6h
kfserving-controller-manager-metrics-service  ClusterIP   8443/TCP            2d6h
kfserving-controller-manager-service          ClusterIP   443/TCP             2d6h
kfserving-webhook-server-service              ClusterIP   443/TCP             2d6h
metadata-db                                   ClusterIP   3306/TCP            2d6h
metadata-envoy-service                        ClusterIP   9090/TCP            2d6h
metadata-grpc-service                         ClusterIP   8080/TCP            2d6h
metadata-service                              ClusterIP   8080/TCP            2d6h
metadata-ui                                   ClusterIP   80/TCP              2d6h
minio-service                                 ClusterIP   9000/TCP            2d6h
ml-pipeline                                   ClusterIP   8888/TCP,8887/TCP   2d6h
ml-pipeline-ml-pipeline-visualizationserver   ClusterIP   8888/TCP            2d6h
ml-pipeline-tensorboard-ui                    ClusterIP   80/TCP              2d6h
ml-pipeline-ui                                ClusterIP   80/TCP              2d6h
mysql                                         ClusterIP   3306/TCP            2d6h
notebook-controller-service                   ClusterIP   443/TCP             2d6h
profiles-kfam                                 ClusterIP   8081/TCP            2d6h
pytorch-operator                              ClusterIP   8443/TCP            2d6h
seldon-webhook-service                        ClusterIP   443/TCP             2d6h
tensorboard                                   ClusterIP   9000/TCP            2d6h
tf-job-operator                               ClusterIP   8443/TCP            2d6h

So können wir feststellen, welche Dienste, die wir bereitgestellt haben, gerade laufen.

Cluster-Informationen abrufen

Wir können den Status des laufenden Clusters mit dem Befehl überprüfen:

kubectl cluster-info

Wir sollten eine ähnliche Ausgabe wie in Beispiel 4-2 sehen.

Beispiel 4-2. kubectl cluster-info Ausgabe
Kubernetes master is running at https://172.17.0.3:8443
KubeDNS is running at https://172.17.0.3:8443/api/v1/namespaces/kube-system...

To further debug and diagnose cluster problems, use kubectl cluster-info dump.

Laufende Aufträge erhalten

Normalerweise führen wir einen Auftrag, der auf einer YAML-Datei basiert, mit dem Befehl kubectl aus:

kubectl apply -f https://github.com/pattersonconsulting/tf_mnist_kubflow_3_5...

Der Auftrag sollte jetzt auf dem Kubeflow-Cluster ausgeführt werden. Wir werden nicht sehen, dass der Job läuft und in unsere Konsole schreibt, weil er auf einem entfernten Cluster läuft. Wir können den Status des Auftrags mit dem Befehl überprüfen:

kubectl -n kubeflow get pod

Unsere Konsolenausgabe sollte in etwa wie in Beispiel 4-3 aussehen.

Beispiel 4-3. kubectl-Ausgabe für aktuell laufende Aufträge
NAME                                              READY  STATUS     RESTARTS  AGE
admission-webhook-deployment-f9789b796-95rfz      1/1    Running    0         2d6h
application-controller-stateful-set-0             1/1    Running    0         2d6h
argo-ui-59f8d49b9-52kn8                           1/1    Running    0         2d6h
centraldashboard-6c548fc6dc-pzskh                 1/1    Running    0         2d6h
jupyter-web-app-deployment-657bf476db-v2xgl       1/1    Running    0         2d6h
katib-controller-5c976769d8-fcxng                 1/1    Running    1         2d6h
katib-db-manager-bf77df6d6-dgml5                  1/1    Running    0         2d6h
katib-mysql-7db488768f-cgcnj                      1/1    Running    0         2d6h
katib-ui-6d7fbfffcb-t84xl                         1/1    Running    0         2d6h
kfserving-controller-manager-0                    2/2    Running    1         2d6h
metadata-db-5d56786648-ldlzq                      1/1    Running    0         2d6h
metadata-deployment-5c7df888b9-gdm5n              1/1    Running    0         2d6h
metadata-envoy-deployment-7cc78946c9-kcmt4        1/1    Running    0         2d6h
metadata-grpc-deployment-5c8545f76f-7q47f         1/1    Running    0         2d6h
metadata-ui-665dff6f55-pbvdp                      1/1    Running    0         2d6h
minio-657c66cd9-mgxcd                             1/1    Running    0         2d6h
ml-pipeline-669cdb6bdf-vwglc                      1/1    Running    0         2d6h
ml-pipeline-ml-pipeline-visualizationserver...    1/1    Running    0         2d6h
ml-pipeline-persistenceagent-56467f8856-zllpd     1/1    Running    0         2d6h
ml-pipeline-scheduledworkflow-548b96d5fc-xkxdn    1/1    Running    0         2d6h
ml-pipeline-ui-6bd4778958-bdf2x                   1/1    Running    0         2d6h
ml-pipeline-viewer-controller-deployment...       1/1    Running    0         2d6h
mysql-8558d86476-xq2js                            1/1    Running    0         2d6h
notebook-controller-deployment-64b85fbc84...      1/1    Running    0         2d6h
profiles-deployment-647448c7dd-9gnz4              2/2    Running    0         2d6h
pytorch-operator-6bc9c99c5-gn7wm                  1/1    Running    30        2d6h
seldon-controller-manager-786775d4d9-frq9l        1/1    Running    0         2d6h
spark-operatorcrd-cleanup-xq8zb                   0/2    Completed  0         2d6h
spark-operatorsparkoperator-9c559c997-mplrh       1/1    Running    0         2d6h
spartakus-volunteer-5978bf56f-jftnh               1/1    Running    0         2d6h
tensorboard-9b4c44f45-frr76                       0/1    Pending    0         2d6h
tf-job-operator-5d7cc587c5-tvxqk                  1/1    Running    33        2d6h
workflow-controller-59ff5f7874-8w9kd              1/1    Running    0         2d6h

Da ein TensorFlow-Auftrag als Erweiterung des TensorFlow-Operators ausgeführt wird, wird er als Pod neben den anderen Kubeflow-Komponenten angezeigt.

Docker verwenden

Docker ist das am weitesten verbreitete Containersystem, das in Container-Orchestrierungssystemen wie Kubernetes verwendet wird. Um einen Container zu starten, führen wir ein Image aus. Ein Image enthält alles, was zum Ausführen einer Anwendung benötigt wird (Code, Laufzeit, Bibliotheken usw.) als ausführbares Image. Im Fall unseres TensorFlow-Auftrags enthält es z. B. die Abhängigkeiten der TensorFlow-Bibliotheken und unseren Python-Trainingscode, der in jedem Container ausgeführt wird.

Docker Hub bietet ein Repository, in dem Container-Images gespeichert, durchsucht und abgerufen werden können. Andere Repositories sind die Container Registry von Google und die Artifactory-Installationen vor Ort.

Grundlegende Docker-Installation

Wie du Docker installierst, erfährst du auf der Dokumentationsseite für den Prozess.

Für den Rest dieses Kapitels gehen wir davon aus, dass du Docker installiert hast. Kommen wir nun zu einigen grundlegenden Docker-Befehlen, die du kennen musst.

Grundlegende Docker-Befehle

Einzelheiten zur Verwendung des Befehls build findest du auf der Docker-Dokumentationsseite.

Der folgende Befehl erstellt das Bild aus dem dockerfile, das im lokalen Verzeichnis enthalten ist, und gibt ihm das Tag [account]/[repository]:[tag]:

docker build -t "[account]/[repository]:[tag]" .

Um den Container, den wir mit diesem Docker-Befehl gebaut haben, zu pushen, verwenden wir einen Befehl der folgenden Form:

docker push [account]/[repository]:[tag]

Der folgende Befehl nimmt das Container-Image, das wir im vorherigen Schritt erstellt haben, und pusht es in das mike -Konto in Artifactory unter dem Kubeflow-Repo. Außerdem fügt er das Tag dist_tf_estimator hinzu.

docker push mike/kubeflow:dist_tf_estimator

Jetzt wollen wir TensorFlow-Container mit Docker bauen.

Docker verwenden, um TensorFlow Container zu bauen

Wenn du Docker Container-Images auf der Grundlage bestehender TensorFlow Container-Images erstellst, solltest du Folgendes beachten:

  • Die gewünschte TensorFlow Version
  • Ob das Container-Image Python2- oder Python3-basiert sein wird
  • Ob das Container-Image CPU- oder GPU-Bindungen haben wird

Wir gehen hier davon aus, dass du entweder deinen eigenen TensorFlow-Container baust oder einen bestehenden Container von gcr.io oder Docker Hub verwendest. Im TensorFlow-Repository auf Docker Hub findest du einige tolle Beispiele für bestehende TensorFlow-Container-Images.

Container, GPUs und Python-Version

Informiere dich in jedem Container-Repository über die Benennungsregeln für Python 2 und Python 3, da diese von Repository zu Repository unterschiedlich sein können. Für GPU-Bindungen innerhalb des Container-Images musst du das richtige Basisbild mit dem Tag -gpu verwenden.

Fahren wir nun mit der Installation von Kubeflow über die Kommandozeile fort .

Grundlegender Installationsprozess

Der grundlegende Installationsprozess für Kubeflow ist folgender:

  1. Initialisiere Kubeflow-Artefakte.
  2. Passe alle Artefakte an.
  3. Verteile Kubeflow-Artefakte auf dem Cluster.

In den folgenden Abschnitten gehen wir auf die einzelnen Punkte ein.

Vor-Ort-Installation

Um Kubeflow vor Ort zu installieren, müssen wir die folgenden Punkte beachten:

  • Überlegungen zum Aufbau von Kubernetes-Clustern
  • Zugang des Gateway-Hosts zum Cluster
  • Active Directory Integration und Benutzerverwaltung
  • Kerberos-Integration
  • Lern- versus Produktionsumgebungen
  • Integration der Speicherung

Zu Beginn schauen wir uns verschiedene Möglichkeiten an, wie man Kubernetes-Cluster einrichtet.

Überlegungen zum Aufbau von Kubernetes-Clustern

Um zu erörtern, wie wir unsere Kubeflow-Installation vor Ort einrichten wollen, sehen wir uns noch einmal das Diagramm an, das zeigt, wie Cluster in logische Schichten unterteilt werden(Abbildung 4-1).

Abbildung 4-1. Optionen für die Produktionsumgebung von Kubernetes-Clustern (Quelle: Kubernetes-Dokumentation)

Kubeflow befindet sich in der Anwendungsschicht unseres Clusters und wir werden es als eine Reihe von langlebigen Pods und Diensten installieren.

Kubernetes Glossar

Bei Kubernetes gibt es viele Begriffe und Konzepte, die du kennen musst. Wenn du mal verwirrt bist, schau einfach im standardisierten Kubernetes-Glossar in der Dokumentation auf der Website des Kubernetes-Projekts nach.

Vor diesem Hintergrund verstehen wir, dass wir Kubeflow auf einem bestehenden Kubernetes-Cluster installieren müssen. Der Ort, an dem sich Dinge wie die Kontrollebene und die Cluster-Infrastruktur befinden, kann große Auswirkungen auf die Installationsentscheidungen haben, z. B:

  • Netzwerktopologien
  • Active Directory Integration
  • Kerberos-Integration

Schauen wir uns genauer an, was bei der Einrichtung eines Gateway-Hosts für den Zugang zu unserem Cluster zu beachten ist.

Gateway Host Zugriff auf Kubernetes Cluster

In den meisten gemeinsam genutzten, mandantenfähigen Unternehmenssystemen gibt es einen Gateway-Host, der für den Zugang zum Cluster verwendet wird. Für die Installation von Kubeflow auf einem Kubernetes-System muss dein Cluster wahrscheinlich nach demselben Muster eingerichtet werden.

Normalerweise benötigt der Gateway-Host-Rechner die folgenden Ressourcen:

  • Netzwerkzugang zum Kubernetes-Cluster
  • kubectl lokal installiert und konfiguriert

Der Netzwerkzugang zum Kubernetes-Cluster, in dem sich Kubeflow befindet, ist erforderlich, da wir den Zugang für kubectl benötigen, um Befehle über das Netzwerk zu senden. Es gibt Varianten, bei denen die Container auf einem Rechner erstellt werden, der nicht der Gateway-Host ist, aber das hängt in der Regel davon ab, wie deine IT-Abteilung die Dinge einrichtet.

Es ist völlig in Ordnung, wenn ein Gateway-Host ein lokaler Rechner ist, der diese Anforderungen erfüllt .

Active Directory Integration und Benutzerverwaltung

In den meisten Unternehmen werden die Benutzer über eine Active Directory-Installation verwaltet. Die meisten Unternehmenssoftwaresysteme müssen mit dieser Active Directory-Installation integriert werden, damit die Benutzer Systeme wie Kubernetes oder Kubeflow nutzen können.

Schauen wir uns zunächst an, wie ein typischer Benutzer in einem Unternehmen auf einen mit Active Directory integrierten Kubernetes-Cluster zugreift.

Kubernetes, kubectl und Active Directory

Um auf einen Kubernetes-Cluster zugreifen zu können, müssen die Nutzer/innen in der Regel bei ihrem IT-Team im Unternehmen einen formellen Antrag auf Zugriff auf den Cluster stellen. Nachdem der Genehmigungsprozess erfolgreich abgeschlossen wurde, werden die Nutzer/innen der entsprechenden Active Directory-Gruppe für den Zugriff auf den Cluster hinzugefügt.

Die Nutzer greifen auf den Gateway-Host zu (der wiederum ihr lokaler Rechner sein kann), indem sie eine Reihe von Anmeldedaten verwenden und sofort nach dem Einloggen mit den allgemeinen Anmeldedaten ein Kerberos-Ticket erhalten. Dieses Ticket kann später verwendet werden, um sich beim Kubernetes-Cluster zu authentifizieren.

Die notwendigen Binärdateien (kubectl und Plug-ins - wie wir im folgenden Text erwähnen) sowie die erforderliche kubeconfig (Kubernetes-Konfiguration) müssen von den Nutzern konfiguriert werden. Sobald kubeconfig konfiguriert ist, müssen sich die Nutzer nur noch darum kümmern, die entsprechenden kubectl Befehle auszuführen.

Kerberos-Integration

IT-Teams in Unternehmen verwenden Kerberos in der Regel als Netzwerk-Authentifizierungsprotokoll, da es für Client/Server-Anwendungen (wie Kubernetes-Knoten) entwickelt wurde, um eine starke Authentifizierung mit Hilfe von Secret-Key-Kryptografie zu ermöglichen. Wie auf der Kerberos-Website beschrieben:

Kerberos wurde vom MIT als Lösung für diese Netzwerksicherheitsprobleme entwickelt. Das Kerberos-Protokoll nutzt starke Kryptografie, damit ein Client seine Identität gegenüber einem Server (und umgekehrt) über eine unsichere Netzwerkverbindung nachweisen kann. Nachdem ein Client und ein Server ihre Identität mit Kerberos nachgewiesen haben, können sie auch ihre gesamte Kommunikation verschlüsseln, um den Datenschutz und die Datenintegrität bei der Arbeit zu gewährleisten.

Standardmäßig bietet Kubernetes keine Methode zur direkten Integration mit Kerberos, da es auf einen moderneren Ansatz - OpenID Connect, kurz OIDC - setzt.

Eine Methode, Kerberos mit Kubernetes zu nutzen, besteht darin, ein bestehendes Kerberos-Ticket gegen ein OIDC-Token auszutauschen und dieses Token bei der Authentifizierung an Kubernetes zu übergeben. Dazu musst du dich zunächst bei einem OIDC-Token-Anbieter mit einem bestehenden Kerberos-Berechtigungsnachweis authentifizieren und erhältst im Austausch für die Kerberos-Authentifizierung ein OIDC-Token. Dies kann mithilfe eines kubectl Plug-ins geschehen, ein Beispiel findest du hier.

Integration der Speicherung

Kubeflow hat keine Vorstellung von einem bestimmten Datenspeicher und überlässt es dem zugrunde liegenden Kubernetes-Cluster, welche Speicheroptionen verfügbar sind.

Beim Einrichten unserer Kubeflow-Installation und beim Ausführen von Aufträgen müssen wir einiges beachten:

  • Welche Art von Speicherung unser Cluster zur Verfügung hat
  • Datenzugriffsmuster, die für unsere Arbeit am besten geeignet sind
  • Sicherheitsüberlegungen rund um den Datenspeicher

Die Art und Weise, wie wir Daten speichern, ist eng mit dem Datenzugriff verknüpft. Deshalb müssen wir bei der Planung unserer Speicherung berücksichtigen, wie wir auf die Daten zugreifen. Die Auftragsarten, die wir im Hinblick auf unsere Datenzugriffsmuster betrachten, sind:

  • Python (oder anderer) Code in einem einzigen Container, der auf Kubernetes läuft
  • Ein Container wird auf einem bestimmten Kubeflow-Operator (z. B. TFOperator oder PyTorchOperator) in normaler Einzelknotenausführung oder im verteilten Modus ausgeführt
  • Python-Code aus einem Jupyter Notebook ausführen

Bei diesen drei Job-Varianten gibt es zwei Aspekte zu beachten:

  • Stellen wir dem Job genug Bandbreite zur Verfügung, damit wir die Modellierungsleistung des laufenden Codes nicht aushungern?
  • Erfolgt die Integration mit der Speicherung über die Semantik des Dateisystems oder über Netzwerkaufrufe?

Schauen wir uns zunächst die Auftragsbandbreite und Speicherung für Kubeflow-Aufträge an.

Nachdenken über die Bandbreite von Kubeflow-Aufträgen

Wenn du dich erinnerst, haben wir in Kapitel 2 darüber gesprochen, wie sich GPUs auf Aufträge auswirken können, von einzelnen GPUs über Multi-GPUs bis hin zu verteilten GPUs. GPUs können sehr datenhungrig sein, daher ist ein extrem schnelles Speichersubsystem entscheidend. Wir wollen nicht, dass die GPUs auf Daten warten müssen.

Wenn ein Auftrag mit vielen Daten trainiert wird, kann man davon ausgehen, dass er eine Speicherung mit hoher Bandbreite benötigt, die den Anforderungen der GPUs gerecht wird. Wenn ein Auftrag hingegen sehr rechenintensiv ist, ohne einen kleineren Datensatz, ist die Geschwindigkeit, mit der die GPUs die Ausgangsdaten erhalten, vielleicht nicht so wichtig. Im letzteren Fall kann man von einem Auftrag mit geringerer Bandbreite sprechen.

Gemeinsame Muster für den Zugriff auf die Speicherung mit Kubeflow-Aufträgen

Es gibt zwei wichtige Möglichkeiten, wie Kubeflow-Aufträge auf die Speicherung zugreifen:

  • Verwendung von Netzwerkanrufen über das Netzwerk oder Internet
  • Dateisystem-Semantik verwenden

Wenn der Auftrag Daten über das Netzwerk/Internet mit den eigenen Anmeldeinformationen des Benutzers abruft (die wir gerne irgendwo in der Konfiguration/im Code hinterlegen), müssen wir uns auf Kubernetes-Ebene keine Gedanken über Dateisystem-Semantiken und Einhängepunkte für Kubernetes machen.

In diesem Fall verarbeitet der Code alle Netzwerkaufrufe, um die Daten lokal abzurufen, aber die Hosts unseres Clusters benötigen eine externe Netzwerkverbindung. Solche Beispiele könnten der Zugriff auf die Speicherung von S3, SFTP, Drittanbietersystemen usw. sein.

Wenn du einen lokalen Einhängepunkt verwenden möchtest, um auf eine Partition der Daten zuzugreifen (z. B. ähnlich wie ein lokales Dateisystem von Python und Notebooks auf einem lokalen Laptop verwendet wird), musst du die Speicherung mithilfe von persistenten Volume Claims (PVCs) auf der Kubernetes Pod- und Container-Ebene bereitstellen.

Optionen für die Kubeflow Speicherung

Kubernetes selbst bietet eine Vielzahl von Mechanismen für die Speicherung, die du hier nachlesen kannst. Auf der grundlegendsten Ebene kann man sich die Speicherung als lokal angeschlossenen Speicher auf einem bestimmten Kubernetes-Worker-Node vorstellen (z. B. ein lokal angeschlossenes und ephemeres Volume) oder als eine Schicht persistenten Speichers, die normalerweise von einem Speichersubsystem bereitgestellt wird.

Im Zusammenhang mit Kubeflow wird ein Hochgeschwindigkeits-Subsystem für die Speicherung bevorzugt, z. B. ein Speicher-Array mit Glasfaseranschluss. Dies bietet eine konsistente Speicherung mit hoher Bandbreite, die den Anforderungen der GPUs gerecht wird.

Einige Beispiele für solche Systeme mit hoher Bandbreite sind :

  • NetApp AFFA800
  • Cisco FlexPod
  • FlashBlade

In den Kapiteln 5 bis 7 stellen wir die wichtigsten Speichersysteme für verwaltete Kubernetes für die öffentlichen Clouds genauer vor.

Persistente Volumenansprüche und Kubeflow Speicherung

Kubeflow verwendet standardmäßig persistente Volumes (PVs) und persistente Volume Claims (PVCs) für seine Speicherung. Wenn ein Nutzer beispielsweise einen Notebook-Server einrichtet, hat er die Möglichkeit, die Speicherung dynamisch zuzuweisen (aus einer Speicherklasse) oder einen vorhandenen persistenten Volume-Anspruch zu verwenden.

Der wichtigste Unterschied zwischen PVs und PVCs besteht darin, dass ein PV einfach eine Darstellung von Speicherplatz "irgendwo" ist, z. B. ein zugewiesener "1 GB Speicherplatz". Um diesen Speicherplatz tatsächlich zu nutzen, muss ein Anspruch auf diese Speicherung erhoben werden. Sobald ein Anspruch erhoben wurde, garantiert Kubernetes, dass die zugrunde liegende Speicherung für die Dauer des Anspruchs nicht freigegeben wird. Im Zusammenhang mit Kubernetes reicht es also nicht aus, nur eine PV zu haben, sondern es muss auch eine PVC für diese Speicherung erworben werden.

Wenn ein Nutzer dynamisch Speicherung bereitstellt, erstellt Kubeflow automatisch eine PVC für die neu zugewiesene Speicherung, die später für verschiedene Pods, Notebooks usw. verwendet und wiederverwendet werden kann. Wenn ein Nutzer beim Einrichten einer Kubeflow-Umgebung, z. B. eines Notebooks, eine bestehende PVC bereitstellen möchte, wird Kubeflow die PVC zur Verfügung gestellt (und nicht die PV selbst).

Container Management und Artefakt Repositories

Die Container-Verwaltung ist der Schlüssel zu Kubeflow und Kubernetes (oder jedem anderen Container-Orchestrierungssystem), denn wir brauchen einen Ort, an dem Container-Images untergebracht werden können.

Wir sollten uns hier klar machen, wie sich Container-Images von Konfigurationsdateien (z. B. Dockerfiles) unterscheiden, die Container-Images definieren. Wir können unsere Konfigurationsdateien (Dockerfiles) in ein Source-Control-Repository wie github.com stellen, aber wir brauchen ein anderes Repository, um die binären Artefakte der Anwendung (z. B. Container-Images) zu verwalten.

Konkret brauchen wir einen Ort, an dem wir alle Container-Images unserer Anwendungen speichern und verwalten können, um sie später in Kubernetes einzusetzen.

Es gibt zwei Arten von Artefakt-Repositories für Container-Images:

  • Öffentliche Container-Image Repositories (oder Registries)
  • Private (und vielleicht lokale) Container-Image-Repositories (oder Registries)

Öffentliche Repositories/Registries sind in der Regel über das Internet zugänglich und ermöglichen es jedem, deine Container zu sehen (zumindest auf der kostenlosen Ebene). Das beliebteste öffentliche Repository für Artefakte ist hub.docker.com, auch bekannt als Docker Hub.

Private Repositories/Register können auch im Internet oder vor Ort gehostet werden. Die Details und die Umsetzung der Erstellung und Verwaltung von privaten Repositories und Registern hängen von der jeweiligen Implementierung ab.

Für Kubeflow ist es wichtig zu verstehen, dass alle Container-Images irgendwo aus einem Container-Repository bezogen werden müssen. Standardmäßig ist Kubeflow so vorkonfiguriert, dass es alle Container-Images von der Google Container Registry (gcr.io) bezieht. Kubeflow bietet einen Mechanismus, um den Ort der Container-Registry festzulegen.

Einrichten eines internen Container-Repositorys

JFrog Artifactory OSS ist eine Open-Source-Option für eine On-Premise-Registry für Container-Anwendungen (es gibt auch kommerzielle Upgrades für die Open-Source-Version).

Um Artifactory herunterzuladen (oder ein Docker-Image zu erhalten), besuche ihre Website. Wie du Artifactory vor Ort installierst, findest du in der Confluence-Dokumentation. Artifactory bietet Unterstützung für:

  • Solaris
  • MacOS
  • Windows
  • Linux

Zu den Abhängigkeiten von Artifactory gehören eine lokale Datenbank (Standard ist eine eingebettete Derby-Datenbank), ein Dateispeicher (Standard ist ein lokaler FS) und die Integration mit einem HTTP-Server.

Zugriff auf und Interaktion mit Kubeflow

Es gibt zwei Hauptwege, um mit Kubeflow zu arbeiten:

  • Das CLI, vor allem mit dem Tool kubectl, sowie das Tool kfctl
  • Mit einem Webbrowser, unter Verwendung der Kubeflow Web UI

In den nächsten Unterabschnitten gehen wir auf die einzelnen Punkte ein.

Es ist wichtig, sich vor Augen zu halten, dass die Kubeflow-Verwaltungsvorgänge - wie die Bereitstellung einer Kubeflow-Installation, die Aktualisierung von Kubeflow-Komponenten usw. - mit dem Tool kfctl durchgeführt werden, während du mit dem Tool kubectl siehst, was der Cluster gerade "tut".

Allgemeine Befehlszeilenoperationen

kubectl ist das grundlegende Werkzeug, das uns für die Kommandozeilenoptionen von Kubeflow interessiert. In einem früheren Abschnitt dieses Kapitels haben wir einige der wichtigsten Dinge besprochen, die wir auf einem Kubernetes-basierten Cluster mit tun können. Die relevanten Vorgänge in Kubeflow, für die wir uns mit interessieren, sind: kubectl kubectl

  • Einen einfachen Container mit etwas Code, typischerweise Python, auf unserem Cluster laufen lassen
  • Ausführen einer Gruppe von Containern mit einem speziellen Kubernetes-Operator wie TFJob

Im ersten Fall haben unsere Praktiker oft Python-Code, den sie gerne auf GPUs ausführen würden. In diesen Fällen erstellen wir einen Container mit den entsprechenden Abhängigkeiten und lassen ihn auf unserem Kubernetes-Cluster mit Kubeflow laufen.

Im zweiten Fall müssen wir unsere Job-YAML-Datei so einrichten, dass sie einen gezielten Kubernetes-Kundenoperator wie TFJob angibt, damit wir spezielle Container-Koordinationsmodi wie das verteilte Training von TensorFlow nutzen können.

Barrierefreie Web-UIs

Die wichtigste Web-Ressource von Kubeflow ist das Kubeflow Dashboard UI, das Links zu allen anderen Web-Ressourcen von Kubeflow enthält. In Abbildung 4-2 siehst du, wie das Dashboard aussieht.

Wie in Kapitel 1 besprochen, ist dieses Dashboard quasi eine schnelle Tabelle für die anderen relevanten Ressourcen, die über einen Webbrowser für Kubeflow-Nutzer verfügbar sind.

Abbildung 4-2. Kubeflow UI

Installation von Kubeflow

In diesem Abschnitt gehen wir auf die Schritte ein, die für die Installation von Kubeflow erforderlich sind.

Systemanforderungen

Zum Zeitpunkt der Erstellung dieses Artikels muss der Kubernetes-Cluster die folgenden Mindestanforderungen erfüllen:

  • 4 CPUs
  • 50 GB Speicherung
  • 12 GB Speicher

Die empfohlene Kubernetes-Version ist 1.14. Kubeflow wurde auf Kubernetes 1.14 validiert und getestet. Auf deinem Cluster muss mindestens Kubernetes Version 1.11 laufen, und Kubeflow funktioniert nicht mit Kubernetes 1.16.

Einrichten und Bereitstellen

Die Installation von Kubeflow erfordert diese Schritte:

  1. Lade das Tool kfctl herunter.
  2. Bereite die Kubeflow-Artefakte vor.
  3. Setze die Artefakte in einem Cluster ein.

Auf einem kompatiblen System (z.B. Linux oder macOS) erhältst du das Tool kfctl, indem du es von den Kubeflow-Releaseseiten auf GitHub herunterlädst. Siehe Beispiel 4-4.

Beispiel 4-4. Herunterladen und Entpacken der kfctl-Binärdatei1
$ cd ~/bin
$ curl -LOJ https://github.com/.../kfctl_v1.0.2-0-ga476281_linux.tar.gz
$ tar zxvf kfctl_v1.0.2-0-ga476281_linux.tar.gz

Sobald das Tool heruntergeladen wurde, wird ein Arbeitsverzeichnis erstellt, in dem die Artefakte und alle Anpassungen für Kubeflow gespeichert werden. In Beispiel 4-5 verwenden wir das Verzeichnis kf im Heimatverzeichnis des Benutzers (~/kf).

Beispiel 4-5. Arbeitsverzeichnis erstellen
$ mkdir ~/kf
$ cd ~/kf

Wir sind noch nicht bereit, die Kubeflow-Installation vorzubereiten. Dazu geben wir ein erstes Manifest an, das wir herunterladen und vorbereiten, wie in Beispiel 4-6.

Beispiel 4-6. Kubeflow-Installation vorbereiten2
$ cd ~/kf
$ ~/bin/kfctl build -V -f "https://raw.githubusercontent.com/..."

Dadurch wird ein Verzeichnis kustomize erstellt, das alle Templates enthält, die Kubeflow bereitstellt. In diesem Stadium können alle zusätzlichen Anpassungen vorgenommen werden.

Um zum Beispiel eine benutzerdefinierte Container-Registry zu verwenden, können wir das Tool kfctl verwenden. Mit dem Befehl in Beispiel 4-7 wird die Standard-Container-Registry von gcr.io auf hub.docker.com geändert.

Beispiel 4-7. Einrichten einer benutzerdefinierten Container-Registrierung
$ ~/bin/kfctl alpha set-image-name hub.docker.com

Sobald wir bereit sind, kann Kubeflow mit dem Befehl kfctl apply eingesetzt werden, wie in Beispiel 4-8 zu sehen ist.

Beispiel 4-8. Kubeflow bereitstellen
$ ~/bin/kfctl apply -V -f kfctl_istio_dex.v1.0.2.yaml

Kubernetes-Kontext

Denke daran, dass Kubeflow den Standard-Kubernetes-Kontext verwendet und dieser bestimmt, in welchem Kubernetes-Cluster Kubeflow installiert wird .

Zusammenfassung

In diesem Kapitel haben wir uns die praktischen Schritte für den Einsatz von Kubeflow vor Ort angesehen. Auch wenn viele Nutzer in die Cloud wechseln wollen (wie wir in den nächsten Kapiteln zeigen werden), sind Installationen vor Ort für viele Unternehmen immer noch relevant. Im nächsten Kapitel werden wir sehen, wie wir auf vielen der in diesem Kapitel vorgestellten Konzepte aufbauen und die Installation für einen Cloud-Einsatz weiterentwickeln können.

1 Die URL wurde hier aus Platzgründen gekürzt; die vollständige URL ist https://github.com/kubeflow/kfctl/releases/download/v1.0.2/kfctl_v1.0.2-0-ga476281_linux.tar.gz.

2 Die URL wurde hier aus Platzgründen gekürzt; die vollständige URL ist https://raw.githubusercontent.com/kubeflow/manifests/v1.0-branch/kfdef/kfctl_istio_dex.v1.0.2.yaml.

Get Kubeflow Betriebsanleitung now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial