Diese Seite wurde von der Cloud Translation API übersetzt.

Batcharbeitslast für maschinelles Lernen bereitstellen

In dieser Anleitung wird gezeigt, wie Sie mit Google Kubernetes Engine (GKE) fehlertolerante Batcharbeitslasten verwalten und gleichzeitig Ihre Kosten niedrig halten. In dieser Anleitung wird die Verwendung von Jobs und kostenoptimierten Spot-Pods sowie die Konfiguration eines In-ClustersRedis-Jobwarteschlange in GKE beschrieben.

Hintergrund

Eine Batcharbeitslast ist ein Prozess, der in der Regel aus einem Start- und einem Abschlusspunkt besteht. Sie sollten Batch-Arbeitslasten in GKE in Betracht ziehen, wenn Ihre Architektur Daten aufnimmt, verarbeitet und ausgibt, anstatt Rohdaten zu verwenden. Bereiche wie maschinelles Lernen, künstliche Intelligenz und Hochleistungs-Computing bieten verschiedene Arten von Batcharbeitslasten, z. B. Offline-Modelltraining, Batchvorhersage, Datenanalyse, Simulation physischer Systeme und Video-Verarbeitung.

Durch das Entwerfen von containerisierten Batcharbeitslasten können Sie die folgenden GKE-Vorteile nutzen:

Eine umfassende Community mit offenem Standard und ein verwalteter Dienst.
Kosteneffizienz durch effektive Orchestrierung von Arbeitslasten und Infrastrukturen sowie spezielle Computing-Ressourcen.
Isolation und Portabilität der Containerisierung, wodurch die Nutzung der Cloud als Überlaufkapazität bei gleichzeitiger Wahrung der Datensicherheit ermöglicht wird.
Verfügbarkeit der Burst-Kapazität gefolgt von einer schnellen Herunterskalierung von GKE-Clustern.

Umgebung vorbereiten

Klonen Sie das in dieser Anleitung verwendete Beispiel-Repository:

git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
cd kubernetes-engine-samples/batch/aiml-workloads

Erstellen Sie einen GKE Autopilot-Cluster:
```
gcloud container clusters create-auto batch-aiml \
    --location=us-central1
```
Dieser Schritt kann bis zu fünf Minuten dauern.

Dataset-Speicher mit einem Netzwerk-Dateisystem (NFS) einrichten

Die Arbeitslast für maschinelles Lernen erfordert eine Speicherlösung für die Datasets und Ausgabedateien. In diesem Abschnitt erstellen Sie eine Filestore-Instanz und gewähren Zugriff auf die Instanz mithilfe eines PersistentVolume und eines PersistentVolumeClaim.

Weitere Informationen finden Sie unter Optimale Speicherstrategie entwerfen und Auf Filestore-Instanzen von GKE-Clustern aus zugreifen.

Filestore-Instanz erstellen

Filestore-Instanz erstellen:
```
gcloud filestore instances create batch-aiml-filestore \
    --zone=us-central1-b \
    --tier=BASIC_HDD \
    --file-share=name="NFSVol",capacity=1TB \
    --network=name="default"
```
Dieser Befehl gibt die folgenden Optionen an:
- tier: Die Dienststufe für die Filestore-Instanz. In diesem Beispiel wird die Basis-Stufe verwendet. Informationen zu den anderen Optionen finden Sie unter Dienststufen.
- network=name: Der Name des VPC-Netzwerks (Virtual Private Cloud) für die Filestore-Instanz. Der GKE-Cluster muss sich im selben VPC-Netzwerk wie die Filestore-Instanz befinden.
- capacity: Die gewünschte Größe des Volumes. Geben Sie den Speicherwert in einer der unterstützten Einheiten an, die unter Ressourcenmengen beschrieben sind.
Hinweis: Dieser Schritt kann bis zu fünf Minuten dauern.

Prüfen Sie, ob die Filestore-Instanz bereitgestellt wurde:

gcloud filestore instances list \
    --project=PROJECT_ID \
    --zone=us-central1-b

Ersetzen Sie PROJECT_ID durch Ihre Google CloudProjekt-ID.

Die Ausgabe sieht etwa so aus:

INSTANCE_NAME: batch-aiml-filestore
LOCATION: us-central1-b
TIER: BASIC_HDD
CAPACITY_GB: 1024
FILE_SHARE_NAME: NFSVol
IP_ADDRESS: 203.0.113.54
STATE: READY
CREATE_TIME: 2022-03-15T18:23:51

Notieren Sie sich den Wert im Feld IP_ADDRESS, da er im folgenden Abschnitt verwendet werden soll.

PersistentVolume erstellen

Eine Kubernetes-PersistentVolume-Spezifikation ermöglicht dem GKE-Cluster, eine Verbindung zur Filestore-Instanz herzustellen.

