Automatiser le transfert de données de Cloud Storage vers un volume Hyperdisk ML à l'aide de GKE Volume Populator

Ce guide explique comment précharger de grandes quantités de données à partir d'un bucket Cloud Storage vers un volume Hyperdisk ML Google Kubernetes Engine (GKE) lors du provisionnement dynamique à l'aide de GKE Volume Populator. Pour en savoir plus, consultez À propos de GKE Volume Populator.

Ce guide s'adresse aux spécialistes du stockage qui créent et attribuent du stockage, et qui gèrent la sécurité et l'accès aux données. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Google Cloud , consultez Rôles utilisateur et tâches courantes de GKE Enterprise.

Gestion des pools de nœuds pour GKE Volume Populator avec Hyperdisk ML

Il est essentiel de dimensionner, provisionner et faire évoluer efficacement les pools de nœuds pour exécuter correctement les jobs de transfert de données créés par GKE Volume Populator afin de remplir les volumes Hyperdisk ML. Vous utilisez une classe de calcul pour définir les exigences des nœuds, telles que le type et la taille de la machine, pour ces tâches de transfert de données spécifiques. Une classe de calcul vous permet de contrôler le coût et les performances du processus de transfert de données. Pour en savoir plus, consultez Avantages des classes de calcul personnalisées.

Pour choisir le cluster le mieux adapté à vos jobs de transfert de données, découvrez comment les classes de calcul fonctionnent avec différents types de clusters pour Hyperdisk ML.

Objectifs

Dans ce guide, vous allez effectuer les tâches suivantes :

Avant de commencer

Assurez-vous d'avoir effectué les tâches suivantes :

  1. Activez les API GKE et Cloud Storage.

    Activer les API

  2. Assurez-vous que la facturation est activée pour votre projetGoogle Cloud .

  3. Téléchargez et installez l'outil de ligne de commande Google Cloud CLI, ou utilisez Cloud Shell pour exécuter les commandes gcloud CLI et kubectl. Cloud Shell est un environnement shell permettant de gérer les ressources hébergées sur Google Cloud. Il est préinstallé avec les outils de ligne de commande gcloud et kubectl.

  4. Définissez une région et une zone par défaut.

  5. Créez ou utilisez un bucket Cloud Storage. Ce guide suppose que vous disposez déjà d'un bucket Cloud Storage contenant les données d'entraînement de votre modèle.

  6. Activez le pilote CSI de disque persistant Compute Engine sur les clusters standards existants pour lesquels le pilote peut avoir été explicitement désactivé. Sur les nouveaux clusters Autopilot et Standard, GKE active le pilote par défaut. Le stockage Hyperdisk ML de destination que vous créez doit être géré par le pilote CSI de disque persistant Compute Engine.

  7. Activez la fédération d'identité de charge de travail pour GKE sur votre cluster. Cela permet au compte de service Kubernetes utilisé par GKE Volume Populator d'accéder au bucket Cloud Storage source. Pour en savoir plus, consultez Configurer les autorisations nécessaires.

Conditions requises

Pour transférer des données à l'aide de GKE Volume Populator, vous devez remplir les conditions suivantes :

  • Votre cluster GKE doit exécuter la version 1.33.2-gke.4780000 ou ultérieure.
  • Votre ressource personnalisée GCPDataSource doit se trouver dans le même espace de noms que votre charge de travail GKE. Les sources de données qui couvrent différents espaces de noms ne sont pas acceptées.
  • Sélectionnez une VM compatible lorsque vous créez votre classe de calcul. Vérifiez que votre projet dispose d'un quota suffisant pour le type de machine que vous sélectionnez.
  • Le nom de classe de calcul gcs-to-hdml-compute-class est prédéfini pour le job de transfert. Vous devez le spécifier exactement lorsque vous créez votre classe de calcul.

Coûts

