Automatizar la transferencia de datos de Cloud Storage a un volumen de Hyperdisk ML mediante GKE Volume Populator


En esta guía se describe cómo puedes precargar grandes cantidades de datos de un bucket de Cloud Storage en un volumen Hyperdisk ML de Google Kubernetes Engine (GKE) durante el aprovisionamiento dinámico mediante GKE Volume Populator. Para obtener más información, consulta Acerca de GKE Volume Populator.

Esta guía está dirigida a especialistas en almacenamiento que crean y asignan almacenamiento, y gestionan la seguridad y el acceso a los datos. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el Google Cloud contenido, consulta Roles y tareas habituales de los usuarios de GKE Enterprise.

Gestión de grupos de nodos para GKE Volume Populator con Hyperdisk ML

Es fundamental que los grupos de nodos se dimensionen, aprovisionen y escalen de forma eficiente para ejecutar correctamente los trabajos de transferencia de datos que crea GKE Volume Populator para rellenar los volúmenes de Hyperdisk ML. Se usa una clase de computación para definir los requisitos de los nodos, como el tipo y el tamaño de la máquina, para estos trabajos de transferencia de datos específicos. Una clase de computación te permite controlar el coste y el rendimiento del proceso de transferencia de datos. Para obtener más información, consulta Ventajas de las clases de cálculo personalizadas.

Para elegir el clúster que mejor se adapte a tus tareas de transferencia de datos, consulta cómo funcionan las clases de computación con los diferentes tipos de clústeres de Hyperdisk ML.

Objetivos

En esta guía, realizarás las siguientes tareas:

Antes de empezar

Asegúrate de haber realizado las siguientes tareas:

  1. Habilita las APIs de GKE y Cloud Storage.

    Habilita las APIs

  2. Comprueba que la facturación esté habilitada en tu Google Cloud proyecto.

  3. Descarga e instala la herramienta de línea de comandos de Google Cloud CLI o usa Cloud Shell para ejecutar comandos gcloud CLI y kubectl. Cloud Shell es un entorno de shell para gestionar recursos alojados en Google Cloud. Viene preinstalada con las herramientas de línea de comandos gcloud y kubectl.

  4. Configura una región y una zona predeterminadas.

  5. Crea un segmento de Cloud Storage o usa uno que ya tengas. En esta guía se da por hecho que ya tienes un segmento de Cloud Storage con los datos de entrenamiento de tu modelo.

  6. Habilita el controlador de CSI para Persistent Disk en Compute Engine en los clústeres estándar que puedan tenerlo inhabilitado explícitamente. En los clústeres Autopilot y Standard nuevos, GKE habilita el controlador de forma predeterminada. El almacenamiento de Hyperdisk ML de destino que crees debe gestionarse con el controlador de CSI para Persistent Disk en Compute Engine.

  7. Habilita Workload Identity Federation para GKE en tu clúster. De esta forma, la cuenta de servicio de Kubernetes que usa GKE Volume Populator puede acceder al segmento de Cloud Storage de origen. Para obtener más información, consulta Configurar los permisos necesarios.

Requisitos

Para transferir datos mediante GKE Volume Populator, debes cumplir los siguientes requisitos:

  • Tu clúster de GKE debe tener la versión 1.33.2-gke.4780000 o una posterior.
  • El recurso personalizado GCPDataSource debe estar en el mismo espacio de nombres que tu carga de trabajo de GKE. No se admiten fuentes de datos que abarcan distintos espacios de nombres.
  • Selecciona una máquina virtual compatible al crear tu clase de cálculo. Comprueba que tu proyecto tiene suficiente cuota para el tipo de máquina que selecciones.
  • El nombre de la clase de cálculo gcs-to-hdml-compute-class está predefinido para la tarea de transferencia y debe especificarse exactamente al crear la clase de cálculo.

Costes

