Se usó la API de Cloud Translation para traducir esta página.

Automatiza la transferencia de datos de Cloud Storage a un volumen de Hyperdisk ML con GKE Volume Populator

Autopilot estándar

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

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

Administración de grupos de nodos para el propagador de volúmenes de GKE con Hyperdisk ML

El ajuste, el aprovisionamiento y el escalamiento eficientes del tamaño del grupo de nodos son fundamentales para ejecutar correctamente los trabajos de transferencia de datos que crea GKE Volume Populator para propagar los volúmenes de Hyperdisk ML. Usas una clase de procesamiento para definir los requisitos de los nodos, como el tipo y el tamaño de la máquina, para estos trabajos específicos de transferencia de datos. Una clase de procesamiento te permite controlar el costo y el rendimiento del proceso de transferencia de datos. Para obtener más información, consulta Beneficios de las clases de procesamiento personalizadas.

Para elegir el clúster más adecuado para tus trabajos de transferencia de datos, comprende cómo funcionan las clases de procesamiento con diferentes tipos de clústeres para el AA de Hyperdisk.

Objetivos

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

Configura tu entorno de clúster de GKE para admitir transferencias de datos con GKE Volume Populator, lo que incluye la creación de clústeres, la definición de clases de procesamiento y la configuración de permisos.
Crea un recurso personalizado GCPDataSource para especificar el bucket de Cloud Storage de origen.
Define un StorageClass para Hyperdisk ML.
Crea un PersistentVolumeClaim que haga referencia al GCPDataSource para activar la propagación de datos en un volumen de Hyperdisk ML.
Verifica la transferencia de datos.
Consume el volumen completado en un Pod.
Limpia los recursos.

Antes de comenzar

Asegúrate de haber realizado las siguientes tareas:

Habilita las APIs de GKE y Cloud Storage.

Habilita las APIs
Asegúrate de tener habilitada la facturación para tu Google Cloud proyecto.
Descarga e instala la herramienta de línea de comandos de Google Cloud CLI o usa Cloud Shell para ejecutar los comandos gcloud CLI y kubectl. Cloud Shell es un entorno de shell que se usa para administrar recursos alojados en Google Cloud. Viene preinstalado con las herramienta de línea de comandos de gcloud y kubectl.
Configura una región y una zona predeterminadas.
Crea o usa un bucket de Cloud Storage existente. En esta guía, se supone que ya tienes un bucket de Cloud Storage completado con los datos de entrenamiento de tu modelo.
Habilita el controlador de CSI de Persistent Disk de Compute Engine en los clústeres de Standard existentes que podrían tener el controlador inhabilitado de forma explícita. En los clústeres nuevos de Autopilot y Standard, GKE habilita el controlador de forma predeterminada. El almacenamiento de Hyperdisk ML de destino que crees debe estar administrado por el controlador de CSI de Persistent Disk para Compute Engine.
Habilita Workload Identity Federation for GKE en tu clúster. Esto permite que la cuenta de servicio de Kubernetes que usa GKE Volume Populator acceda al bucket de origen de Cloud Storage. Para obtener más información, consulta Configura los permisos necesarios.

Requisitos

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

Tu clúster de GKE debe ejecutar la versión 1.33.2-gke.4780000 o una posterior.
Tu recurso personalizado GCPDataSource debe estar en el mismo espacio de nombres que tu carga de trabajo de GKE. No se admiten las fuentes de datos que abarcan diferentes espacios de nombres.
Selecciona una VM compatible cuando crees tu clase de procesamiento. Confirma que tu proyecto tenga suficiente cuota para el tipo de máquina que selecciones.
El nombre de la clase de procesamiento gcs-to-hdml-compute-class está predefinido para el trabajo de transferencia y se debe especificar exactamente cuando creas tu clase de procesamiento.

Costos

Si bien no hay un costo directo por usar GKE Volume Populator, el almacenamiento y las transferencias de datos generan cargos de facturación. Los costos indirectos asociados incluyen lo siguiente:

Instancias de Compute Engine que usa GKE: Es el costo de los nodos que se usan para ejecutar los trabajos de transferencia de datos. La administración de nodos y las implicaciones en los costos varían según los tipos de clústeres. Para obtener más información, consulta los respectivos tipos de clústeres en Crea tu clúster de GKE.
Tamaño del nodo de trabajo de transferencia: Para un rendimiento óptimo de la transferencia, un trabajo de transferencia de forma predeterminada escala verticalmente un nodo con 24 CPU virtuales. Esto se aplica a todos los tipos de clústeres. Si deseas ajustar el tamaño y el tipo de nodo para optimizaciones específicas de costos o rendimiento, puedes hacerlo cuando crees tu clase de procesamiento.
Almacenamiento utilizado en tu bucket de Cloud Storage: Para obtener más información, consulta los precios de Cloud Storage.
Costos de los volúmenes de Hyperdisk ML: Incluyen la capacidad de almacenamiento y el rendimiento (IOPS/capacidad de procesamiento) de los volúmenes de Hyperdisk ML que creas. Para obtener más información, consulta Precios de Hyperdisk.

Prepara el entorno

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

Antes de crear tu clúster para usar GKE Volume Populator con Hyperdisk ML, comprende cómo se aplica una clase de procesamiento a diferentes tipos de clústeres y quién es responsable de la administración de nodos: GKE o tú.

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

GKE Volume Populator usa una clase de procesamiento personalizada para determinar los tipos de nodos que se usarán para los trabajos de transferencia de datos. En la siguiente tabla, se describe el comportamiento de tu clase de procesamiento según la configuración del clúster:

Consideración	GKE Autopilot y GKE Standard con aprovisionamiento automático de nodos	GKE Standard sin aprovisionamiento automático de nodos
Parámetro de configuración de la clase de procesamiento	`nodePoolAutoCreation` habilitado	`nodePoolAutoCreation` inhabilitado
Administración de nodos	GKE crea y administra nodos automáticamente.	Creas y administras nodos de forma manual.
Ajuste de escala 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 procesamiento	Configura grupos de nodos creados manualmente

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

Crea tu clúster de GKE

Puedes elegir implementar tu canalización de transferencia de datos con un clúster de Standard o Autopilot con la versión 1.33.2-gke.4780000 o posterior de GKE. Cada tipo de clúster tiene sus propias ventajas y diferentes modelos de precios.

Elige Autopilot para facilitar la administración del clúster, la eficiencia en los costos y el ajuste de escala automático.
Elige Estándar con el aprovisionamiento automático de nodos habilitado si necesitas el ajuste de escala automático con más control sobre el aprovisionamiento de nodos.
Elige Standard sin el aprovisionamiento automático de nodos habilitado si necesitas el máximo control y te sientes cómodo administrando todos los aspectos del aprovisionamiento, el ajuste de escala y el mantenimiento de nodos.

Autopilot

En los clústeres de GKE Autopilot, GKE controla automáticamente la creación y eliminación de los nodos necesarios para los trabajos de transferencia de datos. Cuando se completa el trabajo de transferencia, los recursos del nodo se reducen automáticamente. No es necesario que borres de forma manual los Pods de transferencia ni los nodos en los que se ejecutaron los Pods.

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

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

Reemplaza lo siguiente:

CLUSTER_NAME: Es el nombre del clúster que crearás.
LOCATION: Es la región de procesamiento del clúster. Por ejemplo, us-central1
CLUSTER_VERSION: Es la versión de GKE para el clúster. En esta guía, se usa 1.33.2-gke.4780000.

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

En los clústeres de GKE estándar con el aprovisionamiento automático de nodos habilitado, GKE controla automáticamente la creación y el borrado de los nodos necesarios para los trabajos de transferencia de datos. Cuando se completa el trabajo de transferencia, los recursos del nodo se reducen automáticamente. No es necesario que borres de forma manual los Pods de transferencia ni los nodos en los que se ejecutaron los Pods.

Para crear un clúster estándar nuevo 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

Reemplaza lo siguiente:

CLUSTER_NAME: Es el nombre del clúster que creas con el aprovisionamiento automático de nodos habilitado.
CLUSTER_VERSION: Es la versión de GKE para el clúster. En esta guía, se usa 1.33.2-gke.4780000.
LOCATION: Es la zona o región de procesamiento del clúster. Por ejemplo, us-central1-a o us-central1.
PROJECT_ID: El ID de tu proyecto de Google Cloud .
MINIMUM_CPU: Es la cantidad mínima de CPU virtuales que se aprovisionan automáticamente. Por ejemplo, 10
MINIMUM_MEMORY: Es la cantidad mínima de memoria en GiB que se puede aprovisionar automáticamente. Por ejemplo, 200
MAXIMUM_CPU: Es la cantidad máxima de CPU virtuales que se pueden aprovisionar automáticamente. Por ejemplo, 100 Este límite es el total de los recursos de CPU en todos los grupos de nodos existentes creados manualmente y en todos los grupos de nodos que GKE podría crear automáticamente.
MAXIMUM_MEMORY: Es la 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 en todos los grupos de nodos existentes creados manualmente y en todos los grupos de nodos que GKE podría crear automáticamente.

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

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

Especifica la clase de procesamiento gcs-to-hdml-compute-class como etiqueta de nodo cuando crees tu clúster y grupo de nodos. Ten en cuenta que el nombre de la clase de procesamiento, gcs-to-hdml-compute-class, está predefinido para el trabajo de transferencia y debe especificarse exactamente.

Para crear un clúster Standard nuevo sin aprovisionamiento automático de nodos y un grupo de nodos nuevo dentro de 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"

Reemplaza lo siguiente:

CLUSTER_NAME: Es el nombre del clúster que creas sin el aprovisionamiento automático de nodos habilitado.
CLUSTER_VERSION: Es la versión de GKE para el clúster. En esta guía, se usa 1.33.2-gke.4780000.
LOCATION: Es la región de procesamiento del clúster. Por ejemplo, us-central1-a o us-central1.
PROJECT_ID es el ID de tu proyecto de Google Cloud .
NODE_POOL_NAME: Es el nombre del grupo de nodos que crearás en tu clúster nuevo. El propagador de volúmenes de GKE usa este grupo de nodos para implementar los trabajos temporales de transferencia de datos.

Para evitar incurrir en costos innecesarios, ejecuta el comando gcloud container node-pools delete para borrar cualquier grupo de nodos de transferencia creado manualmente después de que se complete la transferencia de datos.

Crea tu clase de procesamiento

Para crear una clase de procesamiento que especifique y priorice los tipos de VMs que se pueden usar como nodos en tu clúster, sigue estos pasos:

Guarda el siguiente manifiesto como computeclass.yaml:
Con el aprovisionamiento automático de nodos

En el caso de los clústeres de Autopilot y los clústeres de Standard con el aprovisionamiento automático de nodos habilitado, define tu clase de procesamiento 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 nuevos con la etiqueta de clase de procesamiento 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 aprovisionamiento automático de nodos

En el caso de los clústeres estándar sin el aprovisionamiento automático de nodos habilitado, define tu clase de procesamiento sin la sección nodePoolAutoCreation de la siguiente manera. Asegúrate de haber creado un grupo de nodos con la etiqueta de clase de procesamiento 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.
Para crear la clase de procesamiento, aplica el manifiesto:
```
kubectl apply -f computeclass.yaml
```

Configura los permisos necesarios

Para transferir datos desde un bucket de Cloud Storage, configura los permisos necesarios para la federación de identidades para cargas de trabajo de GKE. Con los permisos adecuados, el trabajo de transferencia creado por GKE Volume Populator puede acceder a tu bucket de Cloud Storage. En esta guía, se supone que ya tienes un bucket de Cloud Storage completado con los datos de entrenamiento de modelos que deseas transferir.

Crea un espacio de nombres de Kubernetes:
```
kubectl create namespace NAMESPACE
```
Reemplaza NAMESPACE por el espacio de nombres en el que deseas que se ejecuten tus cargas de trabajo.

Omite este paso si usas un espacio de nombres existente.

