Datenübertragung von Cloud Storage in ein Hyperdisk ML-Volume mit GKE Volume Populator automatisieren

In diesem Leitfaden wird beschrieben, wie Sie mit GKE Volume Populator große Datenmengen aus einem Cloud Storage-Bucket in ein Hyperdisk ML-Volume von Google Kubernetes Engine (GKE) vorab laden können, wenn dynamische Bereitstellung verwendet wird. Weitere Informationen finden Sie unter GKE Volume Populator.

Diese Anleitung richtet sich an Speicherspezialisten, die Speicherplatz erstellen und zuweisen sowie Datensicherheit und Zugriff verwalten. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Trusted Cloud by S3NS -Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Knotenpoolverwaltung für GKE Volume Populator mit Hyperdisk ML

Eine effiziente Dimensionierung, Bereitstellung und Skalierung von Knotenpools ist entscheidend für die erfolgreiche Ausführung der Datenübertragungsjobs, die von GKE Volume Populator erstellt werden, um Hyperdisk ML-Volumes zu füllen. Mit einer Compute-Klasse definieren Sie die Knotenanforderungen, z. B. Maschinentyp und -größe, für diese spezifischen Datenübertragungsjobs. Mit einer Compute-Klasse können Sie die Kosten und die Leistung des Datenübertragungsprozesses steuern. Weitere Informationen finden Sie unter Vorteile benutzerdefinierter Compute-Klassen.

Wenn Sie einen Cluster auswählen möchten, der am besten für Ihre Datenübertragungsjobs geeignet ist, müssen Sie wissen, wie Rechenklassen mit verschiedenen Clustertypen für Hyperdisk ML funktionieren.

Ziele

In diesem Leitfaden führen Sie die folgenden Aufgaben aus:

• GKE-Clusterumgebung konfigurieren, um Datenübertragungen mit GKE Volume Populator zu unterstützen, einschließlich Clustererstellung, Definition der Compute-Klasse und Einrichtung von Berechtigungen.
• Erstellen Sie eine benutzerdefinierte GCPDataSource-Ressource, um den Cloud Storage-Quellbucket anzugeben.
• Definieren Sie eine StorageClass für Hyperdisk ML.
• Erstellen Sie eine PersistentVolumeClaim, die auf die GCPDataSource verweist, um die Datenpopulation in einem Hyperdisk ML-Volume auszulösen.
• Datenübertragung überprüfen
• Das gefüllte Volume in einem Pod verwenden
• Ressourcen bereinigen.

Hinweise

Achten Sie darauf, dass Sie die folgenden Aufgaben ausgeführt haben:

1. Aktivieren Sie die GKE API und die Cloud Storage API.

   APIs aktivieren

2. Die Abrechnung für Ihr Trusted Cloud by S3NS -Projekt muss aktiviert sein.

3. Laden Sie das Google Cloud CLI-Befehlszeilentool herunter und installieren Sie es oder verwenden Sie Cloud Shell, um die Befehle gcloud CLI und kubectl auszuführen. Cloud Shell ist eine Shell-Umgebung für die Verwaltung von Ressourcen, die in Trusted Cloud by S3NSgehostet werden. Sie ist bei gcloud und dem kubectl-Befehlszeilentool vorinstalliert.

4. Legen Sie eine Standardregion und -zone fest.

5. Erstellen Sie einen Cloud Storage-Bucket oder verwenden Sie einen vorhandenen. In diesem Leitfaden wird davon ausgegangen, dass Sie bereits einen Cloud Storage-Bucket mit Ihren Modelltrainingsdaten haben.

6. Aktivieren Sie den CSI-Treiber für Persistent Disk von Compute Engine für vorhandene Standardcluster, für die der Treiber möglicherweise explizit deaktiviert wurde. In neuen Autopilot- und Standardclustern aktiviert GKE den Treiber standardmäßig. Der von Ihnen erstellte Ziel-Hyperdisk ML-Speicher muss vom CSI-Treiber für Persistent Disk von Compute Engine verwaltet werden.

7. Workload Identity-Föderation für GKE in Ihrem Cluster aktivieren Dadurch kann das Kubernetes-Dienstkonto, das von GKE Volume Populator verwendet wird, auf den Cloud Storage-Quell-Bucket zugreifen. Weitere Informationen finden Sie unter Erforderliche Berechtigungen einrichten.

Voraussetzungen

Wenn Sie Daten mit GKE Volume Populator übertragen möchten, müssen Sie die folgenden Anforderungen erfüllen:

