Umfangreiche Modelle für maschinelles Lernen mit Multi-Tier-Checkpointing in GKE trainieren

Auf dieser Seite erfahren Sie, wie Sie mit Multi-Tier Checkpointing Prüfpunkte während des Trainings Ihres Machine-Learning-Modells in GKE zuverlässig speichern und verwalten. Das Speichern und Verwalten von Checkpoints ist für große Trainingsjobs, die Tausende von Knoten verwenden, von entscheidender Bedeutung. Unterbrechungen dieser umfangreichen Jobs sind häufig (möglicherweise stündlich) und die Wiederherstellung kann langsam sein.

Vorteile

Die Verwendung von Checkpointing auf mehreren Ebenen bietet folgende Vorteile:

  • Vollständig orchestrierte Verwaltung von Checkpoint-Daten, einschließlich Sicherungen, Replikation und automatischer Wiederherstellung für die folgenden Arbeitslasten:
  • Schnelle Wiederherstellung von Trainingsjobs aus einem Checkpoint, der auf dem lokalen Knoten gespeichert ist. Sie können auch Checkpoints verwenden, die auf einem anderen Knoten im Trainingscluster gespeichert sind.
  • Schnelle Wiederherstellung von Trainingsjobs aus einem Prüfpunkt, der in einem Cloud Storage-Back-up gespeichert ist, in Worst-Case-Szenarien, in denen keine Cluster-Prüfpunkte vorhanden sind.

Hinweise

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

  • Aktivieren Sie die Google Kubernetes Engine API.
    • Google Kubernetes Engine API aktivieren
  • Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit gcloud components update ab.

Voraussetzungen

Für das Multi-Tier Checkpointing ist die GKE-Clusterversion 1.32.4-gke.1415000 oder höher erforderlich.

Beschränkungen

  • Autopilot-Cluster werden nicht unterstützt.

GKE-Knoten für die Verwendung von Multi-Tier Checkpointing konfigurieren

In diesem Abschnitt wird beschrieben, wie Sie GKE-Knoten in neuen und vorhandenen Clustern konfigurieren.

Knoten in einem neuen Cluster konfigurieren

  1. Erstellen Sie einen Cluster mit aktivierter Multi-Tier Checkpointing-Funktion, dem Cloud Storage FUSE CSI-Treiber und der Workload Identity-Föderation für GKE. Wenn Sie TPU-Slices für Ihre ML-Arbeitslast verwenden, müssen Sie den Befehl zum Erstellen des Clusters anpassen, um die Konfiguration für einen TPU-Slice-Knotenpool einzuschließen.

    gcloud container clusters create CLUSTER_NAME \
    --addons=HighScaleCheckpointing,GcsFuseCsiDriver  \
    --node-locations=NODE_LOCATION \
    --workload-pool=PROJECT_ID.svc.id.goog \
    --cluster-version=CLUSTER_VERSION
    --location=CLUSTER_LOCATION \
    --machine-type=MACHINE_TYPE \
    --num-nodes=NUM_NODES

    Ersetzen Sie die folgenden Werte:

    • CLUSTER_NAME ist der Name des Clusters.
    • NODE_LOCATION: Die Zone für Ihre Clusterknoten. Hier befindet sich Ihre TPU-Kapazität.
    • PROJECT_ID: Ihre Google Cloud Projekt-ID.
    • CLUSTER_VERSION: Die Version Ihres Clusters. 1.32.4-gke.1415000 ist die unterstützte Mindestversion.
    • CLUSTER_LOCATION: Die Region, in der Sie den Cluster erstellen möchten.
    • MACHINE_TYPE: Der Maschinentyp, der für Knoten verwendet wird, auf denen Komponenten wie der JobSet-Controller und der Controller für mehrstufige Prüfpunkte ausgeführt werden. Für das Training in großem Maßstab empfehlen wir die Verwendung von mindestens e2-standard-4 Maschinen. Sie verwenden diesen Maschinentyp nicht für das Modelltraining, sondern erstellen dafür separate Knotenpools, in denen häufig beschleunigungsoptimierte VM-Familien verwendet werden.
    • NUM_NODES: Die Anzahl der Knoten, die in den einzelnen Zonen des Clusters erstellt werden sollen.

Knoten in einem vorhandenen Cluster konfigurieren

