Fehlerbehebung bei Problemen mit der Datenübertragung für GKE Volume Populator

In diesem Leitfaden wird beschrieben, wie Sie häufige Probleme beheben, die beim Übertragen von Daten in GKE-Cluster mit GKE Volume Populator auftreten. Sie werden durch die Fehlerbehebung von Problemen im Zusammenhang mit der Erstellung von PersistentVolumeClaim (PVC) und PersistentVolume (PV), der Datenträgerleistung und der Ausführung von Datenübertragungsjobs geführt.

Temporäre Kubernetes-Ressourcen prüfen

So verwendet GKE Volume Populator temporäre Ressourcen:

  1. Im Namespace gke-managed-volumepopulator wird ein temporärer PVC erstellt.
  2. Für jede Zone, die am Transfer beteiligt ist, werden ein Transferjob, PVs und PVCs im Namespace Ihres PVCs erstellt.
  3. Nach der Datenübertragung entfernt GKE Volume Populator automatisch alle diese temporären Ressourcen.

So prüfen Sie die temporären Ressourcen:

  1. Umgebungsvariablen speichern:

    export PVC_NAME=PVC_NAME
    export NAMESPACE=NAMESPACE
    

    Ersetzen Sie die folgenden Werte:

    • PVC_NAME: der Name Ihrer PersistentVolumeClaim-Ressource.
    • NAMESPACE: Der Namespace, in dem Ihre Arbeitslasten ausgeführt werden.
  2. Prüfen Sie den 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. Sehen Sie sich den temporären PVC im Namespace gke-managed-volumepopulator an:

    kubectl describe pvc ${TEMP_PVC} -n gke-managed-volumepopulator
    
  4. Rufen Sie die Namen der temporären PVCs in Ihrem Namespace ab:

    export TEMP_PVC_LIST=($(kubectl get pvc -n "$NAMESPACE" -o json | grep -Eo "\"name\":\s*\"$TEMP_PVC[^\"]*\"" | awk -F'"' '{print $4}'))
    
    for pvc in "${TEMP_PVC_LIST[@]}"; do
      echo "$pvc"
    done
    
  5. Temporäre PVCs prüfen:

    kubectl describe pvc "${TEMP_PVC_LIST[0]}" -n $NAMESPACE
    
  6. GKE Volume Populator erstellt in jeder Zone einen Übertragungsjob (einen bei einem Hyperdisk ML-Volume für eine einzelne Zone und mehrere bei Hyperdisk ML-Volumes für mehrere Zonen). Rufen Sie den Namen des Übertragungsjobs mit dem folgenden Befehl ab:

    export TRANSFER_JOB=$(kubectl get pvc "${TEMP_PVC_LIST[0]}" -n "$NAMESPACE" -o "jsonpath={.metadata.annotations['volume-populator\.datalayer\.gke\.io/pd-transfer-requestid']}")
    
    echo $TRANSFER_JOB
    
  7. Überprüfen Sie den Übertragungsjob:

    kubectl describe job $TRANSFER_JOB -n $NAMESPACE
    
  8. Rufen Sie den Pod-Namen aus dem Übertragungsjob ab:

    export TRANSFER_POD=$(kubectl get pods -n "$NAMESPACE" -l "job-name=$TRANSFER_JOB" -o jsonpath='{.items[0].metadata.name}')
    
    echo $TRANSFER_POD
    
  9. Prüfen Sie den Pod:

    kubectl describe pod $TRANSFER_POD -n $NAMESPACE
    

    Wenn Sie einen PVC über mehrere Zonen hinweg erstellen, erstellt der GKE Volume Populator separate temporäre PVCs und die Transfer-Job-Ressourcen für jede angegebene Zone. Wenn Sie die Ressourcen für jede am Transfer beteiligte Zone prüfen möchten, ersetzen Sie den Index 0 für TEMP_PVC_LIST durch andere Zahlen.

Prüfen, ob die Workload Identity-Föderation aktiviert ist