Nota: Asegúrate de usar el mismo espacio de nombres para crear todos los recursos de esta guía.
Crea una cuenta de servicio de Kubernetes:
```
kubectl create serviceaccount KSA_NAME \
    --namespace=NAMESPACE
```
Reemplaza lo siguiente:
- KSA_NAME: Es 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 de Google Cloud .
- NAMESPACE: Es el espacio de nombres de Kubernetes que creaste en el paso anterior.
Precaución: Si vuelves a usar esta cuenta de servicio de Kubernetes en otras cargas de trabajo dentro del mismo espacio de nombres, ese Pod podrá acceder al bucket de Cloud Storage que usas en esta guía. No recomendamos volver a usar esta cuenta de servicio para otras cargas de trabajo en el espacio de nombres.
Otorga a tu cuenta de servicio de IAM el rol adecuado para acceder a tu bucket 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"
```
Reemplaza lo siguiente:
- GCS_BUCKET: el nombre de tu bucket de Cloud Storage.
- PROJECT_NUMBER: Es el identificador numérico de tu proyecto de Google Cloud en el que creaste el clúster. Para encontrar el número de tu proyecto, consulta Identifica proyectos.
- PROJECT_ID: El ID de tu proyecto de Google Cloud .
- NAMESPACE: Es el espacio de nombres que creaste antes y en el que se ejecutarán tus cargas de trabajo.
- KSA_NAME: Es el nombre de la cuenta de servicio de Kubernetes que especificaste en el recurso GCPDataSource. El trabajo de transferencia creado por GKE Volume Populator usa esta cuenta de servicio para autenticarse en las APIs de Google Cloud .
- ROLE: Es el rol de IAM que deseas otorgar a tu cuenta de servicio. Para los fines de esta guía, otorga el rol roles/storage.objectViewer para permitir la lectura desde el bucket.
Los parámetros PROJECT_NUMBER, PROJECT_ID, NAMESPACE y KSA_NAME se usan para construir el identificador principal de la federación de identidades para cargas de trabajo para GKE de tu proyecto.

Crea 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, y para activar y administrar el proceso de transferencia de datos automatizado con el propagador de volúmenes de GKE:

Crea un recurso personalizado GCPDataSource para definir la fuente de los datos.
Crea una StorageClass para definir el tipo de almacenamiento persistente (un volumen de Hyperdisk ML) que se usará.
Crea un PersistentVolumeClaim para habilitar el aprovisionamiento dinámico del almacenamiento y el acceso al volumen de Hyperdisk ML aprovisionado recientemente.
(Opcional) Consulta el progreso de la transferencia de datos.
Crea e implementa un Pod que consuma el volumen de Hyperdisk ML.

Crea un recurso personalizado `GCPDataSource`

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

Guarda el siguiente 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/
```
Reemplaza los siguientes valores:
- GCP_DATA_SOURCE: Es el nombre del CRD GCPDataSource que contiene una referencia a tu bucket 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: Es el nombre de la cuenta de servicio de Kubernetes que especificaste en el recurso GCPDataSource. El trabajo de transferencia creado por GKE Volume Populator usa esta cuenta de servicio para autenticarse en las APIs de Google Cloud . El valor de cloudStorage.serviceAccountName es la cuenta de servicio de Kubernetes que configuraste para la federación de identidades para cargas de trabajo para GKE en la sección Configura los permisos necesarios.
- GCS_BUCKET: el nombre de tu bucket de Cloud Storage. El campo uri especifica los datos de origen.
  - Para copiar todo el bucket, usa gs://GCS_BUCKET/.
  - Para copiar datos de una carpeta específica dentro del bucket, usa el formato gs://GCS_BUCKET/PATH_INSIDE_BUCKET/. Por ejemplo, para copiar datos de la carpeta gemma/v1.0/weights/ dentro del bucket my-project-llm-models, el URI sería gs://my-project-llm-models/gemma/v1.0/weights/. Asegúrate de que la ruta de acceso termine con una barra final para indicar una carpeta.
Para crear el recurso GCPDataSource, aplica el manifiesto:
```
kubectl apply -f gcpdatasource.yaml
```

Crea un StorageClass de Hyperdisk ML

Crea una StorageClass que use el aprovisionador pd.csi.storage.gke.io para aprovisionar un volumen de Hyperdisk ML en la zona que elijas. Si deseas que las copias de tus datos sean accesibles en más de una zona, puedes crear una StorageClass multizona. Este es un ejemplo de una StorageClass multizona.