• Auf Ihrem GKE-Cluster muss Version 1.33.2-gke.4780000 oder höher ausgeführt werden.
• Ihre benutzerdefinierte GCPDataSource-Ressource muss sich im selben Namespace wie Ihre GKE-Arbeitslast befinden. Datenquellen, die sich über verschiedene Namespaces erstrecken, werden nicht unterstützt.
• Wählen Sie beim Erstellen der Compute-Klasse eine unterstützte VM aus. Prüfen Sie, ob Ihr Projekt ausreichend Kontingent für den ausgewählten Maschinentyp hat.
• Der Name der gcs-to-hdml-compute-class-Compute-Klasse ist für den Übertragungsjob vordefiniert und muss beim Erstellen der Compute-Klasse genau angegeben werden.

Kosten

Für die Verwendung von GKE Volume Populator fallen keine direkten Kosten an. Für Speicher und Datenübertragungen werden jedoch Gebühren in Rechnung gestellt. Die damit verbundenen indirekten Kosten umfassen Folgendes:

• Von GKE verwendete Compute Engine-Instanzen: die Kosten der Knoten, die zum Ausführen der Datenübertragungsjobs verwendet werden. Die Knotenverwaltung und die Kosten variieren je nach Clustertyp. Weitere Informationen finden Sie unter den jeweiligen Clustertypen unter GKE-Cluster erstellen.
• Knotengröße für Übertragungsjobs: Für eine optimale Übertragungsleistung wird standardmäßig ein Knoten mit 24 vCPUs für einen Übertragungsjob skaliert. Dies gilt für alle Clustertypen. Wenn Sie die Knotengröße und den Knotentyp für bestimmte Kosten- oder Leistungsoptimierungen anpassen möchten, können Sie dies beim Erstellen der Compute-Klasse tun.
• In Ihrem Cloud Storage-Bucket verwendeter Speicherplatz: Weitere Informationen finden Sie unter Cloud Storage – Preise.
• Kosten für Hyperdisk ML-Volumes: Dazu gehören die Speicherkapazität und die Leistung (IOPS/Durchsatz) der von Ihnen erstellten Hyperdisk ML-Volumes. Weitere Informationen finden Sie unter Preise für Hyperdisks.

Umgebung vorbereiten

In diesem Abschnitt erstellen Sie Ihre GKE-Clusterinfrastruktur mit der entsprechenden Hardware und richten die erforderlichen Berechtigungen für den Zugriff auf Ihre Daten in Cloud Storage ein.

Bevor Sie Ihren Cluster für die Verwendung von GKE Volume Populator mit Hyperdisk ML erstellen, sollten Sie wissen, wie eine Compute-Klasse auf verschiedene Arten von Clustern angewendet wird und wer für die Knotenverwaltung verantwortlich ist: GKE oder Sie.

Funktionsweise von Compute-Klassen mit verschiedenen Clustertypen für Hyperdisk ML

GKE Volume Populator verwendet eine benutzerdefinierte Compute-Klasse, um die Knotentypen für die Datenübertragungsjobs zu bestimmen. In der folgenden Tabelle wird das Verhalten Ihrer Compute-Klasse in Abhängigkeit von Ihrer Clusterkonfiguration beschrieben:

GKE startet den Datenübertragungsjob, nachdem die PersistentVolume für die PersistentVolumeClaim bereitgestellt wurde. Damit das Hyperdisk ML-Volume mit Daten gefüllt werden kann, muss in diesem PersistentVolumeClaim auf das GCPDataSource verwiesen werden, in dem die Quelldaten in Cloud Storage definiert sind.

GKE-Cluster erstellen

Sie können Ihre Datenübertragungspipeline mit einem Standard- oder Autopilot-Cluster mit GKE-Version 1.33.2-gke.4780000 oder höher bereitstellen. Jeder Clustertyp hat seine eigenen Vorteile und unterschiedliche Preismodelle.