Aunque no hay ningún coste directo por usar GKE Volume Populator, el almacenamiento y las transferencias de datos generan cargos de facturación. Los costes indirectos asociados incluyen lo siguiente:

  • Instancias de Compute Engine usadas por GKE: el coste de los nodos usados para ejecutar los trabajos de transferencia de datos. La gestión de nodos y las implicaciones de costes varían según el tipo de clúster. Para obtener más información, consulta los tipos de clústeres correspondientes en Crear un clúster de GKE.
  • Tamaño del nodo de la tarea de transferencia: para obtener un rendimiento óptimo de la transferencia, una tarea de transferencia amplía de forma predeterminada un nodo con 24 vCPUs. Esto se aplica a todos los tipos de clústeres. Si quieres ajustar el tamaño y el tipo de nodo para optimizar los costes o el rendimiento, puedes hacerlo al crear tu clase de computación.
  • Almacenamiento utilizado en tu segmento de Cloud Storage: para obtener más información, consulta la página Precios de Cloud Storage.
  • Costes de los volúmenes de Hyperdisk ML: incluyen la capacidad de almacenamiento y el rendimiento (IOPS/rendimiento) de los volúmenes de Hyperdisk ML que crees. Para obtener más información, consulta los precios de Hyperdisk.

Prepara tu entorno

En esta sección, creará la infraestructura de su clúster de GKE con el hardware adecuado y configurará los permisos necesarios para acceder a sus datos en Cloud Storage.

Antes de crear un clúster para usar GKE Volume Populator con Hyperdisk ML, debes saber cómo se aplica una clase de computación a los distintos tipos de clústeres y quién es el responsable de la gestión de los nodos: GKE o tú.

Cómo funcionan las clases de computación con diferentes tipos de clústeres para Hyperdisk ML

GKE Volume Populator usa una clase de computación personalizada para determinar los tipos de nodos que se van a usar en los trabajos de transferencia de datos. En la siguiente tabla se describe el comportamiento de tu clase de cálculo en función de la configuración del clúster:

Consideración Autopilot de GKE y GKE Standard con aprovisionamiento automático de nodos Aprovisionamiento automático de nodos sin GKE Standard
Configuración de la clase de cálculo nodePoolAutoCreation habilitado nodePoolAutoCreation inhabilitado
Gestión de nodos GKE crea y gestiona nodos automáticamente. Creas y gestionas los nodos manualmente.
Escalado de nodos Automático Manual
Etiquetado de nodos No aplicable Debes etiquetar los nodos con cloud.google.com/compute-class=gcs-to-hdml-compute-class
Más información Aprovisionamiento automático de nodos y clases de computación Configurar grupos de nodos creados manualmente

GKE inicia el trabajo de transferencia de datos después de aprovisionar el PersistentVolume para el PersistentVolumeClaim. Para rellenar el volumen de AA de Hyperdisk, este PersistentVolumeClaim debe hacer referencia al GCPDataSource, que define los datos de origen en Cloud Storage.

Crear un clúster de GKE

Puedes desplegar tu canalización de transferencia de datos mediante un clúster estándar o de Autopilot con la versión 1.33.2-gke.4780000 de GKE o una posterior. Cada tipo de clúster tiene sus propias ventajas y modelos de precios diferentes.

  • Elige Autopilot para disfrutar de una gestión de clústeres más sencilla, una mayor eficiencia de costes y el autoescalado.
  • Elige Estándar con aprovisionamiento automático de nodos habilitado si necesitas el autoescalado y quieres tener más control sobre el aprovisionamiento de nodos.
  • Elige la opción Estándar sin el aprovisionamiento automático de nodos habilitado si necesitas el máximo control y te sientes cómodo gestionando todos los aspectos del aprovisionamiento, el escalado y el mantenimiento de nodos.

Autopilot

En los clústeres de GKE Autopilot, GKE gestiona automáticamente la creación y la eliminación de los nodos necesarios para las tareas de transferencia de datos. Cuando se completa el trabajo de transferencia, los recursos de los nodos se reducen automáticamente. No es necesario que elimines manualmente los pods de transferencia ni los nodos en los que se ejecutaron los pods.

Para crear un clúster de Autopilot, ejecuta el siguiente comando:

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

Haz los cambios siguientes:

  • CLUSTER_NAME: el nombre del clúster que vas a crear.
  • LOCATION: la región de computación de tu clúster. Por ejemplo, us-central1.
  • CLUSTER_VERSION: la versión de GKE del clúster. Usa 1.33.2-gke.4780000 en esta guía.

Estándar (con aprovisionamiento automático de nodos)

En los clústeres estándar de GKE con el aprovisionamiento automático de nodos habilitado, GKE gestiona automáticamente la creación y eliminación de los nodos necesarios para las tareas de transferencia de datos. Cuando se completa el trabajo de transferencia, los recursos de los nodos se reducen automáticamente. No es necesario que elimines manualmente los pods de transferencia ni los nodos en los que se ejecutaron los pods.