Bien que l'utilisation de GKE Volume Populator ne soit pas directement payante, le stockage et les transferts de données sont facturés. Les coûts indirects associés incluent les éléments suivants :

  • Instances Compute Engine utilisées par GKE : coût des nœuds utilisés pour exécuter les jobs de transfert de données. La gestion des nœuds et les implications en termes de coûts varient selon les types de clusters. Pour en savoir plus, consultez les types de clusters respectifs dans Créer votre cluster GKE.
  • Taille du nœud de job de transfert : pour des performances de transfert optimales, un job de transfert augmente par défaut la taille d'un nœud avec 24 processeurs virtuels. Cela s'applique à tous les types de clusters. Si vous souhaitez ajuster la taille et le type de nœud pour des optimisations spécifiques en termes de coûts ou de performances, vous pouvez le faire lorsque vous créez votre classe de calcul.
  • Stockage utilisé dans votre bucket Cloud Storage : pour en savoir plus, consultez les tarifs de Cloud Storage.
  • Coûts des volumes Hyperdisk ML : ils incluent la capacité de stockage et les performances (IOPS/débit) des volumes Hyperdisk ML que vous créez. Pour en savoir plus, consultez la page Tarifs d'Hyperdisk.

Préparer votre environnement

Dans cette section, vous allez créer votre infrastructure de cluster GKE avec le matériel approprié et configurer les autorisations nécessaires pour accéder à vos données dans Cloud Storage.

Avant de créer votre cluster pour utiliser GKE Volume Populator avec Hyperdisk ML, comprenez comment une classe de calcul est appliquée à différents types de clusters et qui est responsable de la gestion des nœuds (GKE ou vous).

Fonctionnement des classes de calcul avec différents types de clusters pour Hyperdisk ML

GKE Volume Populator utilise une classe de calcul personnalisée pour déterminer les types de nœuds à utiliser pour les jobs de transfert de données. Le tableau suivant décrit le comportement de votre classe de calcul en fonction de la configuration de votre cluster :

Considération GKE Autopilot et GKE Standard avec le provisionnement automatique des nœuds GKE Standard sans provisionnement automatique des nœuds
Paramètre de classe de calcul nodePoolAutoCreation activé nodePoolAutoCreation désactivé
Gestion des nœuds GKE crée et gère automatiquement les nœuds. Vous créez et gérez manuellement les nœuds.
Scaling des nœuds Automatique Manuel
Libellés des nœuds Non applicable Vous devez attribuer le libellé cloud.google.com/compute-class=gcs-to-hdml-compute-class aux nœuds.
En savoir plus Provisionnement automatique des nœuds et classes de calcul Configurer des pools de nœuds créés manuellement

GKE lance le job de transfert de données après avoir provisionné le PersistentVolume pour PersistentVolumeClaim. Pour remplir le volume Hyperdisk ML, ce PersistentVolumeClaim doit faire référence à GCPDataSource, qui définit les données sources dans Cloud Storage.

Créer votre cluster GKE

Vous pouvez choisir de déployer votre pipeline de transfert de données à l'aide d'un cluster Standard ou Autopilot avec GKE version 1.33.2-gke.4780000 ou ultérieure. Chaque type de cluster présente ses propres avantages et différents modèles de tarification.

  • Choisissez Autopilot pour une gestion plus facile des clusters, une meilleure rentabilité et l'autoscaling.
  • Choisissez Standard avec provisionnement automatique des nœuds activé si vous avez besoin de l'autoscaling avec un contrôle plus précis du provisionnement des nœuds.
  • Choisissez le mode Standard sans provisionnement automatique des nœuds activé si vous avez besoin d'un contrôle maximal et que vous êtes à l'aise avec la gestion de tous les aspects du provisionnement, du scaling et de la maintenance des nœuds.

Autopilot

Dans les clusters GKE Autopilot, GKE gère automatiquement la création et la suppression des nœuds requis pour les jobs de transfert de données. Une fois le job de transfert terminé, les ressources de nœud sont automatiquement réduites. Vous n'avez pas besoin de supprimer manuellement les pods de transfert ni les nœuds sur lesquels ils s'exécutaient.

Pour créer un cluster Autopilot, exécutez la commande suivante :

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

Remplacez les éléments suivants :

  • CLUSTER_NAME : nom du cluster que vous créez.
  • LOCATION : région de calcul de votre cluster. Exemple :us-central1
  • CLUSTER_VERSION : version de GKE pour le cluster. Utilisez 1.33.2-gke.4780000 dans ce guide.

Standard (avec provisionnement automatique des nœuds)