Guarda el siguiente 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
```
Reemplaza ZONE por la zona de destino en la que deseas que se cree el volumen de Hyperdisk ML:
- En el caso de los clústeres de GKE Standard sin aprovisionamiento automático de nodos, el valor de ZONE debe ser la ubicación en la que creaste los nodos.
- En el caso de los clústeres de GKE Autopilot o Standard con aprovisionamiento automático de nodos, el valor de ZONE debe ser la ubicación en la que tu clúster puede aumentar la escala y crear nodos nuevos si es necesario.
(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)"
```
Reemplaza lo siguiente:
- CLUSTER_NAME: El nombre de tu clúster.
- LOCATION: Es la zona o región de procesamiento del clúster. Por ejemplo, us-central1-a o us-central1.
Para crear el objeto StorageClass, aplica el manifiesto :
```
kubectl apply -f hdml-class.yaml
```

Crea un objeto PersistentVolumeClaim para acceder al volumen

En el siguiente manifiesto, se muestra un ejemplo de cómo crear un PersistentVolumeClaim en el modo de acceso ReadOnlyMany que hace referencia a la StorageClass que creaste antes.

Guarda el siguiente 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
```
Reemplaza los siguientes valores:
- PVC_NAME: Es el nombre del PersistentVolumeClaim al que deseas transferir tus datos.
- NAMESPACE: Es el espacio de nombres en el que se ejecutarán tus cargas de trabajo.
- DISK_SIZE: Es el tamaño del disco, en gigabytes, que se creará para completar los datos. Para completar los datos correctamente, asegúrate de que el tamaño del disco solicitado sea mayor que el tamaño de los datos de tu modelo que se encuentran en el bucket de Cloud Storage. Para cumplir con el rango admitido para los volúmenes de Hyperdisk ML, el valor de DISK_SIZE debe ser mayor que 4 Gi. Para obtener más información, consulta Límites de tamaño de volúmenes de Hyperdisk.
- GCP_DATA_SOURCE: Es el nombre del GCPDataSource CRD que contiene una referencia a tu bucket de Cloud Storage.
Puedes personalizar la transferencia de datos agregando anotaciones opcionales a tu PVC. Estas anotaciones influyen en el comportamiento del trabajo de transferencia subyacente que copia 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 una solicitud de recursos de CPU diferente, la PVC solicita 24 CPU virtuales 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 volumen nuevo que almacenará los datos copiados de tu recurso GCPDataSource. Si no especificas una ruta de acceso diferente, los datos se copiarán a la ruta de acceso raíz dentro del volumen de Hyperdisk ML.

Para crear el PVC, aplica el manifiesto:

kubectl apply -f volume-populator-pvc.yaml

Ten en cuenta los siguientes puntos:

Si configuras el campo volumeBindingMode en tu StorageClass como immediate, la transferencia de datos se activará inmediatamente después de implementar la PVC.
Si configuras el campo volumeBindingMode en tu StorageClass como WaitForFirstConsumer, la transferencia de datos se activará solo después de que implementes un Pod que solicite la PVC y ese Pod se programe correctamente en un nodo. Si bien tu Pod se puede programar, sus contenedores esperarán a que se complete la transferencia de datos y el volumen esté listo para usarse.

Para verificar el progreso de la transferencia de datos, consulta Cómo ver el progreso de la transferencia de datos. Si encuentras errores durante el aprovisionamiento de recursos o la transferencia de datos, consulta Cómo solucionar problemas de transferencia de datos del Volume Populator de GKE.

(Opcional) Consulta el progreso de la transferencia de datos

En esta sección, se muestra cómo puedes hacer un seguimiento del progreso y el éxito de tus transferencias de datos desde un bucket de Cloud Storage a un volumen de Hyperdisk ML.

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
```
Reemplaza lo siguiente:
- PVC_NAME: El nombre de la PVC que creaste en la sección Crea una PersistentVolumeClaim para acceder al volumen.
- NAMESPACE: Es el espacio de nombres que se usa en toda esta guía y que creaste en la sección Configura los permisos necesarios.

En el resultado, revisa los eventos de PersistentVolumeClaim para supervisar el progreso de la transferencia de datos. GKE registra los eventos aproximadamente una vez por minuto. El resultado es similar a este:

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 propagación puede tardar varios minutos en comenzar, según el tamaño de los datos. Si no ves ningún progreso en la transferencia de datos después de varios minutos, consulta Solución de problemas de transferencia de datos del Volume Populator de GKE para obtener ayuda.