Para crear un clúster estándar con el aprovisionamiento automático de nodos habilitado, ejecuta el siguiente comando:

    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
    

Haz los cambios siguientes:

  • CLUSTER_NAME: el nombre del clúster que vas a crear con el aprovisionamiento automático de nodos habilitado.
  • CLUSTER_VERSION: la versión de GKE del clúster. Usa 1.33.2-gke.4780000 en esta guía.
  • LOCATION: la zona o región de cálculo de tu clúster. Por ejemplo, us-central1-a o us-central1.
  • PROJECT_ID: tu ID de proyecto Google Cloud .
  • MINIMUM_CPU: número mínimo de vCPUs que se aprovisionarán automáticamente. Por ejemplo, 10.
  • MINIMUM_MEMORY: cantidad mínima de memoria en GiB que se debe aprovisionar automáticamente. Por ejemplo, 200.
  • MAXIMUM_CPU: número máximo de vCPUs que se pueden aprovisionar automáticamente. Por ejemplo, 100. Este límite es el total de los recursos de CPU de todos los grupos de nodos creados manualmente y de todos los grupos de nodos que GKE pueda crear automáticamente.
  • MAXIMUM_MEMORY: cantidad máxima de memoria que se puede aprovisionar automáticamente. Por ejemplo, 1000. Este límite es el total de los recursos de memoria de todos los grupos de nodos creados manualmente y de todos los grupos de nodos que GKE pueda crear automáticamente.

Estándar (sin aprovisionamiento automático de nodos)

Para usar GKE Volume Populator en un clúster estándar en el que no esté habilitado el aprovisionamiento automático de nodos, puedes usar un grupo de nodos o crear un grupo de nodos de transferencia específico. Los nodos deben tener capacidad para ejecutar los trabajos de transferencia y etiquetas que coincidan con compute-class.

Especifica la clase de computación gcs-to-hdml-compute-class como etiqueta de nodo al crear el clúster y el grupo de nodos. Ten en cuenta que el nombre de la clase de cálculo, gcs-to-hdml-compute-class, está predefinido para la tarea de transferencia y debe especificarse exactamente.

Para crear un clúster estándar sin aprovisionamiento automático de nodos y un grupo de nodos en ese clúster, ejecuta los siguientes comandos:

    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"
    

Haz los cambios siguientes:

  • CLUSTER_NAME: el nombre del clúster que vas a crear sin el aprovisionamiento automático de nodos habilitado.
  • CLUSTER_VERSION: la versión de GKE del clúster. Usa 1.33.2-gke.4780000 en esta guía.
  • LOCATION: la región de computación de tu clúster. Por ejemplo, us-central1-a o us-central1.
  • PROJECT_ID el ID de tu proyecto. Google Cloud
  • NODE_POOL_NAME: el nombre del grupo de nodos que vas a crear en el nuevo clúster. GKE Volume Populator usa este grupo de nodos para desplegar las tareas de transferencia de datos temporales.

Para evitar costes innecesarios, ejecuta el comando gcloud container node-pools delete para eliminar los grupos de nodos de transferencia creados manualmente una vez que se haya completado la transferencia de datos.

Crear una clase de cálculo

Para crear una clase de computación que especifique y priorice los tipos de máquinas virtuales que se pueden usar como nodos en tu clúster, sigue estos pasos:

  1. Guarda el siguiente archivo de manifiesto como computeclass.yaml:

    Con el aprovisionamiento automático de nodos

    En los clústeres de Autopilot y los clústeres estándar con el aprovisionamiento automático de nodos habilitado, define tu clase de Compute con la sección nodePoolAutoCreation de la siguiente manera. Cuando el aprovisionamiento automático de nodos está habilitado, GKE crea automáticamente grupos de nodos con la etiqueta de clase de computación 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
        

    Sin el aprovisionamiento automático de nodos

    En los clústeres estándar en los que no se ha habilitado el aprovisionamiento automático de nodos, define la clase de computación sin la sección nodePoolAutoCreation de la siguiente manera. Comprueba que ya hayas creado un grupo de nodos con la etiqueta de clase de computación 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
        

    Puedes especificar cualquier machineFamily compatible para satisfacer tus necesidades de transferencia de datos. Para obtener más información sobre cómo seleccionar un tipo de máquina adecuado, consulta Compatibilidad de series de máquinas con Hyperdisk ML.

  2. Para crear la clase de cálculo, aplica el manifiesto:
    kubectl apply -f computeclass.yaml