Wenn Sie Multi-Tier Checkpointing mit einem vorhandenen Cluster verwenden möchten, aktivieren Sie es zusammen mit dem CSI-Treiber für Cloud Storage FUSE und der Workload Identity-Föderation für GKE mit den folgenden Befehlen. Ihre vorhandene Clusterversion muss höher als 1.32.3-gke.1170000 sein.

  1. Identitätsföderation von Arbeitslasten für GKE aktivieren:

    gcloud container clusters update CLUSTER_NAME \
    --workload-pool=PROJECT_ID.svc.id.goog \
    --location=CLUSTER_LOCATION

    Ersetzen Sie die folgenden Werte:

    • CLUSTER_NAME ist der Name des Clusters.
    • PROJECT_ID: Ihre Google Cloud Projekt-ID.
    • CLUSTER_LOCATION: Die Region des Clusters.

  2. Aktivieren Sie das mehrstufige Checkpointing und den CSI-Treiber für Cloud Storage FUSE:

    gcloud container clusters update CLUSTER_NAME \
    --update-addons=HighScaleCheckpointing=ENABLED,GcsFuseCsiDriver=ENABLED \
    --location=CLUSTER_LOCATION

Berechtigungen für die Verwendung von Multi-Tier Checkpointing konfigurieren

In diesem Abschnitt wird beschrieben, wie Sie Berechtigungen für die Verwendung von Multi-Tier Checkpointing konfigurieren.

Zugriff auf Cloud Storage-Buckets gewähren

Für die temporären Volumes, die vom Multi-Tier Checkpointing-CSI-Treiber verwendet werden, müssen vorhandene Cloud Storage-Buckets verwendet werden.

Wenn Sie Prüfpunkte in einem Cloud Storage-Bucket speichern möchten, muss Multi-Tier Checkpointing auf den Bucket zugreifen können. Weisen Sie dem Kubernetes-Dienstkonto für die mehrstufige Sicherung die IAM-Rolle „Storage Object User“ (roles/storage.objectUser) für den 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/gke-managed-checkpointing/sa/gke-checkpointing-multitier-node" \
    --role "roles/storage.objectUser"

Ersetzen Sie die folgenden Werte:

Optional: Dem Compute Engine-Standarddienstkonto Zugriff gewähren

Wenn Ihre Compute Engine-Instanzen Lesezugriff auf den Cloud Storage-Bucket benötigen, weisen Sie dem Compute Engine-Standarddienstkonto die IAM-Rolle „Storage-Objekt-Betrachter“ (roles/storage.objectViewer) zu.

gcloud storage buckets add-iam-policy-binding gs://GCS_BUCKET \
    --member serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \
    --role roles/storage.objectViewer

JobSet-Controller bereitstellen

Der JobSet-Controller ist für die Verwaltung der Batchjobs verantwortlich, mit denen das Modelltraining in GKE ausgeführt wird. Die Ressourcenzuweisung wird angepasst, um die Arbeitslast effizient zu bewältigen. Achten Sie darauf, dass Ihr Launcher für Trainingsjobs JobSet bereitstellt und verwendet.

Führen Sie den folgenden Patch-Befehl aus, um die Speicheranforderung für den Manager-Container in Ihrer JobSet-Bereitstellung auf 1 Gi, das Speicherlimit auf 2 Gi und die CPU-Anforderung auf 1 zu erhöhen:

kubectl patch -n jobset-system deploy jobset-controller-manager --type json \
    --patch '[{"op": "add", "path": "/spec/template/spec/containers/0/resources", "value": {"limits": {"memory": "2Gi"}, "requests": {"cpu": "1", "memory": "1Gi"}}}]'

Multi-Tier Checkpointing-CSI-Treiber initialisieren

In diesem Abschnitt wird beschrieben, wie Sie den CSI-Treiber für die mehrstufige Prüfpunktsetzung auf Knoten initialisieren, auf denen Ihre Arbeitslasten ausgeführt werden. Der CSI-Treiber ist für die Speicherung und Verwaltung von Prüfpunkten während des Modelltrainings verantwortlich.

CheckpointConfiguration erstellen

Eine CheckpointConfiguration ist eine benutzerdefinierte Kubernetes-Ressource, die Eigenschaften für die Bereitstellung des Multi-Tier Checkpointing-CSI-Treibers angibt. Diese Ressource ist clusterbezogen.

  1. Erstellen Sie das folgende checkpoint.yaml-Manifest.

    apiVersion: checkpointing.gke.io/v1
kind: CheckpointConfiguration
metadata:
  name: MTC_CONFIG_NAME-configuration