• Wählen Sie Autopilot aus, um die Clusterverwaltung zu vereinfachen, Kosten zu senken und Autoscaling zu nutzen.
• Wählen Sie „Standard“ mit aktivierter automatischer Knotenbereitstellung aus, wenn Sie Autoscaling mit mehr Kontrolle über die Knotenbereitstellung benötigen.
• Wählen Sie „Standard“ ohne aktivierte automatische Knotenbereitstellung aus, wenn Sie maximale Kontrolle benötigen und alle Aspekte der Knotenbereitstellung, ‑skalierung und ‑wartung selbst verwalten möchten.

    gcloud container clusters create-auto CLUSTER_NAME \
        --location=LOCATION \
        --cluster-version=CLUSTER_VERSION
    

    gcloud container clusters create CLUSTER_NAME \
        --cluster-version=CLUSTER_VERSION \
        --location=LOCATION \
        --project=PROJECT_ID \
        --workload-pool=PROJECT_ID.svc.id.goog \
        --enable-autoprovisioning \
        --min-cpu MINIMUM_CPU \
        --min-memory MINIMUM_MEMORY \
        --max-cpu MAXIMUM_CPU \
        --max-memory MAXIMUM_MEMORY \
    --autoprovisioning-scopes=https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring,https://www.googleapis.com/auth/devstorage.read_only
    

    gcloud container clusters create CLUSTER_NAME \
        --cluster-version=CLUSTER_VERSION \
        --location=LOCATION \
        --num-nodes=1 \
        --project=PROJECT_ID \
        --workload-pool=PROJECT_ID.svc.id.goog

    gcloud container node-pools create NODE_POOL_NAME\
        --cluster=CLUSTER_NAME \
        --location=LOCATION \
        --num-nodes=1 \
        --machine-type=c3-standard-44 \
        --node-labels="cloud.google.com/compute-class=gcs-to-hdml-compute-class" \
        --node-taints="cloud.google.com/compute-class=gcs-to-hdml-compute-class:NoSchedule"
    

Compute-Klasse erstellen

So erstellen Sie eine Compute-Klasse, um die VM-Typen anzugeben und zu priorisieren, die als Knoten in Ihrem Cluster verwendet werden können:

1. Speichern Sie das folgende Manifest als computeclass.yaml:

   Mit automatischer Knotenbereitstellung

   Für Autopilot-Cluster und Standardcluster mit aktivierter automatischer Knotenbereitstellung definieren Sie die Compute-Klasse mit dem Abschnitt nodePoolAutoCreation wie folgt. Wenn die automatische Knotenbereitstellung aktiviert ist, erstellt GKE automatisch neue Knotenpools mit dem Compute-Klassenlabel gcs-to-hdml-compute-class.

       apiVersion: cloud.google.com/v1
       kind: ComputeClass
       metadata:
         name: gcs-to-hdml-compute-class
       spec:
         priorities:
         - machineFamily: c3
         - machineFamily: c3d
         nodePoolAutoCreation:
           enabled: true
         whenUnsatisfiable: DoNotScaleUp
       

   Ohne automatische Knotenbereitstellung

   Definieren Sie für Standardcluster ohne aktivierte automatische Knotenbereitstellung die Compute-Klasse ohne den nodePoolAutoCreation-Abschnitt wie folgt. Sie müssen bereits einen Knotenpool mit dem Label für die Compute-Klasse gcs-to-hdml-compute-class erstellt haben.

       apiVersion: cloud.google.com/v1
       kind: ComputeClass
       metadata:
         name: gcs-to-hdml-compute-class
       spec:
         priorities:
         - machineFamily: c3
         - machineFamily: c3d
         whenUnsatisfiable: DoNotScaleUp
       

   Sie können ein beliebiges kompatibles machineFamily angeben, um Ihre Anforderungen an die Datenübertragung zu erfüllen. Weitere Informationen zur Auswahl eines geeigneten Maschinentyps finden Sie unter Unterstützung von Maschinenserien für Hyperdisk ML.

2. Wenden Sie das Manifest an, um die Compute-Klasse zu erstellen:

   kubectl apply -f computeclass.yaml

Erforderliche Berechtigungen einrichten

Wenn Sie Daten aus einem Cloud Storage-Bucket übertragen möchten, müssen Sie die erforderlichen Berechtigungen für die Workload Identity-Föderation für GKE einrichten. Mit den entsprechenden Berechtigungen kann der von GKE Volume Populator erstellte Übertragungsjob auf Ihren Cloud Storage-Bucket zugreifen. In dieser Anleitung wird davon ausgegangen, dass Sie bereits einen Cloud Storage-Bucket mit den Modelltrainingsdaten haben, die Sie übertragen möchten.

1. Erstellen Sie einen Kubernetes-Namespace:

   kubectl create namespace NAMESPACE
   

   Ersetzen Sie NAMESPACE durch den Namespace, in dem Ihre Arbeitslasten ausgeführt werden sollen.

   Überspringen Sie diesen Schritt, wenn Sie einen vorhandenen Namespace verwenden.