Configurar los permisos necesarios

Para transferir datos desde un segmento de Cloud Storage, configura los permisos necesarios para Workload Identity Federation for GKE. Con los permisos adecuados, la tarea de transferencia creada por GKE Volume Populator puede acceder a tu segmento de Cloud Storage. En esta guía se da por hecho que ya tienes un segmento de Cloud Storage con los datos de entrenamiento del modelo que quieres transferir.

  1. Crea un espacio de nombres de Kubernetes:

    kubectl create namespace NAMESPACE
    

    Sustituye NAMESPACE por el espacio de nombres en el que quieras que se ejecuten tus cargas de trabajo.

    Sáltate este paso si ya tienes un espacio de nombres.

  2. Crea una cuenta de servicio de Kubernetes:

    kubectl create serviceaccount KSA_NAME \
        --namespace=NAMESPACE
    

    Haz los cambios siguientes:

    • KSA_NAME: el nombre de la cuenta de servicio de Kubernetes que especificarás en el recurso GCPDataSource. El trabajo de transferencia creado por GKE Volume Populator usa esta cuenta de servicio para autenticarse en las APIs. Google Cloud
    • NAMESPACE: el espacio de nombres de Kubernetes que has creado en el paso anterior.
  3. Concede a tu cuenta de servicio de gestión de identidades y accesos el rol adecuado para acceder a tu segmento de 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"
    

    Haz los cambios siguientes:

    • GCS_BUCKET: el nombre de tu segmento de Cloud Storage.
    • PROJECT_NUMBER: el identificador numérico de tu Google Cloud proyecto en el que has creado el clúster. Para encontrar el número de tu proyecto, consulta el artículo sobre cómo identificar proyectos.
    • PROJECT_ID: tu ID de proyecto Google Cloud .
    • NAMESPACE: el espacio de nombres que has creado anteriormente en el que se ejecutarán tus cargas de trabajo.
    • KSA_NAME: el nombre de la cuenta de servicio de Kubernetes que has especificado en el recurso GCPDataSource. El trabajo de transferencia creado por GKE Volume Populator usa esta cuenta de servicio para autenticarse en las APIs. Google Cloud
    • ROLE: el rol de gestión de identidades y accesos que quieres conceder a tu cuenta de servicio. En esta guía, se concede el rol roles/storage.objectViewer para permitir la lectura del segmento.

    PROJECT_NUMBER, PROJECT_ID, NAMESPACE y KSA_NAME se usan para crear el identificador principal de Workload Identity Federation for GKE de tu proyecto.

Crear un volumen de Hyperdisk ML con datos precargados

Sigue estos pasos para configurar la infraestructura y la configuración de GKE necesarias para crear un volumen de Hyperdisk ML, así como para activar y gestionar el proceso de transferencia de datos automatizado mediante GKE Volume Populator:

  1. Crea un GCPDataSource recurso personalizado para definir la fuente de los datos.
  2. Crea una StorageClass para definir el tipo de almacenamiento persistente (un volumen de Hyperdisk ML) que se va a usar.
  3. Crea un PersistentVolumeClaim para habilitar el aprovisionamiento dinámico del almacenamiento y el acceso al volumen de Hyperdisk ML recién aprovisionado.
  4. (Opcional) Consulta el progreso de la transferencia de datos.
  5. Crea y despliega un pod que consuma el volumen de Hyperdisk ML.

Crear un recurso personalizado GCPDataSource

Crea un GCPDataSource recurso personalizado en GKE para especificar la ubicación del segmento de Cloud Storage de origen y la cuenta de servicio con los permisos necesarios para acceder a ese segmento. Esta definición de recurso personalizado (CRD) es específica del Volume Populator de GKE.

  1. Guarda el siguiente archivo de manifiesto como 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/
    

    Sustituye los siguientes valores:

    • GCP_DATA_SOURCE: el nombre del GCPDataSource CRD que contiene una referencia a tu segmento de Cloud Storage. Para obtener más información, consulta la referencia de CRD de GCPDataSource.
    • NAMESPACE: el mismo espacio de nombres en el que se ejecutan tus cargas de trabajo. El recurso personalizado GCPDataSource se crea en este espacio de nombres.
    • KSA_NAME: el nombre de la cuenta de servicio de Kubernetes que has especificado en el recurso GCPDataSource. El trabajo de transferencia creado por GKE Volume Populator usa esta cuenta de servicio para autenticarse en las APIs. Google Cloud El valor de cloudStorage.serviceAccountName es la cuenta de servicio de Kubernetes que has configurado para Workload Identity Federation for GKE en la sección Configurar los permisos necesarios.
    • GCS_BUCKET: el nombre de tu segmento de Cloud Storage. El campo uri especifica los datos de origen.
      • Para copiar todo el contenedor, usa gs://GCS_BUCKET/.
      • Para copiar datos de una carpeta específica del segmento, usa el formato gs://GCS_BUCKET/PATH_INSIDE_BUCKET/. Por ejemplo, para copiar datos de la carpeta gemma/v1.0/weights/ del segmento my-project-llm-models, el URI sería gs://my-project-llm-models/gemma/v1.0/weights/. Asegúrate de que la ruta termine con una barra inclinada para indicar que se trata de una carpeta.
  2. Para crear el recurso GCPDataSource, aplica el manifiesto:

    kubectl apply -f gcpdatasource.yaml
    

