Volumes auf Kubernetes

Volumes bieten persistenten Speicher für Container innerhalb von Pods, sodass diese Daten zentral über mehrere Pods hinweg auf einer Festplatte lesen und schreiben können. Sie sind besonders im Bereich Machine Learning nützlich, wenn Sie Daten, Modelle und andere Artefakte speichern und darauf zugreifen müssen, die für Trainings-, Serving- und Inferenz-Aufgaben erforderlich sind.

In diesem Blog besprechen wir, wie Sie Volumes nutzen können und welche Optionen in der jeweiligen Cloud zur Verfügung stehen. 

Wann sollten Kubernetes Volumes verwendet werden?

Einige Anwendungsfälle, in denen sich Volumes als sehr nützlich erweisen:

1. Trainingsdaten teilen: Es ist möglich, dass mehrere Data Scientists mit denselben Daten trainieren oder dass wir mehrere Experimente parallel auf demselben Datensatz ausführen. Der naive Weg wäre, die Daten für jeden Data Scientist zu duplizieren – das würde uns jedoch deutlich mehr kosten. Ein effizienterer Weg besteht darin, die Trainingsdaten in einem Volume zu speichern und dieses Volume in den Notebooks der verschiedenen Data Scientists zu mounten.
2. Modellspeicherung: Wenn wir Modelle als Echtzeit-APIs hosten, gibt es mehrere Replikate des API-Servers, um den Traffic zu bewältigen. Hier muss jedes Replikat das Modell aus der Model Registry (z. B. S3) auf die lokale Festplatte herunterladen. Wenn jedes Replikat dies wiederholt tut, verlängert sich die Startzeit und es entstehen höhere S3-Zugriffskosten. Mithilfe von Volumes können Sie Ihre trainierten Modelle extern speichern und auf dem Inferenz-Server mounten. Das Modell muss nicht mehr heruntergeladen werden; der API-Server kann das Modell direkt auf der Festplatte am gemounteten Pfad finden.
3. Artefakt-Sharing: Wir haben möglicherweise einen Anwendungsfall, bei dem die Ausgabe einer Pipeline-Stufe von der nächsten Stufe verwendet werden muss. Nach dem Feintuning eines Modells müssen wir es beispielsweise eventuell nur zu Experimentierzwecken als API hosten. Wir könnten das Modell zwar in S3 schreiben und von dort wieder herunterladen, aber der Upload-/Download-Prozess würde sehr viel Zeit in Anspruch nehmen. Für schnellere Experimente kann der Feintuning-Job das Modell stattdessen einfach in ein Volume schreiben, und der Inferenz-Dienst mountet anschließend das Volume mit dem Modell.
4. Checkpointing: Während des Trainings von Machine-Learning-Modellen ist es üblich, regelmäßig Checkpoints zu speichern, um das Training im Falle eines Fehlers fortzusetzen oder Modelle feinzutunen. Volumes können verwendet werden, um diese Checkpoint-Dateien zu speichern. So wird sichergestellt, dass der Trainingsfortschritt nicht verloren geht, wenn ein Job nach einem Ausfall neu startet. Dies ermöglicht es Ihnen auch, das Training auf Spot-Instanzen auszuführen, was erhebliche Kosten spart.

Nun zu den ML-Anwendungsfällen: In den meisten Fällen erhalten ML-Engineers die Daten in S3 Buckets, GCS Buckets oder Azure Blob Storage. Wenn sie nun Modelle auf diesen Daten trainieren möchten, müssen sie die Daten auf ihre Trainings-Workload (bereitgestellter Job oder Notebook) herunterladen oder den Inhalt ihres Buckets direkt auf der Workload mounten. 

Wann sollte ein Volume im Vergleich zu Blob Storage wie S3 / GCS / Azure Container verwendet werden?

Die Entscheidung zwischen Blob Storage wie S3 und einem Volume ist aus Performance-, Zuverlässigkeits- und Kostenperspektive wichtig.

Performance