2. Erstellen Sie ein Kubernetes-Dienstkonto:

   kubectl create serviceaccount KSA_NAME \
       --namespace=NAMESPACE
   

   Ersetzen Sie Folgendes:

   • KSA_NAME: Der Name des Kubernetes-Dienstkontos, das Sie in der GCPDataSource-Ressource angeben. Der vom GKE Volume Populator erstellte Übertragungsjob verwendet dieses Dienstkonto zur Authentifizierung bei Trusted Cloud by S3NS APIs.
   • NAMESPACE: der Kubernetes-Namespace, den Sie im vorherigen Schritt erstellt haben.

3. Weisen Sie Ihrem IAM-Dienstkonto die entsprechende Rolle für den Zugriff auf Ihren Cloud Storage-Bucket zu:

   gcloud storage buckets \
       add-iam-policy-binding gs://GCS_BUCKET \
       --member "principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME" \
       --role "ROLE"
   

   Ersetzen Sie Folgendes:

   • GCS_BUCKET: Name Ihres Cloud Storage-Buckets.
   • PROJECT_NUMBER: die numerische Kennung Ihres Trusted Cloud by S3NS Projekts, in dem Sie den Cluster erstellt haben. Informationen zum Ermitteln der Projektnummer finden Sie unter Projekte identifizieren.
   • PROJECT_ID: Ihre Trusted Cloud by S3NS -Projekt-ID
   • NAMESPACE: der Namespace, den Sie zuvor erstellt haben und in dem Ihre Arbeitslasten ausgeführt werden.
   • KSA_NAME: Der Name des Kubernetes-Dienstkontos, das Sie in der GCPDataSource-Ressource angegeben haben. Der vom GKE Volume Populator erstellte Übertragungsjob verwendet dieses Dienstkonto zur Authentifizierung bei Trusted Cloud by S3NS APIs.
   • ROLE: Die IAM-Rolle, die Sie Ihrem Dienstkonto zuweisen möchten. Weisen Sie für diese Anleitung die Rolle roles/storage.objectViewer zu, um das Lesen aus dem Bucket zu ermöglichen.

   Die Werte PROJECT_NUMBER, PROJECT_ID, NAMESPACE und KSA_NAME werden verwendet, um die Prinzipal-ID der Identitätsföderation von Arbeitslasten für GKE für Ihr Projekt zu erstellen.

Hyperdisk ML-Volume mit vorab geladenen Daten erstellen

Führen Sie die folgenden Schritte aus, um die GKE-Infrastruktur und -Konfiguration einzurichten, die zum Erstellen eines Hyperdisk ML-Volumes erforderlich sind, und um den automatischen Datenübertragungsprozess mit GKE Volume Populator auszulösen und zu verwalten:

1. GCPDataSource-Benutzerressource erstellen, um die Datenquelle zu definieren.
2. Erstellen Sie eine StorageClass, um den Typ des nichtflüchtigen Speichers (ein Hyperdisk ML-Volume) zu definieren, der verwendet werden soll.
3. Erstellen Sie einen PersistentVolumeClaim, um die dynamische Bereitstellung des Speichers zu ermöglichen und den Zugriff auf das neu bereitgestellte Hyperdisk ML-Volume zu aktivieren.
4. Optional: Fortschritt der Datenübertragung ansehen
5. Erstellen und stellen Sie einen Pod bereit, der das Hyperdisk ML-Volume nutzt.

Benutzerdefinierte GCPDataSource-Ressource erstellen

Erstellen Sie in GKE eine benutzerdefinierte GCPDataSource-Ressource, um den Speicherort des Cloud Storage-Quellbuckets und das Dienstkonto mit den erforderlichen Berechtigungen für den Zugriff auf diesen Bucket anzugeben. Diese benutzerdefinierte Ressourcendefinition (Custom Resource Definition, CRD) ist spezifisch für den GKE Volume Populator.