Crear un StorageClass de Hyperdisk ML

Crea un StorageClass que use el aprovisionador pd.csi.storage.gke.io para aprovisionar un volumen de Hyperdisk ML en la zona que elijas. Si quieres que se pueda acceder a copias de tus datos en más de una zona, puedes crear un StorageClass multizona. A continuación, se muestra un ejemplo de StorageClass multizona.

  1. Guarda el siguiente archivo de manifiesto como 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
    

    Sustituye ZONE por la zona de destino en la que quieras crear el volumen de Hyperdisk ML:

    • En el caso de los clústeres estándar de GKE sin aprovisionamiento automático de nodos, el valor de ZONE debe ser la ubicación en la que hayas creado los nodos.
    • En los clústeres Autopilot o Estándar de GKE con aprovisionamiento automático de nodos, el valor de ZONE debe ser la ubicación en la que tu clúster pueda aumentar la capacidad y crear nodos nuevos si es necesario.
  2. (Opcional) Para enumerar las ubicaciones de los nodos de tu clúster, ejecuta el siguiente comando:

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

    Haz los cambios siguientes:

    • CLUSTER_NAME: el nombre de tu clúster.
    • LOCATION: la zona o región de cálculo de tu clúster. Por ejemplo, us-central1-a o us-central1.
  3. Para crear la StorageClass, aplica el manifiesto :

    kubectl apply -f hdml-class.yaml
    

Crear un PersistentVolumeClaim para acceder al volumen

El siguiente manifiesto muestra un ejemplo de cómo crear un PersistentVolumeClaim en el modo de acceso ReadOnlyMany que hace referencia a la StorageClass que has creado anteriormente.

  1. Guarda el siguiente archivo de manifiesto como 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
    

    Sustituye los siguientes valores:

    • PVC_NAME: el nombre de PersistentVolumeClaim al que quieras transferir tus datos.
    • NAMESPACE: el espacio de nombres en el que se ejecutarán tus cargas de trabajo.
    • DISK_SIZE: tamaño del disco, en gigabytes, que se creará para rellenar los datos. Para rellenar los datos correctamente, asegúrate de que el tamaño del disco solicitado sea mayor que el tamaño de los datos del modelo que se encuentran en el segmento de Cloud Storage. Para ajustarse al intervalo admitido de los volúmenes de Hyperdisk ML, el valor de DISK_SIZE debe ser superior a 4 Gi. Para obtener más información, consulta Límites de tamaño de los volúmenes de Hyperdisk.
    • GCP_DATA_SOURCE: el nombre del GCPDataSource CRD que contiene una referencia a tu segmento de Cloud Storage.

    Puedes personalizar la transferencia de datos añadiendo anotaciones opcionales a tu PVC. Estas anotaciones influyen en el comportamiento del trabajo de transferencia subyacente que copia los datos en tu volumen de Hyperdisk ML.

    • volume-populator.datalayer.gke.io/cpu-request: usa esta anotación para especificar una solicitud de recursos de CPU diferente para la transferencia Job. Si no especificas otra solicitud de recursos de CPU, el PVC solicita 24 vCPUs de forma predeterminada para optimizar el rendimiento de la transferencia.

    • volume-populator.datalayer.gke.io/transfer-path: usa esta anotación para especificar la ruta de destino dentro del nuevo volumen que almacenará los datos copiados de tu recurso GCPDataSource. Si no especificas otra ruta, los datos se copiarán en la ruta raíz del volumen de Hyperdisk ML.

  2. Para crear el PVC, aplica el manifiesto:

    kubectl apply -f volume-populator-pvc.yaml
    

