Résoudre les problèmes de transfert de données liés à GKE Volume Populator

Ce guide explique comment résoudre les problèmes courants qui surviennent lors du transfert de données vers des clusters GKE à l'aide de GKE Volume Populator. Il vous guide dans le débogage des problèmes liés à la création de PersistentVolumeClaim (PVC) et de PersistentVolume (PV), aux performances des disques et à l'exécution des jobs de transfert de données.

Inspecter les ressources Kubernetes temporaires

Voici comment GKE Volume Populator utilise les ressources temporaires :

  1. Un PVC temporaire est créé dans l'espace de noms gke-managed-volumepopulator.
  2. Pour chaque zone impliquée dans le transfert, une tâche de transfert, des PV et des PVC sont créés dans l'espace de noms de votre PVC.
  3. Une fois le transfert de données terminé, GKE Volume Populator supprime automatiquement toutes ces ressources temporaires.

Pour inspecter les ressources temporaires, procédez comme suit :

  1. Stockez les variables d'environnement :

    export PVC_NAME=PVC_NAME
export NAMESPACE=NAMESPACE

    Remplacez les valeurs suivantes :

    • PVC_NAME : nom de votre ressource PersistentVolumeClaim.
    • NAMESPACE : espace de noms dans lequel vos charges de travail sont exécutées.

  2. Vérifiez l'état :

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

  3. Inspectez la PVC temporaire dans l'espace de noms gke-managed-volumepopulator :

    kubectl describe pvc ${TEMP_PVC} -n gke-managed-volumepopulator

  4. Obtenez les noms des PVC temporaires dans votre espace de noms :

    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. Inspectez les PVC temporaires :

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

  6. GKE Volume Populator crée un job de transfert dans chaque zone (un seul dans le cas d'un volume Hyperdisk ML à zone unique et plusieurs dans le cas de volumes Hyperdisk ML multizones). Obtenez le nom du job de transfert à l'aide de la commande suivante :

    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. Inspectez le job de transfert :

    kubectl describe job $TRANSFER_JOB -n $NAMESPACE

  8. Récupérez le nom du pod à partir du job de transfert :

    export TRANSFER_POD=$(kubectl get pods -n "$NAMESPACE" -l "job-name=$TRANSFER_JOB" -o jsonpath='{.items[0].metadata.name}')

echo $TRANSFER_POD

  9. Inspectez le pod :

    kubectl describe pod $TRANSFER_POD -n $NAMESPACE

    Si vous créez un PVC sur plusieurs zones, le Volume Populator GKE crée des PVC temporaires distincts et des ressources de job de transfert pour chaque zone spécifiée. Pour inspecter les ressources de chaque zone impliquée dans le transfert, remplacez l'0 de l'index de TEMP_PVC_LIST par d'autres nombres.

Vérifier si la fédération d'identité de charge de travail est activée

La fédération d'identité de charge de travail permet aux pods de transfert d'accéder aux services Trusted Cloud by S3NS de manière sécurisée. Si les pods de transfert ne parviennent pas à s'authentifier auprès de Trusted Cloud by S3NS, vérifiez que la fédération d'identité de charge de travail pour GKE est activée sur votre cluster.

  1. Pour vérifier si workloadIdentityConfig est activé sur votre cluster, exécutez la commande suivante :

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

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster
    • LOCATION : région ou zone de calcul de votre cluster.
    • PROJECT_ID : ID de votre projet Trusted Cloud .

  2. Recherchez le résultat suivant dans la commande :

    PROJECT_ID.svc.id.goog

  3. Si workloadIdentityConfig est absent du résultat, activez Workload Identity Federation pour GKE.

Chemin de transfert non valide

Si vous rencontrez une erreur semblable à la suivante, cela signifie que le chemin de transfert spécifié dans la ressource GCPDatasource est incorrect et que le transfert échouera.

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

Pour résoudre ce problème, supprimez la ressource GCPDatasource, mettez à jour le champ uri avec la valeur correcte, puis recréez la ressource.

Autorisation insuffisante pour accéder au bucket

Si le compte de service Kubernetes n'a pas accès à l'URI du bucket spécifié dans la ressource GCPDatasource, le job de transfert échouera. L'erreur peut ressembler à l'exemple suivant :

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.

Pour résoudre le problème, accordez les autorisations nécessaires pour transférer les données du bucket vers le disque.

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"

Remplacez les éléments suivants :

  • GCS_BUCKET : nom de votre bucket Cloud Storage.
  • PROJECT_NUMBER : numéro de votre projet Trusted Cloud .
  • PROJECT_ID : ID de votre projet Trusted Cloud .
  • NAMESPACE : espace de noms dans lequel vos charges de travail sont exécutées.
  • KSA_NAME : nom de votre compte de service Kubernetes.
  • ROLE : rôle IAM qui fournit les autorisations nécessaires pour accéder au bucket. Par exemple, utilisez roles/storage.objectViewer pour accorder un accès en lecture seule au bucket.

Erreur : error generating accessibility requirements

L'erreur temporaire suivante peut s'afficher lorsque vous vérifiez le PVC dans l'espace de noms gke-managed-volumepopulator :

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

Si vous utilisez un cluster GKE Autopilot ou un cluster standard avec le provisionnement automatique des nœuds activé, cette erreur peut se produire, car aucun nœud n'est Ready dans votre cluster. L'erreur devrait se résoudre d'elle-même en quelques minutes après que le provisionnement automatique de nœuds a mis à l'échelle un nouveau nœud.

Le pod de transfert est Pending depuis longtemps

L'événement PVC peut indiquer que l'état du pod de transfert est Pending pendant une longue période.

Pour vérifier les événements de la tâche de transfert et déterminer si la planification a échoué, procédez comme suit :

  1. Décrivez la PVC :

    kubectl describe pvc $PVC_NAME -n $NAMESPACE

    Le résultat ressemble à ce qui suit :

    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. Pour inspecter le pod de transfert, suivez la procédure décrite dans Inspecter les ressources Kubernetes temporaires.

    Le résultat ressemble à ce qui suit :

    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. Si le message NotTriggerScaleUp s'affiche, vérifiez si le provisionnement automatique des nœuds est activé dans votre cluster :

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

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster
    • LOCATION : région ou zone de calcul de votre cluster.

  4. Si la sortie affiche "False", activez le provisionnement automatique des nœuds à l'aide de la commande suivante :

    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

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster que vous mettez à jour pour activer le provisionnement automatique des nœuds.
    • LOCATION : zone ou région de calcul de votre cluster. Par exemple, us-central1-a ou us-central1.
    • PROJECT_ID : ID de votre projet Trusted Cloud by S3NS .
    • MINIMUM_CPU : nombre minimal de processeurs virtuels à provisionner automatiquement. Exemple :10
    • MINIMUM_MEMORY : quantité minimale de mémoire en Gio pour le provisionnement automatique. Exemple :200
    • MAXIMUM_CPU : nombre maximal de processeurs virtuels à provisionner automatiquement. Exemple :100 Cette limite correspond au total des ressources de processeur de tous les pools de nœuds existants créés manuellement et de tous les pools de nœuds que GKE peut créer automatiquement.
    • MAXIMUM_MEMORY : quantité maximale de mémoire à provisionner automatiquement. Exemple :1000 Cette limite correspond au total des ressources mémoire de tous les pools de nœuds existants créés manuellement et de tous les pools de nœuds que GKE peut créer automatiquement.

  5. Si le provisionnement automatique des nœuds est activé, vérifiez que l'autoscaling du provisionnement automatique des nœuds est suffisantresourceLimits pour augmenter la taille du job de transfert. Le job de transfert utilise 24 processeurs virtuels par défaut.

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

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster
    • LOCATION : région ou zone de calcul de votre cluster.

    Le résultat ressemble à ce qui suit :

    {'maximum': '1000000000', 'resourceType': 'cpu'};{'maximum': '1000000000', 'resourceType': 'memory'};

  6. Si le provisionnement automatique des nœuds ne dispose pas de limites d'autoscaling suffisantes, mettez à jour le cluster avec la configuration appropriée.

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

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster que vous mettez à jour pour activer le provisionnement automatique des nœuds.
    • LOCATION : zone ou région de calcul de votre cluster. Par exemple, us-central1-a ou us-central1.
    • PROJECT_ID : ID de votre projet Trusted Cloud by S3NS .
    • MAXIMUM_CPU : nombre maximal de processeurs virtuels à provisionner automatiquement. Exemple :100 Cette limite correspond au total des ressources de processeur de tous les pools de nœuds existants créés manuellement et de tous les pools de nœuds que GKE peut créer automatiquement.
    • MAXIMUM_MEMORY : quantité maximale de mémoire à provisionner automatiquement. Exemple :1000 Cette limite correspond au total des ressources mémoire de tous les pools de nœuds existants créés manuellement et de tous les pools de nœuds que GKE peut créer automatiquement.

  7. Pour les clusters Standard sans provisionnement automatique des nœuds activé, vérifiez que le nœud que vous avez créé pour le job de transfert possède le libellé de classe de calcul requis :

    kubectl get node -l cloud.google.com/compute-class=gcs-to-hdml-compute-class

  8. Si le nœud que vous avez créé pour le job de transfert ne figure pas dans le résultat, ajoutez le libellé de classe de calcul gcs-to-hdml-compute-class au nœud :

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

    Remplacez NODE_NAME par le nom du nœud auquel vous souhaitez ajouter le libellé de classe de calcul.

GCE quota exceeded erreur

Un message d'erreur semblable à celui-ci peut s'afficher lorsque vous vérifiez le pod pour le job de transfert :

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. Pour inspecter le pod de transfert, suivez la procédure décrite dans Inspecter les ressources Kubernetes temporaires.

  2. Pour résoudre cette erreur, augmentez le quota ou supprimez les ressources existantes qui pourraient empêcher le scaling-up. Pour en savoir plus, consultez Résoudre les erreurs de quota.

Erreur "Hyperdisk ML HDML_TOTAL_THROUGHPUT dépassé"

Si le PVC temporaire dans l'espace de noms gke-managed-volumepopulator ne parvient pas à provisionner le volume Hyperdisk ML, il est possible que le quota régional pour la création du nouveau volume Hyperdisk ML pour votre transfert de données soit dépassé.

Pour confirmer que le provisionnement du volume Hyperdisk ML a échoué en raison d'un problème de quota régional, inspectez les journaux d'événements associés au PVC temporaire créé par le programme de remplissage de volume GKE. Procédez comme suit :

  1. Stockez les variables d'environnement pertinentes :

    export PVC_NAME=PVC_NAME
export NAMESPACE=NAMESPACE

    Remplacez les valeurs suivantes :

    • PVC_NAME : nom de votre ressource PersistentVolumeClaim.
    • NAMESPACE : espace de noms dans lequel vos charges de travail sont exécutées.

  2. Vérifiez l'état du PVC temporaire :

    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. Consultez les événements du PVC pour trouver le QUOTA_EXCEEDED error, qui ressemble à ce qui suit :

    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

Pour remédier à ce problème :

  1. Demandez un quota supplémentaire pour créer des volumes Hyperdisk ML dans votre projet.
  2. Supprimez tous les disques Hyperdisk ML inutilisés de votre projet.

Aucun espace restant sur le dispositif

Si le message d'erreur No space left on device s'affiche sur votre PVC, cela signifie que le volume Hyperdisk ML est plein et qu'aucune autre donnée ne peut y être écrite. L'erreur peut ressembler à l'exemple suivant :

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

Pour résoudre ce problème, supprimez votre PVC, augmentez la valeur du champ spec.resources.requests.storage dans le fichier manifeste de votre PVC, puis recréez le PVC pour relancer le processus de transfert.

Étapes suivantes

  • Si vous ne trouvez pas de solution à votre problème dans la documentation, consultez Obtenir de l'aide.