Dans les clusters GKE Standard avec le provisionnement automatique de nœuds activé, GKE gère automatiquement la création et la suppression des nœuds requis pour les jobs de transfert de données. Une fois le job de transfert terminé, les ressources de nœud sont automatiquement réduites. Vous n'avez pas besoin de supprimer manuellement les pods de transfert ni les nœuds sur lesquels ils s'exécutaient.

Pour créer un cluster Standard avec le provisionnement automatique des nœuds activé, exécutez la commande suivante :

    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

Remplacez les éléments suivants :

  • CLUSTER_NAME : nom du cluster que vous créez avec le provisionnement automatique des nœuds activé.
  • CLUSTER_VERSION : version de GKE pour le cluster. Utilisez 1.33.2-gke.4780000 dans ce guide.
  • LOCATION : zone ou région de calcul de votre cluster. Par exemple, us-central1-a ou us-central1.
  • PROJECT_ID : ID de votre projet Google Cloud .
  • 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.

Standard (sans provisionnement automatique des nœuds)

Pour utiliser GKE Volume Populator sur un cluster Standard où le provisionnement automatique des nœuds n'est pas activé, vous pouvez utiliser un pool de nœuds existant ou créer un pool de nœuds de transfert dédié. Les nœuds doivent avoir la capacité d'exécuter les tâches de transfert et les libellés correspondant à compute-class.

Spécifiez la classe de calcul gcs-to-hdml-compute-class en tant qu'étiquette de nœud lorsque vous créez votre cluster et votre pool de nœuds. Notez que le nom de la classe de calcul, gcs-to-hdml-compute-class, est prédéfini pour le job de transfert et doit être spécifié exactement.

Pour créer un cluster Standard sans provisionnement automatique des nœuds et un pool de nœuds dans ce cluster, exécutez les commandes suivantes :

    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"

Remplacez les éléments suivants :

  • CLUSTER_NAME : nom du cluster que vous créez sans provisionnement automatique des nœuds activé.
  • CLUSTER_VERSION : version de GKE pour le cluster. Utilisez 1.33.2-gke.4780000 dans ce guide.
  • LOCATION : région de calcul de votre cluster. Par exemple, us-central1-a ou us-central1.
  • PROJECT_ID par l'ID de votre projet Google Cloud .
  • NODE_POOL_NAME : nom du pool de nœuds que vous créez dans votre nouveau cluster. Ce pool de nœuds est utilisé par GKE Volume Populator pour déployer les tâches de transfert de données temporaires.

Pour éviter des coûts inutiles, exécutez la commande gcloud container node-pools delete afin de supprimer les pools de nœuds de transfert créés manuellement une fois le transfert de données terminé.

Créer votre classe de calcul

Pour créer une classe de calcul permettant de spécifier et de hiérarchiser les types de VM pouvant être utilisés comme nœuds dans votre cluster, procédez comme suit :

  1. Enregistrez le manifeste suivant sous le nom computeclass.yaml :

    Avec le provisionnement automatique des nœuds

    Pour les clusters Autopilot et les clusters Standard avec provisionnement automatique des nœuds activé, définissez votre classe de calcul avec la section nodePoolAutoCreation comme suit. Lorsque le provisionnement automatique des nœuds est activé, GKE crée automatiquement des pools de nœuds avec le libellé de classe de calcul 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

    Sans provisionnement automatique des nœuds

    Pour les clusters Standard sans provisionnement automatique des nœuds activé, définissez votre classe de calcul sans la section nodePoolAutoCreation comme suit. Assurez-vous d'avoir déjà créé un pool de nœuds avec le libellé de classe de calcul 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
      whenUnsatisfiable: DoNotScaleUp

    Vous pouvez spécifier n'importe quel machineFamily compatible pour répondre à vos besoins de transfert de données. Pour en savoir plus sur la sélection d'un type de machine approprié, consultez Compatibilité des séries de machines avec Hyperdisk ML.

  2. Pour créer la classe de calcul, appliquez le fichier manifeste : 
    kubectl apply -f computeclass.yaml

Configurer les autorisations nécessaires