Ten en cuenta los siguientes puntos:

  • Si asignas el valor immediate al campo volumeBindingMode de tu StorageClass, la transferencia de datos se activará inmediatamente después de implementar el PVC.
  • Si asignas el valor WaitForFirstConsumer al campo volumeBindingMode de tu StorageClass, la transferencia de datos solo se activará después de desplegar un Pod que solicite el PVC y que se haya programado correctamente en un nodo. Aunque puedes programar tu Pod, sus contenedores esperarán a que se complete la transferencia de datos y el volumen esté listo para usarse.

Para comprobar el progreso de la transferencia de datos, consulta Ver el progreso de la transferencia de datos. Si se producen errores durante el aprovisionamiento de recursos o la transferencia de datos, consulta el artículo Solucionar problemas de transferencia de datos de GKE Volume Populator.

(Opcional) Ver el progreso de la transferencia de datos

En esta sección se explica cómo puede monitorizar el progreso y el éxito de sus transferencias de datos de un segmento de Cloud Storage a un volumen de Hyperdisk ML.

  1. Para verificar el estado de tu PersistentVolumeClaim, ejecuta el siguiente comando. También puedes ejecutar este comando si la operación de vinculación de PersistentVolumeClaim tarda demasiado en completarse.

    kubectl describe pvc PVC_NAME -n NAMESPACE
    

    Haz los cambios siguientes:

  2. En el resultado, revisa los eventos de PersistentVolumeClaim para monitorizar el progreso de la transferencia de datos. GKE registra los eventos aproximadamente una vez por minuto. El resultado debería ser similar al siguiente:

    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
    

La operación de relleno puede tardar varios minutos en iniciarse, en función del tamaño de los datos. Si no ves ningún progreso en la transferencia de datos después de varios minutos, consulta Solucionar problemas de transferencia de datos de GKE Volume Populator para obtener ayuda.

En el caso de las transferencias de datos de volúmenes de Hyperdisk ML multizona, la tarea se marca como completada solo si los datos se transfieren correctamente a todas las zonas especificadas en StorageClass. Si la tarea de transferencia falla en una o varias zonas, el Populator de volúmenes de GKE vuelve a intentar transferir los datos indefinidamente mientras exista el PVC.

Crear y desplegar un pod que consuma el volumen

Para crear un pod que verifique el contenido de un PVC que se ha rellenado con datos, haz lo siguiente:

  1. Guarda el siguiente archivo de manifiesto como 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
    

    Haz los cambios siguientes:

  2. Crea el pod con el siguiente comando:

    kubectl create -f verify-data.yaml
    
  3. Para enumerar los archivos, ejecuta el siguiente comando:

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

Si el comando se ejecuta correctamente, encontrarás los datos rellenados en el directorio /models de tu segmento de Cloud Storage.

Limpieza

Para evitar costes innecesarios y eliminar los recursos huérfanos o mal configurados, sigue los pasos para eliminar PersistentVolumeClaim correctamente.

Eliminar el PersistentVolumeClaim durante el aprovisionamiento dinámico

Si necesitas eliminar tu PersistentVolumeClaim mientras se transfieren datos durante el aprovisionamiento dinámico, sigue estos pasos para realizar una eliminación correcta. La eliminación gradual puede tardar un tiempo en completarse.

Sustituye las siguientes variables pertinentes durante el proceso de eliminación:

  1. Elimina el pod de la carga de trabajo:

    kubectl delete pod POD_NAME -n NAMESPACE
    
  2. Busca el nombre del PersistentVolumeClaim temporal:

    # 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. Elimina el PVC que se ha creado en el espacio de nombres:

    kubectl delete pvc PVC_NAME -n NAMESPACE
    
  4. Es posible que el PVC esté en el estado Terminating:

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

    Si es así, limpia manualmente el PVC eliminando sus finalizadores:

    kubectl patch pvc PVC_NAME -n NAMESPACE  -p '{"metadata":{"finalizers":null}}'
    
  5. Elimina el recurso GCPDataSource solo después de que se haya eliminado el PVC. Si eliminas primero el recurso GCPDataSource, la eliminación del PVC se quedará bloqueada.

    kubectl delete gcpdatasource GCP_DATA_SOURCE -n NAMESPACE
    
  6. Comprueba que los recursos temporales se hayan eliminado.

Siguientes pasos