Mit der Workload Identity-Föderation können Transfer-Pods sicher auf Trusted Cloud by S3NS -Dienste zugreifen. Wenn sich die Übertragungs-Pods nicht bei Trusted Cloud by S3NSauthentifizieren können, prüfen Sie, ob die Identitätsföderation von Arbeitslasten für GKE in Ihrem Cluster aktiviert ist.

  1. Führen Sie den folgenden Befehl aus, um zu prüfen, ob workloadIdentityConfig in Ihrem Cluster aktiviert ist:

    gcloud container clusters describe CLUSTER_NAME
    --location=LOCATION \
    --project=PROJECT_ID \
    --format="value(workloadIdentityConfig)"
    

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: Der Name Ihres Clusters.
    • LOCATION: die Computing-Region oder ‑Zone Ihres Clusters.
    • PROJECT_ID: Ihre Trusted Cloud -Projekt-ID
  2. Suchen Sie in der Befehlsausgabe nach Folgendem:

    PROJECT_ID.svc.id.goog
    
  3. Wenn workloadIdentityConfig in der Ausgabe fehlt, aktivieren Sie die Identitätsföderation von Arbeitslasten für GKE.

Ungültiger Übertragungspfad

Wenn ein Fehler wie der folgende auftritt, ist der in der GCPDatasource-Ressource angegebene Übertragungspfad falsch und die Übertragung schlägt fehl.

ERROR: (gcloud.storage.cp) The following URLs matched no objects or files:
gs://datasets-pd/llama2-7b-hfa/

Löschen Sie die GCPDatasource-Ressource, aktualisieren Sie das Feld uri mit dem richtigen Wert und erstellen Sie die Ressource neu, um dieses Problem zu beheben.

Unzureichende Berechtigungen für den Zugriff auf den Bucket

Wenn das Kubernetes-Dienstkonto keinen Zugriff auf den Bucket-URI hat, der in der GCPDatasource-Ressource angegeben ist, schlägt der Übertragungsjob fehl. Der Fehler könnte so aussehen:

ERROR: (gcloud.storage.cp) [test-gke-dev.svc.id.goog] does not have permission to access b instance [small-bucket-7] (or it may not exist): 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). This command is authenticated as test-gke-dev.svc.id.goog which is the active account specified by the [core/account] property.

Um das Problem zu beheben, gewähren Sie die erforderlichen Berechtigungen, um Daten aus dem Bucket auf das Laufwerk zu übertragen.

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: Ihre Trusted Cloud -Projektnummer.
  • PROJECT_ID: Ihre Trusted Cloud -Projekt-ID
  • NAMESPACE: Der Namespace, in dem Ihre Arbeitslasten ausgeführt werden.
  • KSA_NAME: Der Name Ihres Kubernetes-Dienstkontos.
  • ROLE: Die IAM-Rolle, die die erforderlichen Berechtigungen für den Zugriff auf den Bucket bietet. Verwenden Sie beispielsweise roles/storage.objectViewer, um Lesezugriff auf den Bucket zu gewähren.

Fehler: error generating accessibility requirements

Möglicherweise wird der folgende vorübergehende Fehler angezeigt, wenn Sie den PVC im Namespace gke-managed-volumepopulator prüfen:

Error: error generating accessibility requirements: no available topology found.

Wenn Sie einen GKE Autopilot-Cluster oder einen Standardcluster mit aktivierter automatischer Knotenbereitstellung verwenden, kann dieser Fehler auftreten, weil in Ihrem Cluster möglicherweise keine Knoten Ready sind. Der Fehler sollte sich innerhalb weniger Minuten beheben, nachdem die automatische Knotenbereitstellung einen neuen Knoten hochskaliert hat.

Der Transfer-Pod wird seit Langem geplant.Pending

In Ihrem PVC-Ereignis wird möglicherweise angezeigt, dass der Status des Übertragungs-Pods lange Zeit Pending ist.

