Einige oder alle Informationen auf dieser Seite gelten möglicherweise nicht für Cloud de Confiance von S3NS. Weitere Informationen finden Sie unter Unterschiede zu Google Cloud.

Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

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

Autopilot Standard

Mit dem GKE Volume Populator können Daten in GKE-Cluster übertragen werden. Während der Datenübertragung können jedoch Probleme auftreten, die verhindern, dass PersistentVolumeClaims (PVCs) erstellt oder Daten korrekt eingefügt werden.

In diesem Dokument erfahren Sie, wie Sie häufige Probleme bei der Verwendung des GKE Volume Populator beheben. Sie lernen, wie Sie Probleme bei der Datenübertragung beheben, indem Sie den Komponentenstatus prüfen, Konfigurationen validieren und Ressourcen- oder Berechtigungsfehler beheben.

Diese Informationen sind wichtig für Anwendungsentwickler und Plattformadministratoren und ‑operatoren, die den GKE Volume Populator verwenden, um Daten in ihre GKE-Volumes einzufügen. Weitere Informationen zu den häufig verwendeten Rollen und Beispielaufgaben, auf die wir in den Cloud de Confiance by S3NS Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und ‑aufgaben.

Temporäre Kubernetes-Ressourcen prüfen

So verwendet der GKE Volume Populator temporäre Ressourcen:

Im Namespace gke-managed-volumepopulator wird ein temporärer PVC erstellt.
Für jede an der Übertragung beteiligte Zone werden im Namespace Ihres PVC ein Übertragungsjob, PVs und PVCs erstellt.
Nach Abschluss der Datenübertragung entfernt der GKE Volume Populator automatisch alle diese temporären Ressourcen.

So prüfen Sie die temporären Ressourcen:

Speichern Sie die 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.

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}

Prüfen Sie den temporären PVC im Namespace gke-managed-volumepopulator:
```
kubectl describe pvc ${TEMP_PVC} -n gke-managed-volumepopulator
```

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

Prüfen Sie die temporären PVCs:

kubectl describe pvc "${TEMP_PVC_LIST[0]}" -n $NAMESPACE

Der 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
```

Prüfen Sie den Übertragungsjob:

kubectl describe job $TRANSFER_JOB -n $NAMESPACE

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

Prüfen Sie den Pod:
```
kubectl describe pod $TRANSFER_POD -n $NAMESPACE
```
Wenn Sie einen PVC für mehrere Zonen erstellen, erstellt der GKE Volume Populator für jede angegebene Zone separate temporäre PVCs und die Ressourcen des Übertragungsjobs. Wenn Sie die Ressourcen für jede an der Übertragung beteiligte Zone prüfen möchten, ersetzen Sie die 0 des Index 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 Übertragungs-Pods sicher auf Cloud de Confiance by S3NS Dienste zugreifen. Wenn sich die Übertragungs-Pods nicht bei authentifizieren können Cloud de Confiance by S3NS, prüfen Sie, ob die Workload Identity-Föderation für GKE in Ihrem Cluster aktiviert ist.

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 Compute-Region oder ‑Zone Ihres Clusters.
- PROJECT_ID: Ihre Cloud de Confiance Projekt-ID.
Suchen Sie in der Befehlsausgabe nach Folgendem:
```
PROJECT_ID.s3ns.svc.id.goog
```
Wenn workloadIdentityConfig in der Ausgabe fehlt, aktivieren Sie die Workload Identity-Föderation 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 die Bucket-URI hat, die in der GCPDatasource-Ressource angegeben ist, schlägt der Übertragungsjob fehl. Der Fehler sieht möglicherweise so aus:

ERROR: (gcloud.storage.cp) [test-gke-dev.s3ns.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.s3ns.svc.id.goog which is the active account specified by the [core/account] property.

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

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

Ersetzen Sie Folgendes:

GCS_BUCKET: Name Ihres Cloud Storage-Bucket.
PROJECT_NUMBER: Ihre Cloud de Confiance Projektnummer.
PROJECT_ID: Ihre Cloud de Confiance 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 innerhalb weniger Minuten behoben werden, nachdem die automatische Knotenbereitstellung einen neuen Knoten hochskaliert hat.

Übertragungs-Pod ist lange Zeit `Pending`

Im 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:

Beschreiben Sie den 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

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:

Wenn die Meldung NotTriggerScaleUp angezeigt wird, prüfen Sie, ob die automatische Knotenbereitstellung in Ihrem Cluster 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 Compute-Region oder ‑Zone Ihres Clusters.
Wenn die Ausgabe „False“ lautet, 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-a oder us-central1.
- PROJECT_ID: Ihre Cloud de Confiance 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 der automatisch bereitzustellenden vCPUs. Beispiel: 100. Dieses Limit ist die Summe der CPU-Ressourcen in allen vorhandenen manuell erstellten Knotenpools und allen Knotenpools, die von GKE automatisch erstellt werden können.
- MAXIMUM_MEMORY: die maximale Menge an Arbeitsspeicher, die automatisch bereitgestellt werden soll. Beispiel: 1000. Dieses Limit ist die Summe der Arbeitsspeicherressourcen in allen vorhandenen manuell erstellten Knotenpools und allen Knotenpools, die von GKE automatisch erstellt werden können.
Wenn die automatische Knotenbereitstellung aktiviert ist, prüfen Sie, ob die automatische Knotenbereitstellung über genügend Autoscaling resourceLimits verfügt, um den Übertragungsjob hochzuskalieren. Der Übertragungsjob verwendet standardmäßig 24 vCPUs.
```
gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --format="value(autoscaling.resourceLimits)"
```
Ersetzen Sie Folgendes:
- CLUSTER_NAME: der Name Ihres Clusters.
- LOCATION: die Compute-Region oder ‑Zone Ihres Clusters.
Die Ausgabe sieht etwa so aus:
```
{'maximum': '1000000000', 'resourceType': 'cpu'};{'maximum': '1000000000', 'resourceType': 'memory'};
```
Wenn die automatische Knotenbereitstellung nicht über genügend Autoscaling-Limits verfügt, aktualisieren Sie den Cluster mit der richtigen Konfiguration.
```
gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --enable-autoprovisioning \
    --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-a oder us-central1.