1. Speichern Sie das folgende Manifest als gcpdatasource.yaml.

   apiVersion: datalayer.gke.io/v1
   kind: GCPDataSource
   metadata:
     name: GCP_DATA_SOURCE
     namespace: NAMESPACE
   spec:
     cloudStorage:
       serviceAccountName: KSA_NAME
       uri: gs://GCS_BUCKET/
   

   Ersetzen Sie die folgenden Werte:

   • GCP_DATA_SOURCE: Der Name der GCPDataSource-CRD, die einen Verweis auf Ihren Cloud Storage-Bucket enthält. Weitere Informationen finden Sie in der GCPDataSource-CRD-Referenz.
   • NAMESPACE: derselbe Namespace, in dem Ihre Arbeitslasten ausgeführt werden. Die benutzerdefinierte Ressource GCPDataSource wird in diesem Namespace erstellt.
   • KSA_NAME: Der Name des Kubernetes-Dienstkontos, das Sie in der GCPDataSource-Ressource angegeben haben. Der vom GKE Volume Populator erstellte Übertragungsjob verwendet dieses Dienstkonto zur Authentifizierung bei Trusted Cloud by S3NS APIs. Der Wert cloudStorage.serviceAccountName ist das Kubernetes-Dienstkonto, das Sie für die Workload Identity-Föderation für GKE im Abschnitt Erforderliche Berechtigungen einrichten eingerichtet haben.
   • GCS_BUCKET: Name Ihres Cloud Storage-Buckets. Im Feld uri werden die Quelldaten angegeben.
     • Wenn Sie den gesamten Bucket kopieren möchten, verwenden Sie gs://GCS_BUCKET/.
     • Wenn Sie Daten aus einem bestimmten Ordner im Bucket kopieren möchten, verwenden Sie das Format gs://GCS_BUCKET/PATH_INSIDE_BUCKET/. Wenn Sie beispielsweise Daten aus dem Ordner gemma/v1.0/weights/ im Bucket my-project-llm-models kopieren möchten, lautet der URI gs://my-project-llm-models/gemma/v1.0/weights/. Achten Sie darauf, dass der Pfad mit einem Schrägstrich endet, um einen Ordner anzugeben.

2. Wenden Sie das Manifest an, um die GCPDataSource-Ressource zu erstellen:

   kubectl apply -f gcpdatasource.yaml
   

StorageClass für Hyperdisk ML erstellen

Erstellen Sie eine StorageClass, die den Bereitsteller pd.csi.storage.gke.io verwendet, um ein Hyperdisk ML-Volume in der von Ihnen ausgewählten Zone bereitzustellen. Wenn Sie möchten, dass Kopien Ihrer Daten in mehr als einer Zone verfügbar sind, können Sie eine StorageClass für mehrere Zonen erstellen. Hier finden Sie ein Beispiel für eine StorageClass für mehrere Zonen.

1. Speichern Sie das folgende Manifest als hdml-class.yaml.

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: hyperdisk-ml-single-zone
   parameters:
     type: hyperdisk-ml
     provisioned-throughput-on-create: "2400Mi"
   provisioner: pd.csi.storage.gke.io
   allowVolumeExpansion: false
   reclaimPolicy: Delete
   volumeBindingMode: Immediate
   allowedTopologies:
   - matchLabelExpressions:
     - key: topology.gke.io/zone
       values:
       - ZONE
   

   Ersetzen Sie ZONE durch die Zielzone, in der das Hyperdisk ML-Volume erstellt werden soll:

   • Für GKE-Standardcluster ohne automatische Knotenbereitstellung muss der Wert für ZONE der Ort sein, an dem Sie Ihre Knoten erstellt haben.
   • Für GKE Autopilot- oder Standardcluster mit automatischer Knotenbereitstellung muss der Wert für ZONE der Standort sein, an dem Ihr Cluster bei Bedarf skaliert und neue Knoten erstellt werden können.

2. Optional: Führen Sie den folgenden Befehl aus, um die Knotenstandorte Ihres Clusters aufzulisten:

   gcloud container clusters describe CLUSTER_NAME --location=LOCATION --format="value(locations)"
   

   Ersetzen Sie Folgendes:

   • CLUSTER_NAME: Der Name Ihres Clusters.
   • LOCATION: die Compute-Zone oder ‑Region für Ihren Cluster. Beispiel: us-central1-aoder us-central1

3. Wenden Sie das Manifest an, um die StorageClass zu erstellen :

   kubectl apply -f hdml-class.yaml
   

PersistentVolumeClaim für den Zugriff auf das Volume erstellen

Das folgende Manifest zeigt ein Beispiel für das Erstellen eines PersistentVolumeClaims im ReadOnlyMany-Zugriffsmodus, der auf die zuvor erstellte StorageClass verweist.