So prüfen Sie die Ereignisse des Übertragungsjobs, um festzustellen, ob die Planung für den Job fehlgeschlagen ist:

  1. Beschreiben Sie das PVC:

    kubectl describe pvc $PVC_NAME -n $NAMESPACE
    

    Die Ausgabe sieht etwa so aus:

    Events:
      Type     Reason             Age                From                Message
      ----     ------             ----               ----                -------
    Normal   TransferInProgress              1s (x2 over 2s)    gkevolumepopulator-populator                                                                      populateCompleteFn: For PVC pd-pvc79 in namespace default, job with request ID populator-job-0b93fec4-5490-4e02-af32-15b16435d559 is still active with pod status as - Phase: Pending
    
  2. Folgen Sie der Anleitung unter Temporäre Kubernetes-Ressourcen prüfen, um den Übertragungs-Pod zu prüfen.

    Die Ausgabe sieht etwa so aus:

    Events:
      Type     Reason             Age                From                Message
      ----     ------             ----               ----                -------
      Warning  FailedScheduling   2m50s              default-scheduler   0/3 nodes are available: 1 Insufficient cpu, 2 node(s) had volume node affinity conflict. preemption: 0/3 nodes are available: 1 No preemption victims found for incoming pod, 2 Preemption is not helpful for scheduling.
      Warning  FailedScheduling   37s (x2 over 39s)  default-scheduler   0/3 nodes are available: 1 Insufficient cpu, 2 node(s) had volume node affinity conflict. preemption: 0/3 nodes are available: 1 No preemption victims found for incoming pod, 2 Preemption is not helpful for scheduling.
      Normal   NotTriggerScaleUp  2m40s              cluster-autoscaler  pod didn't trigger scale-up:
    
  3. Wenn die Meldung NotTriggerScaleUp angezeigt wird, prüfen Sie, ob in Ihrem Cluster die automatische Knotenbereitstellung aktiviert ist:

    gcloud container clusters describe CLUSTER_NAME \
        --location=LOCATION \
        --format="value(autoscaling.enableNodeAutoprovisioning)"
    

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: Der Name Ihres Clusters.
    • LOCATION: die Computing-Region oder ‑Zone Ihres Clusters.
  4. Wenn in der Ausgabe „False“ angezeigt wird, aktivieren Sie die automatische Knotenbereitstellung mit dem folgenden Befehl:

    gcloud container clusters update CLUSTER_NAME \
        --enable-autoprovisioning \
        --location=LOCATION \
        --project=PROJECT_ID \
        --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
    

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: der Name des Clusters, den Sie aktualisieren, um die automatische Knotenbereitstellung zu aktivieren.
    • LOCATION: die Compute-Zone oder ‑Region für Ihren Cluster. Beispiel: us-central1-aoder us-central1
    • PROJECT_ID: Ihre Trusted Cloud by S3NS -Projekt-ID
    • MINIMUM_CPU: die Mindestanzahl der automatisch bereitzustellenden vCPUs. Beispiel: 10.
    • MINIMUM_MEMORY: die Mindestmenge an Arbeitsspeicher in GiB, die automatisch bereitgestellt werden soll. Beispiel: 200.
    • MAXIMUM_CPU: die maximale Anzahl von vCPUs, die automatisch bereitgestellt werden sollen. Beispiel: 100. Dieses Limit ist die Summe der CPU-Ressourcen aller vorhandenen manuell erstellten Knotenpools und aller Knotenpools, die GKE möglicherweise automatisch erstellt.
    • MAXIMUM_MEMORY: die maximale Menge an Arbeitsspeicher, die automatisch bereitgestellt werden soll. Beispiel: 1000. Dieses Limit ist die Summe der Arbeitsspeicherressourcen aller vorhandenen, manuell erstellten Knotenpools und aller Knotenpools, die GKE möglicherweise automatisch erstellt.
  5. Wenn die automatische Knotenbereitstellung aktiviert ist, prüfen Sie, ob die automatische Knotenbereitstellung über genügend Autoscaling-resourceLimits verfügt, um den Übertragungsjob zu skalieren. Für den Übertragungsjob werden standardmäßig 24 vCPUs verwendet.

    gcloud container clusters describe CLUSTER_NAME \
        --location=LOCATION \
        --format="value(autoscaling.resourceLimits)"
    

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: Der Name Ihres Clusters.
    • LOCATION: die Computing-Region oder ‑Zone Ihres Clusters.

    Die Ausgabe sieht etwa so aus:

    {'maximum': '1000000000', 'resourceType': 'cpu'};{'maximum': '1000000000', 'resourceType': 'memory'};
    
  6. Wenn die automatische Knotenbereitstellung nicht über ausreichende Autoscaling-Limits verfügt, aktualisieren Sie den Cluster mit der richtigen Konfiguration.

    gcloud container clusters update CLUSTER_NAME \
        --location=LOCATION \
        --project=PROJECT_ID \
        --max-cpu MAXIMUM_CPU \
        --max-memory MAXIMUM_MEMORY
    

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: der Name des Clusters, den Sie aktualisieren, um die automatische Knotenbereitstellung zu aktivieren.
    • LOCATION: die Compute-Zone oder ‑Region für Ihren Cluster. Beispiel: us-central1-aoder us-central1
    • PROJECT_ID: Ihre Trusted Cloud by S3NS -Projekt-ID
    • MAXIMUM_CPU: die maximale Anzahl von vCPUs, die automatisch bereitgestellt werden sollen. Beispiel: 100. Dieses Limit ist die Summe der CPU-Ressourcen aller vorhandenen manuell erstellten Knotenpools und aller Knotenpools, die GKE möglicherweise automatisch erstellt.
    • MAXIMUM_MEMORY: die maximale Menge an Arbeitsspeicher, die automatisch bereitgestellt werden soll. Beispiel: 1000. Dieses Limit ist die Summe der Arbeitsspeicherressourcen aller vorhandenen, manuell erstellten Knotenpools und aller Knotenpools, die GKE möglicherweise automatisch erstellt.
  7. Prüfen Sie bei Standardclustern ohne aktivierte automatische Knotenbereitstellung, ob der Knoten, den Sie für den Übertragungsjob erstellt haben, das erforderliche Compute-Klassenlabel hat:

    kubectl get node -l cloud.google.com/compute-class=gcs-to-hdml-compute-class
    
  8. Wenn der Knoten, den Sie für den Übertragungsjob erstellt haben, nicht in der Ausgabe aufgeführt ist, fügen Sie dem Knoten das Label für die Compute-Klasse gcs-to-hdml-compute-class hinzu:

    kubectl label node NODE_NAME cloud.google.com/compute-class=gcs-to-hdml-compute-class
    

    Ersetzen Sie NODE_NAME durch den Namen des Knotens, dem Sie das Compute-Klassenlabel hinzufügen möchten.