Pour transférer des données depuis un bucket Cloud Storage, configurez les autorisations requises pour la fédération d'identité de charge de travail pour GKE. Avec les autorisations appropriées, le job de transfert créé par GKE Volume Populator peut accéder à votre bucket Cloud Storage. Ce guide suppose que vous disposez déjà d'un bucket Cloud Storage contenant les données d'entraînement du modèle que vous souhaitez transférer.

  1. Créez un espace de noms Kubernetes :

    kubectl create namespace NAMESPACE

    Remplacez NAMESPACE par l'espace de noms sur lequel vous souhaitez que vos charges de travail s'exécutent.

    Ignorez cette étape si vous utilisez un espace de noms existant.

  2. Créez un compte de service Kubernetes :

    kubectl create serviceaccount KSA_NAME \
    --namespace=NAMESPACE

    Remplacez les éléments suivants :

    • KSA_NAME : nom du compte de service Kubernetes que vous spécifierez dans la ressource GCPDataSource. Le job de transfert créé par GKE Volume Populator utilise ce compte de service pour s'authentifier auprès des API Google Cloud .
    • NAMESPACE : espace de noms Kubernetes que vous avez créé à l'étape précédente.

  3. Accordez à votre compte de service IAM le rôle approprié pour accéder à votre bucket Cloud Storage :

    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 : identifiant numérique de votre projet Google Cloud dans lequel vous avez créé le cluster. Pour trouver votre numéro de projet, consultez Identifier des projets.
    • PROJECT_ID : ID de votre projet Google Cloud .
    • NAMESPACE : espace de noms que vous avez créé précédemment et dans lequel vos charges de travail seront exécutées.
    • KSA_NAME : nom du compte de service Kubernetes que vous avez spécifié dans la ressource GCPDataSource. Le job de transfert créé par GKE Volume Populator utilise ce compte de service pour s'authentifier auprès des API Google Cloud .
    • ROLE : rôle IAM à attribuer à votre compte de service. Pour les besoins de ce guide, accordez le rôle roles/storage.objectViewer pour autoriser la lecture à partir du bucket.

    PROJECT_NUMBER, PROJECT_ID, NAMESPACE et KSA_NAME sont utilisés pour construire l'identifiant principal de la fédération d'identité de charge de travail pour GKE pour votre projet.

Créer un volume Hyperdisk ML avec des données préchargées

Suivez les étapes ci-dessous pour configurer l'infrastructure et la configuration GKE requises pour créer un volume Hyperdisk ML, et pour déclencher et gérer le processus de transfert de données automatisé à l'aide de GKE Volume Populator :

  1. Créez une ressource personnalisée GCPDataSource pour définir la source des données.
  2. Créez une StorageClass pour définir le type de stockage persistant à utiliser (un volume Hyperdisk ML).
  3. Créez un PersistentVolumeClaim pour activer le provisionnement dynamique du stockage et l'accès au volume Hyperdisk ML nouvellement provisionné.
  4. (Facultatif) Consultez la progression du transfert de données.
  5. Créez et déployez un pod qui utilise le volume Hyperdisk ML.

Créer une ressource personnalisée GCPDataSource

Créez une ressource personnalisée GCPDataSource dans GKE pour spécifier l'emplacement du bucket Cloud Storage source et le compte de service disposant des autorisations nécessaires pour accéder à ce bucket. Cette définition de ressource personnalisée (CRD) est spécifique au Volume Populator GKE.

  1. Enregistrez le fichier manifeste suivant sous le nom 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/

    Remplacez les valeurs suivantes :

    • GCP_DATA_SOURCE : nom du CRD GCPDataSource qui contient une référence à votre bucket Cloud Storage. Pour en savoir plus, consultez la documentation de référence sur les CRD GCPDataSource.
    • NAMESPACE : le même espace de noms dans lequel vos charges de travail sont exécutées. La ressource personnalisée GCPDataSource est créée dans cet espace de noms.
    • KSA_NAME : nom du compte de service Kubernetes que vous avez spécifié dans la ressource GCPDataSource. Le job de transfert créé par GKE Volume Populator utilise ce compte de service pour s'authentifier auprès des API Google Cloud . La valeur cloudStorage.serviceAccountName correspond au compte de service Kubernetes que vous avez configuré pour la fédération d'identité de charge de travail pour GKE dans la section Configurer les autorisations nécessaires.
    • GCS_BUCKET : nom de votre bucket Cloud Storage. Le champ uri spécifie les données sources.
      • Pour copier l'intégralité du bucket, utilisez gs://GCS_BUCKET/.
      • Pour copier des données à partir d'un dossier spécifique du bucket, utilisez le format gs://GCS_BUCKET/PATH_INSIDE_BUCKET/. Par exemple, pour copier des données du dossier gemma/v1.0/weights/ dans le bucket my-project-llm-models, l'URI serait gs://my-project-llm-models/gemma/v1.0/weights/. Assurez-vous que le chemin d'accès se termine par une barre oblique pour indiquer un dossier.

  2. Pour créer la ressource GCPDataSource, appliquez le manifeste :

    kubectl apply -f gcpdatasource.yaml