In den meisten Fällen ist das Lesen von Daten aus S3 langsamer als das direkte Lesen von einem Volume. Wenn die Ladegeschwindigkeit für Sie entscheidend ist, ist ein Volume die richtige Wahl. Ein hervorragendes Beispiel hierfür ist das Herunterladen und Laden des Modells zur Inferenzzeit in mehreren Replikaten des Dienstes. Ein Volume ist die bessere Wahl, da Sie nicht die Zeit für das wiederholte Herunterladen des Modells aufwenden müssen und das Modell viel schneller aus dem Volume in den Arbeitsspeicher laden können.

Zuverlässigkeit

Blob Storages wie S3/GCS/ACS sind im Allgemeinen zuverlässiger als Volumes. Daher sollten Sie die Rohdaten idealerweise immer in einem der Blob Storages sichern und Volumes nur für Zwischendaten verwenden. Zudem sollten Sie dauerhaft eine Kopie der Modelle in S3 speichern.

Kosten

Der Zugriff auf Volumes wie EFS ist etwas günstiger als die Nutzung von S3 – wenn Sie dieselben Daten recht häufig lesen, kann es hilfreich sein, sie in einem Volume zu speichern. Wenn Sie nur sehr selten lesen oder schreiben, sollte S3 völlig ausreichen.

Zugriffsbeschränkungen

Auf Daten in Volumes sollte idealerweise nur von Workloads innerhalb derselben Region und desselben Clusters zugegriffen werden. S3 ist für den globalen Zugriff und die Nutzung über verschiedene Cloud-Umgebungen hinweg konzipiert. Volumes sind daher keine gute Wahl, wenn Sie auf die Daten in einer anderen Region oder bei einem anderen Cloud-Anbieter zugreifen möchten.

Volume-Bereitstellungsmodi

Um alle Arten von Volumes zu unterstützen, bietet TrueFoundry zwei Volume-Bereitstellungsmodi für unterschiedliche Anwendungsfälle:

Dynamic

‍Hierbei handelt es sich um Volumes, die dynamisch erstellt und bereitgestellt werden, sobald Sie ein Volume auf TrueFoundry deployen. Z. B. können EBS, EFS in AWS und AzureFiles in Azure auf TrueFoundry dynamisch bereitgestellt werden.

Static

Hierbei handelt es sich um Volumes, für die bereits ein Speicher-Volume existiert und bei denen wir die Daten in diesem Speicher-Volume in unseren Dienst/Job mounten möchten. Beispiele hierfür sind das Mounten von S3 Buckets und GCS Buckets auf den auf der Plattform bereitgestellten Workloads.

Lassen Sie uns nun verstehen, wie diese beiden Modi funktionieren und welche Optionen in den einzelnen Clouds verfügbar sind:

Dynamisch bereitgestellte Volumes

Dynamisch bereitgestellte Volumes erfordern die Angabe einer Storage Class. Ein Volume wird dynamisch entsprechend der vom Benutzer angegebenen Storage Class und Größe bereitgestellt.

Lassen Sie uns also verstehen, was eine Storage Class ist und welche verschiedenen Storage Classes in jeder Cloud verfügbar sind:

Storage Classes

Storage Classes bieten eine Möglichkeit, den Speichertyp anzugeben, der für ein Volume bereitgestellt werden soll. Diese Storage Classes unterscheiden sich in ihren Eigenschaften wie Performance, Haltbarkeit und Kosten. Sie können bei der Erstellung Ihres Volumes die passende Storage Class aus dem Dropdown-Menü "Storage Class" auswählen.

Welche spezifischen Storage Classes verfügbar sind, hängt von dem von Ihnen genutzten Cloud-Anbieter ab und davon, was vom Infra-Team vorkonfiguriert wurde. In der Regel sehen Sie je nach Cloud-Anbieter die folgenden Optionen bei den Storage Classes:

AWS Storage Classes

‍

GCP Storage Classes

‍

Azure Storage Classes

Statisch bereitgestellte Volumes

Statisch bereitgestellte Volumes ermöglichen es Ihnen, Folgendes als Volume zu mounten:

• GCS Bucket
• S3 Bucket
• Bestehendes EFS
• Jedes allgemeine Volume auf Kubernetes