GCE quota exceeded Fehler

Wenn Sie den Pod für den Übertragungsjob prüfen, wird möglicherweise eine Fehlermeldung wie die folgende angezeigt:

Node scale up in zones us-west1-b associated with this pod failed: GCE quota exceeded. Pod is at risk of not being scheduled.
  1. Folgen Sie der Anleitung unter Temporäre Kubernetes-Ressourcen prüfen, um den Übertragungs-Pod zu prüfen.

  2. Erhöhen Sie das Kontingent oder löschen Sie vorhandene Ressourcen, die möglicherweise das Hochskalieren verhindern, um den Fehler zu beheben. Weitere Informationen finden Sie unter Kontingentfehler beheben.

Fehler „Hyperdisk ML HDML_TOTAL_THROUGHPUT überschritten“

Wenn die Bereitstellung des Hyperdisk ML-Volumes für den temporären PVC im Namespace gke-managed-volumepopulator fehlschlägt, wurde möglicherweise das regionale Kontingent für die Erstellung des neuen Hyperdisk ML-Volumes für die Datenübertragung überschritten.

Wenn Sie bestätigen möchten, dass die Bereitstellung des Hyperdisk ML-Volumes aufgrund eines regionalen Kontingentproblems fehlgeschlagen ist, sehen Sie sich die Ereignisprotokolle an, die dem temporären PVC zugeordnet sind, der vom GKE Volume Populator erstellt wurde. Gehen Sie so vor:

  1. Speichern Sie die relevanten Umgebungsvariablen:

    export PVC_NAME=PVC_NAME
    export NAMESPACE=NAMESPACE
    

    Ersetzen Sie die folgenden Werte:

    • PVC_NAME: der Name Ihrer PersistentVolumeClaim-Ressource.
    • NAMESPACE: Der Namespace, in dem Ihre Arbeitslasten ausgeführt werden.
  2. Prüfen Sie den Status des temporären PVC:

    export PVC_UID=$(kubectl get pvc ${PVC_NAME} -n ${NAMESPACE} -o jsonpath='{.metadata.uid}')
    export TEMP_PVC=prime-$PVC_UID
    echo $TEMP_PVC
    kubectl describe pvc $TEMP_PVC -n gke-managed-volumepopulator
    
  3. Suchen Sie in den PVC-Ereignissen nach dem QUOTA_EXCEEDED error, das in etwa so aussieht:

    Events:
      Type     Reason                Age                 From                                                                                              Message
      ----     ------                ----                ----                                                                                              -------
      Warning  ProvisioningFailed    105s                pd.csi.storage.gke.io_gke-3ef909a7688d424b94a2-d0d9-b185-vm_6a77d057-54e3-415a-8b39-82b666516b6b  failed to provision volume with StorageClass "pd-sc": rpc error: code = Unavailable desc = CreateVolume failed: rpc error: code = Unavailable desc = CreateVolume failed to create single zonal disk pvc-73c69fa8-d23f-4dcb-a244-bcd120a3c221: failed to insert zonal disk: unknown error when polling the operation: rpc error: code = ResourceExhausted desc = operation operation-1739194889804-62dc9dd9a1cae-9d24a5ad-938e5299 failed (QUOTA_EXCEEDED): Quota 'HDML_TOTAL_THROUGHPUT' exceeded.  Limit: 30720.0 in region us-central1
    