Créer une StorageClass Hyperdisk ML

Créez une StorageClass qui utilise l'approvisionneur pd.csi.storage.gke.io pour provisionner un volume Hyperdisk ML dans la zone de votre choix. Si vous souhaitez que des copies de vos données soient accessibles dans plusieurs zones, vous pouvez créer une StorageClass multizone. Voici un exemple de StorageClass multizone.

  1. Enregistrez le fichier manifeste suivant sous le nom 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

    Remplacez ZONE par la zone cible dans laquelle vous souhaitez créer le volume Hyperdisk ML :

    • Pour un cluster GKE Standard sans provisionnement automatique des nœuds, la valeur de ZONE doit correspondre à l'emplacement où vous avez créé vos nœuds.
    • Pour les clusters GKE Autopilot ou Standard avec provisionnement automatique de nœuds, la valeur de ZONE doit correspondre à l'emplacement où votre cluster peut évoluer et créer des nœuds si nécessaire.

  2. (Facultatif) Pour lister les emplacements des nœuds de votre cluster, exécutez la commande suivante :

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

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster
    • LOCATION : zone ou région de calcul de votre cluster. Par exemple, us-central1-a ou us-central1.

  3. Pour créer la StorageClass, appliquez le fichier manifeste :

    kubectl apply -f hdml-class.yaml

Créer un PersistentVolumeClaim pour accéder au volume

Le manifeste suivant montre un exemple de création d'un PersistentVolumeClaim en mode d'accès ReadOnlyMany qui référence la StorageClass que vous avez créée précédemment.

  1. Enregistrez le manifeste suivant sous le nom 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

    Remplacez les valeurs suivantes :

    • PVC_NAME : nom du PersistentVolumeClaim vers lequel vous souhaitez transférer vos données.
    • NAMESPACE : espace de noms dans lequel vos charges de travail seront exécutées.
    • DISK_SIZE : taille du disque, en gigaoctets, qui sera créé pour remplir les données. Pour que les données soient correctement insérées, assurez-vous que la taille de disque demandée est supérieure à la taille des données de votre modèle dans le bucket Cloud Storage. Pour respecter la plage acceptée pour les volumes Hyperdisk ML, la valeur de DISK_SIZE doit être supérieure à 4 Gi. Pour en savoir plus, consultez Limites de taille des volumes Hyperdisk.
    • GCP_DATA_SOURCE : nom du CRD GCPDataSource qui contient une référence à votre bucket Cloud Storage.

    Vous pouvez personnaliser le transfert de données en ajoutant des annotations facultatives à votre PVC. Ces annotations influencent le comportement du job de transfert sous-jacent qui copie les données dans votre volume Hyperdisk ML.

    • volume-populator.datalayer.gke.io/cpu-request : utilisez cette annotation pour spécifier une autre demande de ressources de processeur pour le transfert Job. Si vous ne spécifiez pas de demande de ressources de processeur différente, le PVC demande 24 vCPU par défaut pour optimiser les performances de transfert.

    • volume-populator.datalayer.gke.io/transfer-path : utilisez cette annotation pour spécifier le chemin de destination dans le nouveau volume qui stockera les données copiées à partir de votre ressource GCPDataSource. Si vous ne spécifiez pas un autre chemin, les données sont copiées dans le chemin racine du volume Hyperdisk ML.

  2. Pour créer le PVC, appliquez le fichier manifeste :

    kubectl apply -f volume-populator-pvc.yaml