En el caso de las transferencias de datos de volúmenes de Hyperdisk ML multizona, el trabajo se marca como completado solo si los datos se transfieren correctamente a todas las zonas especificadas en StorageClass. Si falla el trabajo de transferencia para una o más zonas, el propagador de volúmenes de GKE vuelve a intentar transferir los datos de forma indefinida mientras exista la PVC.

Crea e implementa un Pod que consuma el volumen

Para crear un Pod que verifique el contenido de un PVC que se propagó con datos, haz lo siguiente:

Guarda el siguiente 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

Reemplaza lo siguiente:

NAMESPACE: Es el espacio de nombres en el que se encuentra tu PVC y en el que deseas crear el Pod verify-data.
PVC_NAME: Es el nombre del PVC que creaste para propagar datos en la sección Crea un PersistentVolumeClaim para acceder al volumen.

Crea el Pod con el siguiente comando:
```
kubectl create -f verify-data.yaml
```

Para enumerar los archivos, ejecuta el siguiente comando:

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

Si el comando se ejecuta correctamente, puedes encontrar los datos completados en el directorio /models dentro de tu bucket de Cloud Storage.

Limpia

Para evitar costos innecesarios y quitar los recursos huérfanos o mal configurados, sigue los pasos para borrar correctamente el PersistentVolumeClaim.

Borra la PersistentVolumeClaim durante el aprovisionamiento dinámico

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

Reemplaza las siguientes variables relevantes durante el proceso de eliminación:

POD_NAME: Es el nombre del Pod que creaste en la sección Crea e implementa un Pod que consuma el volumen.
NAMESPACE: Es el espacio de nombres en el que se encuentra tu PVC.
PVC_NAME: Es el nombre del PVC que creaste en la sección Crea un objeto PersistentVolumeClaim para acceder al volumen.
GCP_DATA_SOURCE: Es el nombre del recurso personalizado de GCPDataSource que creaste en la sección Crea un recurso personalizado de GCPDataSource.

Borra el Pod de carga de trabajo:

kubectl delete pod POD_NAME -n NAMESPACE

Busca el nombre de la 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}

Borra el PVC que se creó en el espacio de nombres:
```
kubectl delete pvc PVC_NAME -n NAMESPACE
```

Es posible que el PVC esté atascado en el estado Terminating:

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

Si es así, limpia el PVC de forma manual quitando sus finalizadores:

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

Borra el recurso GCPDataSource solo después de que se borre el PVC. Si borras primero el recurso GCPDataSource, se bloqueará el borrado de la PVC.
```
kubectl delete gcpdatasource GCP_DATA_SOURCE -n NAMESPACE
```
Verifica que los recursos temporales se hayan borrado.

¿Qué sigue?

Obtén información sobre GKE Volume Populator.
Si necesitas ayuda con problemas de transferencia de datos, consulta Soluciona problemas de transferencia de datos del Volume Populator de GKE.
Para ver un ejemplo avanzado de carga de trabajo de Hyperdisk ML, consulta Acelera la carga de datos de IA/AA con Hyperdisk ML.

Automatiza la transferencia de datos de Cloud Storage a un volumen de Hyperdisk ML con GKE Volume Populator Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

Administración de grupos de nodos para el propagador de volúmenes de GKE con Hyperdisk ML

Objetivos

Antes de comenzar

Requisitos

Costos

Prepara el entorno

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

Crea tu clúster de GKE

Autopilot

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

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

Crea tu clase de procesamiento

Con el aprovisionamiento automático de nodos

Sin aprovisionamiento automático de nodos

Configura los permisos necesarios

Crea un volumen de Hyperdisk ML con datos precargados

Crea un recurso personalizado GCPDataSource

Crea un StorageClass de Hyperdisk ML

Crea un objeto PersistentVolumeClaim para acceder al volumen

(Opcional) Consulta el progreso de la transferencia de datos

Crea e implementa un Pod que consuma el volumen

Limpia

Borra la PersistentVolumeClaim durante el aprovisionamiento dinámico

¿Qué sigue?

Automatiza la transferencia de datos de Cloud Storage a un volumen de Hyperdisk ML con GKE Volume Populator

Crea un recurso personalizado `GCPDataSource`