1. Speichern Sie das folgende Manifest als volume-populator-pvc.yaml:

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: PVC_NAME
     namespace: NAMESPACE
   spec:
     accessModes:
     - ReadOnlyMany
     storageClassName: hyperdisk-ml-single-zone
     resources:
       requests:
         storage: DISK_SIZE
     dataSourceRef:
       apiGroup: datalayer.gke.io
       kind: GCPDataSource
       name: GCP_DATA_SOURCE
   

   Ersetzen Sie die folgenden Werte:

   • PVC_NAME: Der Name des PersistentVolumeClaim, in den Sie Ihre Daten übertragen möchten.
   • NAMESPACE: der Namespace, in dem Ihre Arbeitslasten ausgeführt werden.
   • DISK_SIZE: die Größe des Laufwerks in Gigabyte, das zum Einfügen von Daten erstellt wird. Damit Daten erfolgreich eingefügt werden können, muss die angeforderte Festplattengröße größer sein als die Größe der Daten Ihres Modells im Cloud Storage-Bucket. Damit der unterstützte Bereich für die Hyperdisk ML-Volumes eingehalten wird, muss der Wert von DISK_SIZE größer als 4 Gi sein. Weitere Informationen finden Sie unter Größenlimits für Hyperdisk-Volumes.
   • GCP_DATA_SOURCE: Der Name der GCPDataSource-CRD, die einen Verweis auf Ihren Cloud Storage-Bucket enthält.

   Sie können die Datenübertragung anpassen, indem Sie Ihrem PVC optionale Anmerkungen hinzufügen. Diese Anmerkungen beeinflussen das Verhalten des zugrunde liegenden Übertragungsjobs, mit dem Daten in Ihr Hyperdisk ML-Volume kopiert werden.

   • volume-populator.datalayer.gke.io/cpu-request: Mit dieser Annotation können Sie eine andere CPU-Ressourcenanfrage für den Transfer Job angeben. Wenn Sie keine andere CPU-Ressourcenanfrage angeben, werden für den PVC standardmäßig 24 vCPUs angefordert, um die Übertragungsleistung zu optimieren.

   • volume-populator.datalayer.gke.io/transfer-path: Mit dieser Annotation geben Sie den Zielpfad im neuen Volume an, in dem die aus Ihrer GCPDataSource-Ressource kopierten Daten gespeichert werden. Wenn Sie keinen anderen Pfad angeben, werden die Daten in den Stammpfad im Hyperdisk ML-Volume kopiert.

2. Wenden Sie das Manifest an, um den PVC zu erstellen:

   kubectl apply -f volume-populator-pvc.yaml
   

Beachten Sie Folgendes:

• Wenn Sie das Feld volumeBindingMode in Ihrer StorageClass auf immediate festlegen, wird die Datenübertragung sofort nach der Bereitstellung des PVC ausgelöst.
• Wenn Sie das Feld volumeBindingMode in Ihrer StorageClass auf WaitForFirstConsumer festlegen, wird die Datenübertragung erst ausgelöst, wenn Sie einen Pod bereitstellen, der den PVC anfordert, und dieser Pod erfolgreich auf einem Knoten geplant wird. Ihr Pod kann zwar geplant werden, seine Container warten jedoch mit dem Start, bis die Datenübertragung abgeschlossen ist und das Volume verwendet werden kann.

Weitere Informationen Wenn bei der Ressourcenbereitstellung oder Datenübertragung Fehler auftreten, lesen Sie den Abschnitt Fehlerbehebung bei der Datenübertragung mit GKE Volume Populator.

(Optional) Fortschritt der Datenübertragung ansehen

In diesem Abschnitt wird beschrieben, wie Sie den Fortschritt und Erfolg Ihrer Datenübertragungen von einem Cloud Storage-Bucket auf ein Hyperdisk ML-Volume verfolgen können.

1. Führen Sie den folgenden Befehl aus, um den Status Ihres PersistentVolumeClaim zu prüfen. Sie können diesen Befehl auch ausführen, wenn die Bindung des PersistentVolumeClaim zu lange dauert.

   kubectl describe pvc PVC_NAME -n NAMESPACE
   

   Ersetzen Sie Folgendes:

   • PVC_NAME: Der Name des PVC, den Sie im Abschnitt PersistentVolumeClaim für den Zugriff auf das Volume erstellen erstellt haben.
   • NAMESPACE: Der Namespace, der in diesem Leitfaden verwendet wird und den Sie im Abschnitt Erforderliche Berechtigungen einrichten erstellt haben.