Notez les points suivants :

  • Si vous définissez le champ volumeBindingMode de votre StorageClass sur immediate, le transfert de données est déclenché immédiatement lors du déploiement du PVC.
  • Si vous définissez le champ volumeBindingMode de votre StorageClass sur WaitForFirstConsumer, le transfert de données n'est déclenché qu'après le déploiement d'un pod qui demande la PVC et que ce pod est correctement planifié sur un nœud. Bien que votre pod puisse être planifié, ses conteneurs attendront que le transfert de données soit terminé et que le volume soit prêt à l'emploi avant de démarrer.

Pour vérifier la progression de votre transfert de données, consultez Afficher la progression du transfert de données. Si vous rencontrez des erreurs lors du provisionnement des ressources ou du transfert de données, consultez Résoudre les problèmes de transfert de données liés à GKE Volume Populator.

(Facultatif) Afficher la progression du transfert de données

Cette section explique comment suivre la progression et la réussite de vos transferts de données d'un bucket Cloud Storage vers un volume Hyperdisk ML.

  1. Pour vérifier l'état de votre PersistentVolumeClaim, exécutez la commande suivante. Vous pouvez également exécuter cette commande si l'opération de liaison PersistentVolumeClaim prend trop de temps.

    kubectl describe pvc PVC_NAME -n NAMESPACE

    Remplacez les éléments suivants :

  2. Dans le résultat, examinez les événements PersistentVolumeClaim pour surveiller la progression du transfert de données. GKE consigne les événements environ une fois par minute. Le résultat ressemble à ce qui suit :

    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

L'opération de remplissage peut prendre plusieurs minutes, en fonction de la taille des données. Si aucune progression du transfert de données ne s'affiche après plusieurs minutes, consultez Dépannage des problèmes de transfert de données liés à GKE Volume Populator pour obtenir de l'aide.

Pour les transferts de données de volumes Hyperdisk ML multizones, la tâche n'est marquée comme terminée que si les données sont transférées avec succès vers toutes les zones spécifiées dans la StorageClass. Si le transfert échoue pour une ou plusieurs zones, le GKE Volume Populator tente de transférer les données indéfiniment tant que le PVC existe.

Créer et déployer un pod qui consomme le volume

Pour créer un pod permettant de vérifier le contenu d'un PVC qui a été rempli de données :

  1. Enregistrez le manifeste suivant sous le nom 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

    Remplacez les éléments suivants :

  2. Créez le pod à l'aide de la commande suivante :

    kubectl create -f verify-data.yaml

  3. Pour lister les fichiers, exécutez la commande suivante :

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

Si la commande aboutit, vous trouverez les données renseignées dans le répertoire /models de votre bucket Cloud Storage.

Effectuer un nettoyage

Pour éviter des coûts inutiles et supprimer les ressources mal configurées ou orphelines, suivez les étapes permettant de supprimer correctement le PersistentVolumeClaim.

Supprimer la PersistentVolumeClaim lors du provisionnement dynamique

Si vous devez supprimer votre PersistentVolumeClaim alors que des données sont encore en cours de transfert lors du provisionnement dynamique, suivez les étapes ci-dessous pour une suppression progressive. La suppression progressive peut prendre un certain temps.

Remplacez les variables pertinentes suivantes lors du processus de suppression :

  1. Supprimez le pod de charge de travail :

    kubectl delete pod POD_NAME -n NAMESPACE

  2. Recherchez le nom de l'objet PersistentVolumeClaim temporaire :

    # 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. Supprimez le PVC créé dans l'espace de noms :

    kubectl delete pvc PVC_NAME -n NAMESPACE

  4. Le PVC est peut-être bloqué dans l'état Terminating :

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

    Si c'est le cas, nettoyez manuellement le PVC en supprimant ses finaliseurs :

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

  5. Ne supprimez la ressource GCPDataSource qu'une fois la PVC supprimée. Si vous supprimez d'abord la ressource GCPDataSource, la suppression du PVC sera bloquée.

    kubectl delete gcpdatasource GCP_DATA_SOURCE -n NAMESPACE

  6. Vérifiez que les ressources temporaires ont été supprimées.

Étapes suivantes