Aktualisieren Sie die Datei kubernetes-manifests/persistent-volume.yaml mit der IP-Adresse der Filestore-Instanz:
```
sed -i "\
  s/<FILESTORE_IP_ADDRESS>/IP_ADDRESS/g" \
  kubernetes-manifests/persistent-volume.yaml
```
Ersetzen Sie IP_ADDRESS durch die IP-Adresse, die Sie beim Erstellen der Filestore-Instanz im vorherigen Abschnitt notiert haben.

Stellen Sie das PersistentVolume bereit:

kubectl apply -f kubernetes-manifests/persistent-volume.yaml

PersistentVolumeClaim erstellen

Ein Kubernetes-PersistentVolumeClaim ermöglicht Kubernetes-Pods und -Jobs den Zugriff auf die Speicherressourcen eines PersistentVolume.

Stellen Sie den PersistentVolumeClaim bereit:

kubectl apply -f kubernetes-manifests/persistent-volume-claim.yaml

PersistentVolumeClaim nutzen

Wenn das PersistentVolume und der PersistentVolumeClaim im GKE-Cluster eingerichtet sind, können Sie den Redis-Server und die Batchjobs so konfigurieren, dass sie den PersistentVolumeClaim nutzen. Dies wird als bereitstellbares Speicher-Volume angezeigt.

Prüfen Sie die Dateien kubernetes-manifests/redis-pod.yaml und kubernetes-manifests/workload.yaml. Die Manifestkonfigurationen sehen in etwa so aus:

  spec:
  …
  containers:
  - name: workload
    image: "us-central1-docker.pkg.dev/gke-batch-aiml/batch-aiml-docker-repo/workload"
    volumeMounts:
    - mountPath: /mnt/fileserver
      name: workload-pvc
  volumes:
  - name: workload-pvc
    persistentVolumeClaim:
      claimName: fileserver-claim
      readOnly: false

In diesem Manifest:

spec.volumes gibt den zu nutzenden PersistentVolumeClaim an.
spec.containers.volumeMounts gibt den lokalen Dateipfad an, unter dem der Pod auf die Filestore-Dateifreigabe zugreifen kann.

Redis-Jobwarteschlange einrichten

Die Arbeitslast verarbeitet Daten in Batches, um iterativ ein Betrugserkennungsmodell zu trainieren. Zum Verwalten der aktuell verarbeiteten oder noch in der Warteschlange enthaltenen Datasets stellen Sie den Redis-Server im GKE-Cluster bereit.

Für diese Anleitung starten Sie eine einzelne Instanz von Redis. Informationen zur skalierbaren und redundanten Bereitstellung von Redis finden Sie unter Mehrstufige Webanwendung mit Redis und PHP erstellen.

Stellen Sie die Spezifikation des Redis-Servers bereit.

kubectl apply -f kubernetes-manifests/redis-pod.yaml

Prüfen Sie, ob der Pod ausgeführt wird:
```
kubectl get pods
```
Die Ausgabe sieht in etwa so aus:
```
NAME           READY   STATUS    RESTARTS   AGE
redis-leader   1/1     Running   0          118s
```
Es kann bis zu zwei Minuten dauern, bis der Pod ausgeführt wird.
Übertragen Sie die Dateien mit den Trainings- und Test-Datasets auf das NFS-Volume.
```
sh scripts/transfer-datasets.sh
```
Dieses Script kopiert die Dateien aus dem Beispielcode-Repository in das Verzeichnis /mnt/fileserver/datasets/ auf dem Pod redis-leader.
Füllen Sie die Redis-Warteschlange aus.
```
sh scripts/queue-jobs.sh
```
Dieses Script überträgt die Dateipfade für die Trainings-Datasets per Push in eine Liste mit dem Namen datasets in der Redis-Datenbank. Diese Warteschlange wird von der Arbeitslast verwendet, um das nächste zu verarbeitende Dataset zu ermitteln.
Stellen Sie den Dienst bereit, damit der Redis-Server im GKE-Cluster gefunden werden kann.
```
kubectl apply -f ./kubernetes-manifests/redis-service.yaml
```

Batch-Arbeitslast ausführen

Jetzt haben Sie den GKE-Cluster, die Redis-Jobwarteschlange und die Dateifreigabe vorbereitet. Jetzt können Sie Ihre Batch-Arbeitslast ausführen.

In diesem Abschnitt verwenden Sie ein Container-Image einer Beispielarbeitslast, um ein Betrugserkennungsmodell mithilfe von Batches an Finanztransaktionsdaten zu trainieren. Der Trainingsprozess kann so zusammengefasst werden:

Ein Redis-Client beansprucht Jobs (Dateipfade zu Datasets) in der Redis-Warteschlange und entfernt sie nach dem Abschluss aus der Warteschlange.
Die Modelltrainingadministratorklasse FraudDetectionModelTrainer lädt einen neuen Datenbatch und optional einen gespeicherten Zustand eines ML-Modells. Das Dataset wird zur Verfeinerung des Modells verwendet (ein Prozess, der als „Warmstart”-Training bezeichnet wird).
Der neue Status des Modells und ein Bericht der Batchdetails und Leistungspunktzahlen werden im Filestore-NFS-Volume gespeichert, auf das im GKE-Cluster mit einem PersistentVolumeClaim zugegriffen werden kann.

Weitere Informationen finden Sie wenn Sie Quellcode erkunden.

Job definieren

Das folgende Manifest beschreibt den Kubernetes-Job für das Batch-Arbeitslast-Image. Ein Jobcontroller in Kubernetes erstellt einen oder mehrere Pods und sorgt dafür, dass sie eine bestimmte Aufgabe erfolgreich ausführen.

apiVersion: batch/v1
kind: Job
metadata:
  name: workload
spec:
  parallelism: 1
  template:
    metadata:
      name: workload
    spec:
      nodeSelector:
        cloud.google.com/gke-spot: "true"
      containers:
      - name: workload
        image: "us-docker.pkg.dev/google-samples/containers/gke/batch-ml-workload"
        volumeMounts:
        - mountPath: /mnt/fileserver
          name: workload-pvc
      volumes:
      - name: workload-pvc
        persistentVolumeClaim:
          claimName: fileserver-claim
          readOnly: false
      restartPolicy: OnFailure

Arbeitslast bereitstellen

Stellen Sie den Job bereit:

kubectl apply -f ./kubernetes-manifests/workload.yaml

Prüfen Sie, ob der Pods workload-XXX den Status Completed hat:
```
watch kubectl get pods
```
Dies kann einige Sekunden dauern. Sie können zur Befehlszeile zurückkehren, indem Sie Ctrl+C drücken.

Die entsprechende Ausgabe sieht etwa so aus:
```
NAME             READY   STATUS      RESTARTS   AGE
redis-leader     1/1     Running     0          16m
workload-4p55d   0/1     Completed   0          83s
```
Prüfen Sie die Logs des Jobs workload:
```
kubectl logs job/workload
```
Die entsprechende Ausgabe sieht etwa so aus:
```
Worker with sessionID: b50f9459-ce7f-4da8-9f84-0ab5c3233a72
Initial queue state: empty=False
Processing dataset: datasets/training/2018-04-04.pkl
Processing dataset: datasets/training/2018-04-03.pkl
Processing dataset: datasets/training/2018-04-02.pkl
Processing dataset: datasets/training/2018-04-01.pkl
Queue empty, exiting
```
Die .pkl-Dateien sind Serialisierung von Datasets mit einem Batch von Kreditkartentransaktionen, die als gültig oder betrügerisch markiert sind. Der workload-Job durchläuft diese Dateien, entpackt die Datasets und verwendet sie zum Trainieren des Modells für maschinelles Lernen, bevor sie aus der Redis-Warteschlange entfernt werden. Die Arbeitslast verarbeitet die Daten weiterhin in Batches, bis die Redis-Warteschlange geleert wird, bevor sie erfolgreich beendet wird.

NFS-Volume ansehen

Während des Vorgangs erstellt die Arbeitslast Dateien im bereitgestellten NFS-Volume, auf die im Cluster durch andere Batchjobs oder Onlineanwendungen zugegriffen werden kann.

Listen Sie die von der Arbeitslast erstellten Dateien auf:
```
kubectl exec --stdin --tty redis-leader -- /bin/sh -c "ls -1 /mnt/fileserver/output"
```
Die Ausgabe sollte so aussehen:
```
model_cpt_2018-04-01.pkl
model_cpt_2018-04-02.pkl
model_cpt_2018-04-03.pkl
model_cpt_2018-04-04.pkl
report.txt
```
Prüfpunkte für das trainierte Modell (Dateinamen wie model_cpt_XXX.pkl) und ein Bericht zur Modellleistung (report.txt) wurden im Verzeichnis /mnt/fileserver/output auf dem NFS-Volume erstellt.

Sehen Sie sich den Modellleistungsbericht an:

kubectl exec --stdin --tty redis-leader -- /bin/sh -c "cat /mnt/fileserver/output/report.txt"

Folgendes ist ein Snippet aus der Ausgabe:

Report generated on: 2022-02-09 14:19:42.303619
Training dataset: 2018-04-04.pkl
Model checkpoint: model_cpt_2018-04-04.pkl
---
Accuracy on training data: 0.9981112277019937
Accuracy on testing data: 0.9977204434773599

Die Datei enthält Einträge, die die Zeit des Trainings, das verwendete Dataset, die erreichte Genauigkeit und den Dateinamen des mit dem Training assoziierten Modellprüfpunkts enthalten.

Weitere Informationen zu NFS-Volumes finden Sie in den Filestore-Leitfäden.