spec:
    cloudStorageBucketName: GCS_BUCKET
    nodeSelector:
        node.kubernetes.io/instance-type: MACHINE_TYPE
    tolerations:
    - key: TOLERATION_KEY
        operator: Exists
        effect: NoSchedule
    inMemoryVolumeSize: IN_MEMORY_VOLUME_SIZE
    gcsFuseMountOptions:
    - implicit-dirs
    - metadata-cache:negative-ttl-secs:0
    - metadata-cache:ttl-secs:-1
    - metadata-cache:stat-cache-max-size-mb:-1
    - metadata-cache:type-cache-max-size-mb:-1
    - file-cache:max-size-mb:-1
    - file-cache:cache-file-for-range-read:true
    - file-system:kernel-list-cache-ttl-secs:0
    - file-cache:enable-parallel-downloads:true
    - read_ahead_kb=1024
    - write:enable-streaming-writes:true

    Ersetzen Sie Folgendes:

    • MTC_CONFIG_NAME: der Name Ihrer CheckpointConfiguration. Dieser Name ist global für den Cluster und nicht jobspezifisch.
    • GCS_BUCKET: Der Name des Cloud Storage-Bucket, in dem Sie Prüfpunktdaten speichern. Verwenden Sie den Bucket, den Sie im Schritt Cloud Storage-Bucket mit Berechtigungen einrichten eingerichtet haben.

    • MACHINE_TYPE: Der Maschinentyp für die entsprechenden Beschleuniger. Der Wert kann einer der folgenden sein:

      Weitere Informationen zum Ausführen verteilter Arbeitslasten auf GPUs mit GKE finden Sie unter GPUs mit mehreren Instanzen ausführen. Informationen zu TPUs finden Sie unter TPU-Slice-Knotenpool erstellen.

    • TOLERATION_KEY: Mit diesem Feld kann der CSI-Treiber auf Knoten mit übereinstimmenden Markierungen geplant werden. Weitere Informationen zur Funktionsweise von Taints bei verschiedenen Beschleunigertypen finden Sie auf den folgenden Seiten:

    • IN_MEMORY_VOLUME_SIZE: die Größe des In-Memory-Checkpointing-Cache. Geben Sie die Menge und die Einheit an, z. B. 200 Gi. Dieser Wert sollte:

      • Die Größe des lokalen Prüfpunkts für TPUs multipliziert mit 2,2
      • Die Größe des lokalen Prüfpunkts für GPUs mit einem einzelnen Peer multipliziert mit 6,6.

  2. Wenden Sie das Manifest an:

    kubectl apply -f checkpoint.yaml

  3. Prüfen Sie, ob der CSI-Treiber ausgeführt wird:

    kubectl get pod -n gke-managed-checkpointing

    Die Ausgabe sollte in etwa wie unten aussehen. Es gibt mehrere Einträge, einen pro beschleunigtem Knoten.

    NAME                                                          READY   STATUS    RESTARTS   AGE
multitier-driver-e2b033a7-a4e7-496a-87a3-ffd7fcc2e57b-2d4fz   5/5     Running   0          114s

CSI-Treiber für Multi-Tier Checkpointing deinstallieren

Wenn Sie den Multi-Tier Checkpointing-CSI-Treiber entfernen möchten, löschen Sie die CheckpointConfiguration-Ressource. Der Multi-Tier Checkpointing-Controller entfernt den CSI-Treiber von den Knoten. Dadurch werden die RAM-Disks entfernt und Arbeitsspeicher für andere Arbeitslasten freigegeben. Beispiel:

kubectl delete -f checkpoint.yaml

Datenaufbewahrung und Garbage Collection für Cloud Storage-Back-ups verwalten

Sie sind für die Implementierung von Aufbewahrungsrichtlinien für die Cloud Storage-Sicherungen von Checkpoints verantwortlich. Beim Multi-Tier Checkpointing werden Checkpoint-Back-ups nur in Cloud Storage geschrieben. Sie werden nie geändert oder gelöscht.

Viele Open-Source-Tools können die Aufbewahrung und die Garbage Collection verwalten, darunter:

Im folgenden Beispiel wird backup-warden verwendet, wobei das Verzeichnis backup an einem Sicherungsspeicherort gemountet ist, für den Cloud Storage FUSE verwendet wird:

# Add --delete option to actually delete the backups, as is it only shows what would be deleted (dry-run)
backup-warden -p backup \
    --hourly 24 \
    --daily 7 \
    --weekly 5 \
    --monthly always \
    --yearly always \
    --prefer-recent