So lösen Sie dieses Problem:

  1. Fordern Sie zusätzliches Kontingent an, um neue Hyperdisk ML-Volumes in Ihrem Projekt zu erstellen.
  2. Löschen Sie alle nicht verwendeten Hyperdisk ML-Laufwerke in Ihrem Projekt.

Kein Speicherplatz mehr auf dem Gerät

Wenn Sie die Fehlermeldung No space left on device für Ihren PVC sehen, bedeutet das, dass das Hyperdisk ML-Volume voll ist und keine weiteren Daten darauf geschrieben werden können. Der Fehler könnte so aussehen:

Events:
  Type     Reason                   Age   From                          Message
  ----     ------                   ----  ----                          -------
  Warning  TransferContainerFailed  57m   gkevolumepopulator-populator  populateCompleteFn: For PVC vp-pvc in namespace default, job with request ID populator-job-c2a2a377-6168-4ff1-afc8-c4ca713c43e2 for zone us-central1-c has a failed pod container with message:  on device
ERROR: Failed to download one or more components of sliced download.
ERROR: [Errno 28] No space left on device

Löschen Sie zur Behebung dieses Problems Ihren PVC, erhöhen Sie den Wert für das Feld spec.resources.requests.storage in Ihrem PVC-Manifest und erstellen Sie den PVC neu, um den Übertragungsvorgang noch einmal zu starten.

Nächste Schritte

  • Wenn Sie in der Dokumentation keine Lösung für Ihr Problem finden, lesen Sie den Abschnitt Support erhalten.