- PROJECT_ID: Ihre Cloud de Confiance by S3NS Projekt-ID.
- MAXIMUM_CPU: die maximale Anzahl der automatisch bereitzustellenden vCPUs. Beispiel: 100. Dieses Limit ist die Summe der CPU-Ressourcen in allen vorhandenen manuell erstellten Knotenpools und allen Knotenpools, die von GKE automatisch erstellt werden können.
- MAXIMUM_MEMORY: die maximale Menge an Arbeitsspeicher, die automatisch bereitgestellt werden soll. Beispiel: 1000. Dieses Limit ist die Summe der Arbeitsspeicherressourcen in allen vorhandenen manuell erstellten Knotenpools und allen Knotenpools, die von GKE automatisch erstellt werden können.
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
```
Wenn der Knoten, den Sie für den Übertragungsjob erstellt haben, nicht in der Ausgabe aufgeführt ist, fügen Sie dem Knoten das Compute-Klassenlabel 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.

Fehler `GCE quota exceeded`

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

Node scale up in zones us-west1-b associated with this pod failed: GCE quota exceeded. Pod is at risk of not being scheduled.

Folgen Sie der Anleitung unter Temporäre Kubernetes-Ressourcen prüfen, um den Übertragungs-Pod zu prüfen.
Erhöhen Sie das Kontingent oder löschen Sie vorhandene Ressourcen, die eine Hochskalierung verhindern könnten, um den Fehler zu beheben. Weitere Informationen finden Sie unter Kontingentfehler beheben.

Fehler `HDML_TOTAL_THROUGHPUT` für Hyperdisk ML überschritten

Wenn der temporäre PVC im Namespace gke-managed-volumepopulator das Hyperdisk ML-Volume nicht bereitstellen kann, wurde möglicherweise das regionale Kontingent für die Erstellung des neuen Hyperdisk ML-Volumes für die Datenübertragung überschritten.

Prüfen Sie die Ereignislogs, die mit dem temporären PVC verknüpft sind, der vom GKE Volume Populator erstellt wurde, um zu bestätigen, dass die Bereitstellung des Hyperdisk ML-Volumes aufgrund eines Problems mit dem regionalen Kontingent fehlgeschlagen ist. Gehen Sie so vor:

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.

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

Suchen Sie in den PVC-Ereignissen nach dem QUOTA_EXCEEDED error, der 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:

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

Kein Speicherplatz mehr auf dem Gerät

Wenn die Fehlermeldung No space left on device auf Ihrem PVC angezeigt wird, ist das Hyperdisk ML-Volume voll und es können keine weiteren Daten darauf geschrieben werden. Der Fehler sieht möglicherweise so aus:

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 den PVC, erhöhen Sie den Wert für das Feld spec.resources.requests.storage im PVC-Manifest und erstellen Sie den PVC neu, um die Übertragung noch einmal zu starten, um dieses Problem zu beheben.

Nächste Schritte

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