2. Sehen Sie sich in der Ausgabe die PersistentVolumeClaim-Ereignisse an, um den Fortschritt der Datenübertragung zu verfolgen. GKE protokolliert die Ereignisse etwa einmal pro Minute. Die Ausgabe sieht etwa so aus:

   Name:          vp-pvc
   Namespace:     default
   StorageClass:  hyperdisk-ml-single-zone
   Status:        Bound
   Volume:        pvc-f7ae2ee2-106d-4b87-b458-481a3ff82b62
   Labels:        <none>
   Annotations:   pv.kubernetes.io/bind-completed: yes
                 pv.kubernetes.io/bound-by-controller: yes
                 volume.beta.kubernetes.io/storage-provisioner: pd.csi.storage.gke.io
                 volume.kubernetes.io/storage-provisioner: pd.csi.storage.gke.io
   Finalizers:    [kubernetes.io/pvc-protection]
   Capacity:      200Gi
   Access Modes:  ROX
   VolumeMode:    Filesystem
   DataSource:
     APIGroup:  datalayer.gke.io
     Kind:      GCPDataSource
     Name:      vp-gds
   Used By:     verify-data-665cfd4dbf-mwc7t
               verify-data-665cfd4dbf-n7xw9
   Events:
     Type     Reason                         Age                     From                                                                                              Message
     ----     ------                         ----                    ----                                                                                              -------
     Warning  ProvisioningFailed             9m8s                    persistentvolume-controller                                                                       Error saving claim: Operation cannot be fulfilled on persistentvolumeclaims "vp-pvc": the object has been modified; please apply your changes to the latest version and try again
     Normal   Provisioning                   9m5s                    pd.csi.storage.gke.io_gke-f110123a1cbd44cdaa7a-921b-b1f4-vm_1a100bd9-5231-4f20-8e65-1f8e995a03c0  External provisioner is provisioning volume for claim "default/vp-pvc"
     Normal   Provisioning                   9m5s                    external-provisioner                                                                              Assuming an external populator will provision the volume
     Normal   PopulateOperationStartSuccess  8m58s                   gkevolumepopulator-populator                                                                      populateFn: Populate operation started for zone us-central1-c
     Normal   TransferInProgress             8m58s (x2 over 8m58s)   gkevolumepopulator-populator                                                                      populateCompleteFn: For PVC vp-pvc in namespace default, transfer job with request ID populator-job-2304531e-4937-4534-a1a4-3eb11e5cb39f in zone us-central1-c waiting for pod to get created
     Normal   TransferInProgress             6m10s (x14 over 8m57s)  gkevolumepopulator-populator                                                                      populateCompleteFn: For PVC vp-pvc in namespace default, transfer job in zone us-central1-c with request ID populator-job-2304531e-4937-4534-a1a4-3eb11e5cb39f is still active with pod status as - Phase: Pending
     Normal   ExternalProvisioning           3m35s (x24 over 9m5s)   persistentvolume-controller                                                                       Waiting for a volume to be created either by the external provisioner 'pd.csi.storage.gke.io' or manually by the system administrator. If volume creation is delayed, please verify that the provisioner is running and correctly registered.
     Normal   TransferJobCompleted           3m24s (x2 over 3m26s)   gkevolumepopulator-populator                                                                      populateCompleteFn: For PVC vp-pvc in namespace default, job with request ID populator-job-2304531e-4937-4534-a1a4-3eb11e5cb39f for zone us-central1-c completed successfully
     Normal   TransferJobCompleted           3m24s (x2 over 3m26s)   gkevolumepopulator-populator                                                                      populateCompleteFn: For PVC vp-pvc in namespace default, transfer job for all zones have completed successfully
     Normal   PopulateOperationFinished      3m24s (x2 over 3m26s)   gkevolumepopulator-populator                                                                      Populate operation finished
     Normal   PopulatorFinished              3m19s (x3 over 3m20s)   gkevolumepopulator-populator                                                                      Populator finished
   

Je nach Datengröße kann es einige Minuten dauern, bis der Vorgang zum Einfügen von Daten beginnt. Wenn nach einigen Minuten kein Fortschritt beim Datentransfer angezeigt wird, finden Sie unter Probleme beim Datentransfer mit GKE Volume Populator beheben weitere Informationen.

Bei Datenübertragungen für Hyperdisk ML-Volumes für mehrere Zonen wird der Job erst als abgeschlossen markiert, wenn die Daten erfolgreich in alle in der StorageClass angegebenen Zonen übertragen wurden. Wenn der Übertragungsjob für eine oder mehrere Zonen fehlschlägt, versucht der GKE Volume Populator, die Daten unbegrenzt oft zu übertragen, solange die PVC vorhanden ist.

Pod erstellen und bereitstellen, der das Volume verbraucht

So erstellen Sie einen Pod, um den Inhalt eines PVC zu prüfen, der mit Daten gefüllt wurde:

1. Speichern Sie das folgende Manifest als verify-data.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: verify-data
     namespace: NAMESPACE
   spec:
     nodeSelector:
       cloud.google.com/compute-class: gcs-to-hdml-compute-class
     containers:
     - name: verify-data
       image: busybox
       command:
       - sleep
       - infinity
       volumeMounts:
         - mountPath: /models
           name: mypvc
     volumes:
     - name: mypvc
       persistentVolumeClaim:
         claimName: PVC_NAME
   

   Ersetzen Sie Folgendes:

   • NAMESPACE: der Namespace, in dem sich Ihr PVC befindet und in dem Sie den verify-data-Pod erstellen möchten.
   • PVC_NAME: Der Name des PVC, den Sie zum Füllen von Daten im Abschnitt Mit einem PersistentVolumeClaim auf das Volume zugreifen erstellt haben.

2. Erstellen Sie den Pod mit dem folgenden Befehl:

   kubectl create -f verify-data.yaml
   

3. Führen Sie den folgenden Befehl aus, um die Dateien aufzulisten:

   kubectl exec -it verify-data -- /bin/sh
   # cd /models && ls
   

Wenn der Befehl erfolgreich ist, finden Sie die eingefügten Daten im Verzeichnis /models in Ihrem Cloud Storage-Bucket.

Bereinigen

Um unnötige Kosten zu vermeiden und falsch konfigurierte oder verwaiste Ressourcen zu entfernen, folgen Sie der Anleitung zum ordnungsgemäßen Löschen des PersistentVolumeClaim.

PersistentVolumeClaim bei dynamischer Bereitstellung löschen

Wenn Sie Ihren PersistentVolumeClaim löschen müssen, während Daten während der dynamischen Bereitstellung noch übertragen werden, führen Sie die folgenden Schritte für das ordnungsgemäße Löschen aus. Das endgültige Löschen kann einige Zeit dauern.

Ersetzen Sie die folgenden relevanten Variablen während des Löschvorgangs:

• POD_NAME: der Name des Pods, den Sie im Abschnitt Pod erstellen und bereitstellen, der das Volume nutzt erstellt haben.
• NAMESPACE: der Namespace, in dem sich Ihre PVC befindet.
• PVC_NAME: Der Name des PVC, den Sie im Abschnitt Mit einem PersistentVolumeClaim auf das Volume zugreifen erstellt haben.
• GCP_DATA_SOURCE: der Name der benutzerdefinierten Ressource GCPDataSource, die Sie im Abschnitt Benutzerdefinierte Ressource GCPDataSource erstellen erstellt haben.

1. Löschen Sie den Arbeitslast-Pod:

   kubectl delete pod POD_NAME -n NAMESPACE
   

2. Suchen Sie den Namen des temporären PersistentVolumeClaim:

   # Store the relevant environment variables
   export PVC_NAME=PVC_NAME
   export NAMESPACE=NAMESPACE
   

   # Check the status
   export PVC_UID=$(kubectl get pvc ${PVC_NAME} -n ${NAMESPACE} -o jsonpath='{.metadata.uid}')
   export TEMP_PVC=prime-${PVC_UID}
   echo ${TEMP_PVC}
   

3. Löschen Sie den PVC, der im Namespace erstellt wurde:

   kubectl delete pvc PVC_NAME -n NAMESPACE
   

4. Der PVC befindet sich möglicherweise im Status Terminating:

   NAME           STATUS        VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS               VOLUMEATTRIBUTESCLASS   AGE
   vp-pvc   Terminating                                      hyperdisk-ml   <unset>                 7m23s
   

   Wenn ja, bereinigen Sie den PVC manuell, indem Sie seine Finalizer entfernen:

   kubectl patch pvc PVC_NAME -n NAMESPACE  -p '{"metadata":{"finalizers":null}}'
   

5. Löschen Sie die GCPDataSource-Ressource erst, nachdem der PVC gelöscht wurde. Wenn Sie zuerst die GCPDataSource-Ressource löschen, bleibt das Löschen des PVC hängen.

   kubectl delete gcpdatasource GCP_DATA_SOURCE -n NAMESPACE
   

6. Prüfen Sie, ob die temporären Ressourcen gelöscht wurden.

Nächste Schritte

• Weitere Informationen zum GKE Volume Populator
• Hilfe bei Problemen mit der Datenübertragung finden Sie unter Fehlerbehebung bei Problemen mit der Datenübertragung für GKE Volume Populator.
• Ein erweitertes Beispiel für eine Hyperdisk ML-Arbeitslast finden Sie unter KI/ML-Datenladen mit Hyperdisk ML beschleunigen.