Manifest des JobSets für die Arbeitslast aktualisieren

Aktualisieren Sie das JobSet-Manifest für Ihren Job, um das große Checkpoint-Volume einzuschließen. Die Details hängen von Ihrer Arbeitslast ab.

Wenn Sie beispielsweise das Beispiel-JobSet aus TPU-Multiplikationen in GKE bereitstellen erweitern möchten, führen Sie die folgenden Schritte aus:

  1. Fügen Sie dem jax-tpu-Container die folgenden Zeilen hinzu.

    volumeMounts:
- name: checkpoint
  mountPath: CHECKPOINT_DIR

    Ersetzen Sie CHECKPOINT_DIR durch den Pfad zu Ihrem Checkpoint-Verzeichnis. An diesem Ort wird replicator.yaml generiert und der Checkpoint-Speichervorgang wird durch Multi-Tier Checkpointing ausgeführt. Weitere Informationen finden Sie unter Checkpointing auf mehreren Ebenen in Ihre Anwendung einbinden.

  2. Fügen Sie dem Feld spec.template.spec der Job-Spezifikation die folgenden Zeilen hinzu.

    volumes:
- name: checkpoint
  csi:
    driver: multitier-checkpoint.csi.storage.gke.io

Multi-Tier Checkpointing in Ihre Anwendung einbinden

Wenn Sie Informationen zu Prüfpunktstandorten und zur Replikationsbereitschaft weitergeben möchten, müssen Sie Ihre Anwendung so ändern, dass sie das folgende Protokoll für die Kommunikation mit Multi-Tier Checkpointing verwendet.

Starten

In diesem Abschnitt werden die ersten Schritte beschrieben, die die Anwendung für die Interaktion mit Multi-Tier Checkpointing ausführen muss.

Der Replicator ist eine Kernkomponente von Multi-Tier Checkpointing und wird auf jedem Knoten als Teil des CSI-Treibers ausgeführt. Der Replicator verwaltet die Checkpoint-Replikation über Speicherebenen hinweg, von der lokalen RAM-Festplatte zu Peer-Knoten und zu externem Speicher wie Cloud Storage.

Die Datei replicator.yaml fungiert als dynamische Steuerungsebene zwischen Ihrem ML-Trainingsjob (Framework-Code) und der Replicator-Komponente. Ihre ML-Anwendung generiert diese Datei programmatisch auf dem lokalen Volume (RAMDisk), auf das sowohl der Trainingsjob als auch der Replicator-Dienst zugreifen können. Dieses Manifest ermöglicht es dem ML-Framework, dem Replicator Laufzeitkonfigurations- und Lebenszyklusverwaltungsanweisungen zu geben, die sich von statischen Infrastrukturparametern (z. B. Cloud Storage-Uploadhäufigkeit) unterscheiden, die bei der Backend-Einrichtung definiert werden.

Ein konkretes Beispiel für diese Interaktion finden Sie unter:

  • Das MaxText-Projekt, in dem diese Architektur für JAX auf Cloud TPU verwendet wird.
  • Das PyTorch-Referenzbeispiel, in dem diese Architektur mit PyTorch und NVIDIA NeMO auf GPUs verwendet wird.

Ihre Anwendung sollte beim Start folgende Schritte ausführen:

  1. Warten Sie, bis die Datei replicator.yaml nicht mehr vorhanden ist. Das bedeutet, dass der Replicator von Ihrer Anwendung konfiguriert werden kann. Die Datei replicator.yaml wird am Speicherort CHECKPOINT_DIR generiert, den Sie im Abschnitt JobSet-Manifest für die Arbeitslast aktualisieren konfiguriert haben.

    Wenn der Job zum Trainieren des Modells zum ersten Mal erstellt wird, ist die Datei replicator.yaml nicht vorhanden und Ihre Anwendung kann sofort fortfahren. Wenn der Job jedoch neu gestartet wurde (z. B. aufgrund eines Fehlers oder manuellen Eingriffs), verarbeitet das System möglicherweise noch die vorherige Jobinstanz und die replicator.yaml dieser Instanz sind möglicherweise noch auf dem lokalen Volume vorhanden.

  2. Ihre Anwendung oder Ihr ML-Job erstellt die Datei replicator.yaml mit einer Konfiguration, die in etwa so aussieht.

    Orbax

    job-name: orbax