Um statisch bereitgestellte Volumes zu verwenden, müssen Sie ein „PersistentVolume“ erstellen, das auf Ihren Speicher (S3/GCS etc.) verweist. Dafür müssen Sie die erforderlichen CSI-Treiber auf dem Cluster installieren und/oder entsprechende ServiceAccounts für die Berechtigungen einrichten. Im nächsten Abschnitt besprechen wir, wie Sie statisch bereitgestellte Volumes erstellen können.

Einen GCS Bucket als Volume mounten

Um einen GCS Bucket als Volume auf TrueFoundry zu mounten, müssen Sie die folgenden Schritte ausführen. Weitere Details finden Sie in diesem Dokument:

GCS Bucket erstellen

Erstellen Sie einen GCS Bucket und stellen Sie Folgendes sicher:

• Sollte in einer einzelnen Region liegen (Multi-Region funktioniert zwar, ist aber langsamer und verursacht höhere Kosten)
• Die Region sollte dieselbe sein wie die Ihres Kubernetes-Clusters

ServiceAccount erstellen und relevante Berechtigungen erteilen

Sie müssen das folgende Skript ausführen. Dieses führt die folgenden Aktionen aus:

• Aktiviert den GCS Fuse Driver auf dem Cluster
• Erstellt eine IAM-Policy für den Zugriff auf Ihren Bucket
• Erstellt einen K8s-ServiceAccount und weist ihm die Policy zu
• Aktiviert das Role-Binding des ServiceAccounts für den gewünschten K8s-Namespace.

Shell

#!/bin/bash

PROJECT=
CLUSTER_NAME=
REGION=
BUCKET_NAME=
TARGET_NAMESPACE=


K8S_SA_NAME="$BUCKET_NAME-bucket-sa"
GCP_SA_NAME="$BUCKET_NAME-bucket-gcp-sa"
GCP_SA_ID="$GCP_SA_NAME@$PROJECT.iam.gserviceaccount.com"


gcloud container clusters update $CLUSTER_NAME \
    --update-addons GcsFuseCsiDriver=ENABLED \
    --region=$REGION \
    --project=$PROJECT
gcloud iam service-accounts create $GCP_SA_NAME  --project=$PROJECT
gcloud storage buckets add-iam-policy-binding gs://$BUCKET_NAME \
    --member "serviceAccount:$GCP_SA_ID" \
    --role "roles/storage.objectAdmin" \
    --project $PROJECT

gcloud iam service-accounts add-iam-policy-binding $GCP_SA_ID \
    --role roles/iam.workloadIdentityUser \
    --member "serviceAccount:$PROJECT.svc.id.goog[$TARGET_NAMESPACE/$K8S_SA_NAME]" \
    --project $PROJECT

ServiceAccount im Workspace über die TrueFoundry-Benutzeroberfläche erstellen

Wir müssen nun einen ServiceAccount auf TrueFoundry im selben Workspace mit dem Namen TARGET_NAMESPACE erstellen, und der ServiceAccount muss den Namen GCP_SA_NAME tragen.

1. Gehen Sie zu Workspaces -> Wählen Sie Ihren Workspace aus, klicken Sie auf die drei Punkte auf der rechten Seite und dann auf Bearbeiten:

2. Öffnen Sie die erweiterten Optionen unten links im Formular und füllen Sie den Serviceaccount -Bereich aus:

Hinweis

Der Name des ServiceAccounts und der Workspace müssen exakt mit dem vorherigen Schritt übereinstimmen.

Ein PersistentVolume-Objekt erstellen 

Erstellen Sie mit dem folgenden Schritt ein PersistentVolume-Objekt (durch Ausführen von kubectl apply).

YAML

apiVersion: v1
kind: PersistentVolume
metadata:
  name: 
spec:
  capacity:
    storage: 30Gi
  csi:
    driver: gcsfuse.csi.storage.gke.io
    volumeHandle: 
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  storageClassName: np-fuse-test
  mountOptions:
    - implicit-dirs
  volumeMode: Filesystem