framework: orbax
assume-data-parallelism: 3
node-rank: 0
nodes: 32
peer-ranks: [1, 16] or peers-per-node: 2
backup-interval-minutes: 30

    PyTorch

    job-name: nemo
framework: pytorch.distributed
node-rank: 0
nodes: 32
peer-ranks: [1, 16] or peers-per-node: 2
backup-interval-minutes: 30

    Diese Beispielkonfiguration enthält die folgenden Felder:

    • name: Der Name des Trainingsjobs.
    • framework: Das vom Trainingsjob verwendete ML-Framework.
    • node-rank: Die eindeutige Kennung des aktuellen Knotens im verteilten Trainingsjob. Dies ist der Knotenrang des Knotens, der diese Datei erstellt. Jeder Knoten, der am Lauf beteiligt ist, hat einen eigenen Rang.
    • nodes: Die Gesamtzahl der Knoten, die am verteilten Trainingsjob beteiligt sind. Dieser Wert stammt aus den Metadaten des Pods. Der ML-Trainingsjob kann diesen Wert ebenfalls abrufen.
    • peer-ranks oder peers-per-node: zwei alternative Möglichkeiten, die Replikationstopologie anzugeben. Nur einer dieser beiden Parameter sollte vorhanden sein.
      • peer-ranks: Explizite Ränge von Peerknoten, auf die die Prüfpunktdaten des aktuellen Knotens repliziert werden sollen. So lässt sich genau steuern, welche Knoten als Replikationspartner dienen.
      • peers-per-node: Die Anzahl der Peer-Knoten pro Knoten, die der Replicator automatisch für die Replikation auswählen soll.
    • backup-interval-minutes: Die Häufigkeit, in Minuten, mit der Prüfpunkte in Cloud Storage gesichert werden. Wir empfehlen, diesen Wert auf mindestens 30 Minuten festzulegen.

  3. Warten Sie, bis die neue replicator.yaml-Datei vom System gelöscht wurde. Das bedeutet, dass der Replikator neu gestartet wurde und die Bereinigung durchgeführt hat. Mit diesem Schritt können Sie vermeiden, dass auf dem lokalen Volume veraltete oder temporäre Dateien vorhanden sind, wenn Ihre Anwendung die Schritte im nächsten Abschnitt ausführt.

Aus dem letzten bekannten guten (LKG) Prüfpunkt wiederherstellen

  1. Nach der Initialisierung des Replikators wird durch Multi-Tier Checkpointing ein symbolischer Link pro TPU- oder GPU-Worker erstellt. Diese symbolischen Links werden im selben bereitgestellten lokalen Volume wie die Datei replicator.yaml erstellt, in der der Job Checkpoints speichert.

    Die symbolischen Links haben das Format <job-name>-s{step}-n<node-rank>-w<worker-index>.restore.

  2. Stellen Sie jeden Worker aus der entsprechenden .restore-Datei wieder her. Ein Beispiel finden Sie im nächsten Abschnitt unter „Orbax replicated checkpoint manager“.

Checkpoint speichern

Ihre Anwendung führt diese Schritte mehrmals aus, während der Trainingsjob ausgeführt wird. Die Speichervorgänge erfolgen am Speicherort CHECKPOINT_DIR, den Sie im JobSet-Manifest für die Arbeitslast aktualisieren konfiguriert haben.

Orbax

Orbax-Prüfpunkte erstellen Das Verzeichnis ist nach der Schrittnummer benannt. Der Replikator erkennt das neu erstellte Prüfpunktverzeichnis, führt bei Bedarf die Replikation oder Sicherung durch und bereinigt automatisch.

Weitere Informationen zur Verwendung des Orbax-Replicator-Checkpoint-Managers finden Sie in der Datei „MaxtTest“ checkpointing. Ein Beispiel für die Interaktion mit dem Replikator-Dienst finden Sie in der MaxText-Datei max_utils.

PyTorch

Verwenden Sie InClusterLocalCheckpointIO als benutzerdefiniertes pytorch_lightning.CheckpointIO, um die korrekte verteilte Prüfpunktsetzung mit lokalem Speicher zu ermöglichen. Mit dem folgenden Beispielbefehl wird die mehrstufige Sicherung mit einer Referenzimplementierung aktiviert, die auf dem NVIDIA NeMo-Framework basiert:

torchrun train.py <other_train_flags> \
    --local-ckpt-dir=CHECKPOINT_DIR \
    --local-ckpt-interval=20 \
    --job-name=JOB_NAME \
    --enable-high-scale-ckpt

Ersetzen Sie Folgendes:

  • CHECKPOINT_DIR: der Pfad zu Ihrem Checkpoint-Verzeichnis.
  • JOB_NAME: Der Name der Arbeitslast Ihres Trainingsjobs.

Clusterupgrades

Bei Clusterupgrades können Sie Ihr CheckpointConfiguration-Objekt entweder vor oder nach dem Upgrade löschen und neu erstellen. Diese Aktion ist erforderlich, da das DaemonSet für den Node-Checkpointing-Treiber, das dynamisch von diesem Objekt bereitgestellt wird, nicht automatisch aktualisiert wird.

Wenn Sie die DaemonSet-Spezifikation beibehalten möchten, müssen Sie nichts weiter tun.

Fehlerbehebung

Dieser Abschnitt enthält Hinweise zur Fehlerbehebung bei Problemen mit Multi-Tier Checkpointing. Allgemeine Informationen zur Fehlerbehebung bei Speicherproblemen finden Sie unter Fehlerbehebung bei Cloud Storage in GKE.

Checkpointing auf mehreren Ebenen nicht aktiviert

Der folgende Fehler weist darauf hin, dass Multi-Tier Checkpointing in Ihrem Cluster nicht aktiviert ist:

error: unable to recognize "checkpoint.yaml": no matches for kind "CheckpointConfiguration" in version "checkpointing.gke.io/v1"

Dieser Fehler kann auftreten, nachdem Sie im Schritt CheckpointConfiguration erstellen kubectl apply -f checkpoint.yaml ausgeführt haben.

Prüfen Sie mit dem folgenden Befehl, ob Sie Multi-Tier Checkpointing in Ihrem Cluster aktiviert haben, um dieses Problem zu beheben:

gcloud container clusters describe CLUSTER_NAME \
    --project PROJECT_ID
    --location CLUSTER_LOCATION

Wenn die mehrstufige Sicherung aktiviert ist, sollte die Ausgabe in etwa so aussehen:

addonsConfig:
  gcePersistentDiskCsiDriverConfig:
    enabled: true
  gcsFuseCsiDriverConfig:
    enabled: true
  highScaleCheckpointingConfig:
    enabled: true
  kubernetesDashboard:
    disabled: true
  networkPolicyConfig:
    disabled: true

Wenn Multi-Tier Checkpointing nicht aktiviert ist, aktualisieren Sie Ihren Cluster, um Multi-Tier Checkpointing zu aktivieren.

CSI-Treiber für mehrstufige Prüfpunkte kann Volumes nicht bereitstellen

Dieses Problem kann auftreten, wenn der CSI-Treiber das Cloud Storage-Volume nicht bereitstellen kann. Es kann mehrere Zeilen geben, die dieser ähneln.

kubectl get pod -n gke-managed-checkpointing
NAME                                                          READY   STATUS     RESTARTS   AGE
multitier-driver-14694e4d-774f-4104-8bba-f0bd82fd7557-5vxr9   0/5     Init:0/1   0          6m32s

Prüfen Sie zur Behebung dieses Problems die CSI-Treiber-Pod-Ereignisse, wie im folgenden Beispiel gezeigt:

kubectl describe pod multitier-driver-14694e4d-774f-4104-8bba-f0bd82fd7557-5vxr9 -n gke-managed-checkpointing

Events:
  Type     Reason       Age                 From               Message
  ----     ------       ----                ----               -------
  Normal   Scheduled    17m                 default-scheduler  Successfully assigned gke-managed-checkpointing/multitier-driver-14694e4d-774f-4104-8bba-f0bd82fd7557-5vxr9 to gke-my-cluster-default-pool-353c773f-6d8q
  Warning  FailedMount  82s (x16 over 17m)  kubelet            MountVolume.SetUp failed for volume "gcs" : rpc error: code = PermissionDenied desc = failed to get GCS bucket "checkpointing-test-bucket": googleapi: Error 403: Caller does not have storage.objects.list access to the Google Cloud Storage bucket. Permission 'storage.objects.list' denied on resource (or it may not exist)., forbidden

Wenn das Problem aufgrund des Cloud Storage-Bucket-Fehlers PermissionDenied auftritt, wie im Beispiel gezeigt, können Sie das Problem beheben, indem Sie Berechtigungen richtig einrichten.

Nächste Schritte