Einen S3 Bucket als Volume mounten

Um einen S3 Bucket als Volume auf TrueFoundry zu mounten, müssen Sie die folgenden Schritte ausführen:

Einrichten von IAM-Policies und relevanten Rollen

Bitte folgen Sie diesem Dokument von AWS, um den Mountpoint von S3 in einem EKS-Cluster einzurichten.

Dies leitet Sie bei folgenden Schritten an:

• Erstellen einer IAM-Policy, um dem Mountpoint Berechtigungen für den Zugriff auf den S3 Bucket zu erteilen
• Erstellen einer IAM-Rolle.
• Installieren des Mountpoint für den Amazon S3 CSI-Treiber und Anfügen der oben erstellten Rolle.

Erstellen eines PersistentVolume auf dem Kubernetes-Cluster

Erstellen Sie ein PV mit der folgenden Spezifikation (durch Ausführen von kubectl apply):

YAML

apiVersion: v1
kind: PersistentVolume
metadata:
  name: 
spec:
  capacity:
    storage: 100Gi
  csi:
    driver: s3.csi.aws.com
    volumeHandle: s3-csi-driver-volume # must be unique
    volumeAttributes:
      bucketName: 
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  storageClassName: s3-test # put any value here
  mountOptions:
    - allow-delete
    - region 
    - allow-other
    - uid=1000
  volumeMode: Filesystem

Ein bestehendes EFS als Volume mounten

Um ein bestehendes EFS als Volume auf TrueFoundry zu mounten, müssen Sie die folgenden Schritte ausführen:

EFS CSI-Treiber auf Ihrem Cluster installieren

• Um den EFS CSI-Treiber auf Ihrem Cluster zu installieren, gehen Sie in der TrueFoundry-Benutzeroberfläche zu -> Clusters-> Installed Applications-> Verwalten
  

• Klicken Sie im Volumes-Bereich auf "AWS EFS CSI driver installieren" und dann auf Installieren.

Einen Access Point für Ihr EFS erstellen

• Suchen Sie Ihr EFS in der AWS-Konsole und öffnen Sie es. Stellen Sie sicher, dass sich das EFS und der K8s-Cluster im selben VPC befinden. Klicken Sie auf "Access Point erstellen"
  

• Geben Sie Details wie Name und den Pfad zum Stammverzeichnis ein (stellen Sie sicher, dass Sie den Bereich für Berechtigungen zur Erstellung des Stammverzeichnisses ausfüllen; Sie können UID:1000 GID:1000 eintragen, wenn Sie es an das Notebook anhängen möchten)
  

• Klicken Sie auf Erstellen.

Ein PersistentVolume auf dem Cluster erstellen

Erstellen Sie ein PV mit der folgenden Spezifikation (durch Ausführen von kubectl apply):

YAML

apiVersion: v1
kind: PersistentVolume
metadata:
  name: 
spec:
  capacity:
    storage: 5Gi # this number doesn't matter for EFS, any number will work
  csi:
    driver: efs.csi.aws.com
    volumeHandle: :: # e.g. fs-036e93cbb1fabcdef::fsap-0923ac354cqwerty
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  storageClassName: efs-sc
  volumeMode: Filesystem

Ein Volume auf TrueFoundry erstellen

Bitte folgen Sie diesem Abschnitt, um ein Volume auf TrueFoundry zu erstellen.

Verwendung von Volumes auf TrueFoundry 

Mit den obigen Anleitungen können Sie ganz einfach Volumes bereitstellen oder bestehende Speicher-Container als Volumes nutzen. Diese Volumes können nun auf jeder Workload in Kubernetes gemountet werden. Wenn Sie TrueFoundry nutzen, können Sie Ihr Volume ganz einfach auf jeder beliebigen Workload bereitstellen. Sie können es problemlos auf einem Service oder einer ähnlichen auf TrueFoundry bereitgestellten Workload mounten. Sie können auch mit nur wenigen Klicks über unseren Volume Browser einen Datei-Browser aktivieren, um die Inhalte des Volumes zu durchsuchen.