Esta página foi traduzida pela API Cloud Translation.

Automatize a transferência de dados do Cloud Storage para um volume de ML do Hyperdisk através do GKE Volume Populator

Autopilot Padrão

Este guia descreve como pode pré-carregar grandes quantidades de dados de um contentor do Cloud Storage para um volume do Hyperdisk ML do Google Kubernetes Engine (GKE) durante o aprovisionamento dinâmico através do GKE Volume Populator. Para mais informações, consulte o artigo Acerca do GKE Volume Populator.

Este guia destina-se a especialistas de armazenamento que criam e atribuem armazenamento, e gerem a segurança e o acesso aos dados. Para saber mais sobre as funções comuns e as tarefas de exemplo que referimos no Google Cloud conteúdo, consulte o artigo Funções e tarefas de utilizador comuns do GKE Enterprise.

Gestão do conjunto de nós para o GKE Volume Populator com o Hyperdisk ML

O dimensionamento, o aprovisionamento e a escalabilidade eficientes do conjunto de nós são fundamentais para executar com êxito as tarefas de transferência de dados criadas pelo GKE Volume Populator para preencher volumes de ML do Hyperdisk. Usa uma classe de computação para definir os requisitos dos nós, como o tipo e o tamanho da máquina, para estas tarefas de transferência de dados específicas. Uma classe de computação permite-lhe controlar o custo e o desempenho do processo de transferência de dados. Para mais informações, consulte o artigo Vantagens das classes de computação personalizadas.

Para escolher um cluster mais adequado para as suas tarefas de transferência de dados, compreenda como as classes de computação funcionam com diferentes tipos de clusters para o Hyperdisk ML.

Objetivos

Neste guia, vai realizar as seguintes tarefas:

Configure o ambiente do cluster do GKE para suportar transferências de dados através do GKE Volume Populator, incluindo a criação de clusters, a definição da classe de computação e a configuração de autorizações.
Crie um GCPDataSource recurso personalizado para especificar o contentor do Cloud Storage de origem.
Defina um StorageClass para o Hyperdisk ML.
Crie um PersistentVolumeClaim que faça referência ao GCPDataSource para acionar o preenchimento de dados num volume do Hyperdisk ML.
Valide a transferência de dados.
Consumir o volume preenchido num Pod.
Limpe os recursos.

Antes de começar

Certifique-se de que realizou as seguintes tarefas:

Ative as APIs GKE e Cloud Storage.

Ative as APIs
Certifique-se de que a faturação está ativada para o seu Google Cloud projeto.
Transfira e instale a ferramenta de linha de comandos da CLI Google Cloud ou use a Cloud Shell para executar os comandos gcloud CLI e kubectl. O Cloud Shell é um ambiente de shell para gerir recursos alojados no Google Cloud. Vem pré-instalado com a ferramenta de linhas de comando gcloud e kubectl.
Defina uma região e uma zona predefinidas.
Crie ou use um contentor do Cloud Storage existente. Este guia pressupõe que já tem um contentor do Cloud Storage preenchido com os dados de preparação do modelo.
Ative o controlador CSI do Persistent Disk do Compute Engine em clusters padrão existentes que possam ter o controlador explicitamente desativado. Nos novos clusters do Autopilot e Standard, o GKE ativa o controlador por predefinição. O armazenamento Hyperdisk ML de destino que criar tem de ser gerido pelo controlador CSI do Persistent Disk do Compute Engine.
Ative a federação de identidade da força de trabalho para o GKE no seu cluster. Isto permite que a conta de serviço do Kubernetes usada pelo GKE Volume Populator aceda ao contentor do Cloud Storage de origem. Para mais informações, consulte o artigo Configure as autorizações necessárias.

Requisitos

Para transferir dados através do GKE Volume Populator, cumpra os seguintes requisitos:

O cluster do GKE tem de estar a executar a versão 1.33.2-gke.4780000 ou posterior.
O seu recurso personalizado GCPDataSource tem de estar no mesmo espaço de nomes que a carga de trabalho do GKE. As origens de dados que abrangem diferentes espaços de nomes não são suportadas.
Selecione uma MV suportada quando criar a sua classe de computação. Confirme se o seu projeto tem quota suficiente para o tipo de máquina que selecionar.
O nome da classe de computação gcs-to-hdml-compute-class é predefinido para a tarefa de transferência e tem de ser especificado exatamente quando cria a classe de computação.

Custos

Embora não exista um custo direto para usar o GKE Volume Populator, o armazenamento e as transferências de dados incorrem em encargos de faturação. Os custos indiretos associados incluem o seguinte:

Instâncias do Compute Engine usadas pelo GKE: o custo dos nós usados para executar as tarefas de transferência de dados. A gestão de nós e as implicações de custos variam consoante os tipos de clusters. Para mais informações, consulte os respetivos tipos de clusters em Crie o seu cluster do GKE.
Tamanho do nó da tarefa de transferência: para um desempenho de transferência ideal, uma tarefa de transferência aumenta por predefinição um nó com 24 vCPUs. Isto aplica-se a todos os tipos de clusters. Se quiser ajustar o tamanho e o tipo do nó para otimizações de custos ou de desempenho específicas, pode fazê-lo quando criar a classe de computação.
Armazenamento usado no seu contentor do Cloud Storage: para mais informações, consulte os preços do Cloud Storage.
Custos do volume de ML do Hyperdisk: isto inclui a capacidade de armazenamento e o desempenho (IOPS/débito) dos volumes de ML do Hyperdisk que criar. Para mais informações, consulte os preços do Hyperdisk.

Prepare o seu ambiente

Nesta secção, cria a infraestrutura do cluster do GKE com o hardware adequado e configura as autorizações necessárias para aceder aos seus dados no Cloud Storage.

Antes de criar o cluster para usar o GKE Volume Populator com o Hyperdisk ML, compreenda como uma classe de computação é aplicada a diferentes tipos de clusters e quem é responsável pela gestão de nós: o GKE ou o utilizador.

Como funcionam as classes de computação com diferentes tipos de clusters para o Hyperdisk ML

O GKE Volume Populator usa uma classe de computação personalizada para determinar os tipos de nós a usar para as tarefas de transferência de dados. A tabela seguinte descreve o comportamento da classe de computação consoante a configuração do cluster:

Ponderação	GKE Autopilot e GKE Standard com aprovisionamento automático de nós	GKE Standard sem aprovisionamento automático de nós
Definição da classe de computação	`nodePoolAutoCreation` ativado	`nodePoolAutoCreation` desativado
Gestão de nós	O GKE cria e gere automaticamente os nós.	Cria e gere nós manualmente.
Escala dos nós	Automático	Manual
Etiquetagem de nós	Não aplicável	Tem de etiquetar os nós com `cloud.google.com/compute-class=gcs-to-hdml-compute-class`
Mais informações	Aprovisionamento automático de nós e classes de computação	Configure node pools criados manualmente

O GKE inicia a tarefa de transferência de dados após o aprovisionamento do PersistentVolume para o PersistentVolumeClaim. Para preencher o volume de ML do Hyperdisk, este PersistentVolumeClaim tem de fazer referência ao GCPDataSource, que define os dados de origem no Cloud Storage.

Crie o seu cluster do GKE

Pode optar por implementar o pipeline de transferência de dados usando um cluster padrão ou do Autopilot com a versão 1.33.2-gke.4780000 ou posterior do GKE. Cada tipo de cluster tem as suas próprias vantagens e modelos de preços diferentes.

Escolha o Autopilot para uma gestão de clusters mais fácil, rentabilidade e escalamento automático.
Escolha a opção Padrão com o aprovisionamento automático de nós ativado se precisar de escalamento automático com mais controlo sobre o aprovisionamento de nós.
Escolha a opção Padrão sem o aprovisionamento automático de nós ativado se precisar do controlo máximo e se sentir confortável a gerir todos os aspetos do aprovisionamento, da escalabilidade e da manutenção de nós.

Piloto automático

Nos clusters do GKE Autopilot, o GKE processa automaticamente a criação e a eliminação dos nós necessários para as tarefas de transferência de dados. Quando a tarefa de transferência estiver concluída, os recursos de nós são reduzidos automaticamente. Não tem de eliminar manualmente os pods de transferência nem os nós nos quais os pods foram executados.

Para criar um novo cluster do Autopilot, execute o seguinte comando:

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

Substitua o seguinte:

CLUSTER_NAME: o nome do cluster que está a criar.
LOCATION: a região de computação do cluster. Por exemplo, us-central1.
CLUSTER_VERSION: a versão do GKE para o cluster. Utilizar 1.33.2-gke.4780000 neste guia.

Padrão (com aprovisionamento automático de nós)

Nos clusters padrão do GKE com o aprovisionamento automático de nós ativado, o GKE processa automaticamente a criação e a eliminação de nós necessários para as tarefas de transferência de dados. Quando a tarefa de transferência estiver concluída, os recursos de nós são reduzidos automaticamente. Não tem de eliminar manualmente os pods de transferência nem os nós nos quais os pods foram executados.

Para criar um novo cluster padrão com o aprovisionamento automático de nós ativado, execute o seguinte 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

Substitua o seguinte:

CLUSTER_NAME: o nome do cluster que está a criar com o aprovisionamento automático de nós ativado.
CLUSTER_VERSION: a versão do GKE para o cluster. Utilizar 1.33.2-gke.4780000 neste guia.
LOCATION: a zona de computação ou a região do cluster. Por exemplo, us-central1-a ou us-central1.
PROJECT_ID: o ID do seu Google Cloud projeto.
MINIMUM_CPU: o número mínimo de vCPUs a aprovisionar automaticamente. Por exemplo, 10.
MINIMUM_MEMORY: a quantidade mínima de memória em GiB para o aprovisionamento automático. Por exemplo, 200.
MAXIMUM_CPU: o número máximo de vCPUs a aprovisionar automaticamente. Por exemplo, 100. Este limite é o total dos recursos da CPU em todos os conjuntos de nós criados manualmente existentes e em todos os conjuntos de nós que o GKE pode criar automaticamente.
MAXIMUM_MEMORY: a quantidade máxima de memória a aprovisionar automaticamente. Por exemplo, 1000. Este limite é o total dos recursos de memória em todos os node pools existentes criados manualmente e em todos os node pools que o GKE pode criar automaticamente.

Padrão (sem aprovisionamento automático de nós)

Para usar o GKE Volume Populator num cluster Standard onde o aprovisionamento automático de nós não está ativado, pode usar um conjunto de nós existente ou criar um conjunto de nós de transferência dedicado. Os nós têm de ter capacidade para executar as tarefas de transferência e as etiquetas correspondentes ao compute-class.

Especifique a classe de computação gcs-to-hdml-compute-class como uma etiqueta de nó quando criar o cluster e o node pool. Tenha em atenção que o nome da classe de computação, gcs-to-hdml-compute-class, está predefinido para a tarefa de transferência e tem de ser especificado exatamente.

Para criar um novo cluster padrão sem aprovisionamento automático de nós e um novo conjunto de nós nesse cluster, execute os seguintes 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"

Substitua o seguinte:

CLUSTER_NAME: o nome do cluster que está a criar sem o aprovisionamento automático de nós ativado.
CLUSTER_VERSION: a versão do GKE para o cluster. Utilizar 1.33.2-gke.4780000 neste guia.
LOCATION: a região de computação do cluster. Por exemplo, us-central1-a ou us-central1.
PROJECT_ID o ID do seu Google Cloud projeto.
NODE_POOL_NAME: o nome do conjunto de nós que está a criar no novo cluster. Este conjunto de nós é usado pelo GKE Volume Populator para implementar as tarefas de transferência de dados temporárias.

Para evitar custos desnecessários, execute o comando gcloud container node-pools delete para eliminar todos os conjuntos de nós de transferência criados manualmente após a conclusão da transferência de dados.

Crie a sua classe de computação

Para criar uma classe de computação para especificar e dar prioridade aos tipos de VMs que podem ser usados como nós no seu cluster, siga estes passos:

Guarde o seguinte manifesto como computeclass.yaml:
Com o aprovisionamento automático de nós

Para clusters do Autopilot e clusters Standard com o aprovisionamento automático de nós ativado, defina a sua classe de computação com a secção nodePoolAutoCreation da seguinte forma. Quando o aprovisionamento automático de nós está ativado, o GKE cria automaticamente novos conjuntos de nós com a etiqueta de classe de computação 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
Sem o aprovisionamento automático de nós

Para clusters padrão sem o aprovisionamento automático de nós ativado, defina a classe de computação sem a secção nodePoolAutoCreation da seguinte forma. Certifique-se de que já criou um conjunto de nós com a etiqueta de classe de computação 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
Pode especificar qualquer machineFamily compatível para satisfazer as suas necessidades de transferência de dados. Para mais informações sobre a seleção de um tipo de máquina adequado, consulte o artigo Suporte de séries de máquinas para o Hyperdisk ML.
Para criar a classe de computação, aplique o manifesto:
```
kubectl apply -f computeclass.yaml
```

Configure as autorizações necessárias

Para transferir dados de um contentor do Cloud Storage, configure as autorizações necessárias para a Workload Identity Federation para o GKE. Com as autorizações adequadas, a tarefa de transferência criada pelo GKE Volume Populator pode aceder ao seu contentor do Cloud Storage. Este guia pressupõe que já tem um contentor do Cloud Storage preenchido com os dados de preparação do modelo que quer transferir.

Crie um namespace do Kubernetes:
```
kubectl create namespace NAMESPACE
```
Substitua NAMESPACE pelo espaço de nomes no qual quer que as suas cargas de trabalho sejam executadas.

Ignore este passo se estiver a usar um espaço de nomes existente.

Nota: certifique-se de que usa o mesmo espaço de nomes para criar todos os recursos neste guia.
Crie uma conta de serviço do Kubernetes:
```
kubectl create serviceaccount KSA_NAME \
    --namespace=NAMESPACE
```
Substitua o seguinte:
- KSA_NAME: o nome da conta de serviço do Kubernetes que vai especificar no recurso GCPDataSource. A tarefa de transferência criada pelo GKE Volume Populator usa esta conta de serviço para fazer a autenticação nas Google Cloud APIs.
- NAMESPACE: o namespace do Kubernetes que criou no passo anterior.
Aviso: a reutilização desta conta de serviço do Kubernetes noutras cargas de trabalho no mesmo espaço de nomes permite que esse pod aceda ao contentor do Cloud Storage que está a usar neste guia. Não recomendamos a reutilização desta conta de serviço para outras cargas de trabalho no espaço de nomes.
Conceda à sua conta de serviço do IAM) a função adequada para aceder ao seu contentor do 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"
```
Substitua o seguinte:
- GCS_BUCKET: o nome do seu contentor do Cloud Storage.
- PROJECT_NUMBER: o identificador numérico do seu projeto do Google Cloud Google Cloud onde criou o cluster. Para encontrar o número do projeto, consulte o artigo Identificar projetos.
- PROJECT_ID: o ID do seu Google Cloud projeto.
- NAMESPACE: o espaço de nomes que criou anteriormente onde as suas cargas de trabalho vão ser executadas.
- KSA_NAME: o nome da conta de serviço do Kubernetes que especificou no recurso GCPDataSource. A tarefa de transferência criada pelo GKE Volume Populator usa esta conta de serviço para fazer a autenticação nas Google Cloud APIs.
- ROLE: a função de IAM que quer conceder à sua conta de serviço. Para efeitos deste guia, conceda a função roles/storage.objectViewer para permitir a leitura do contentor.
Os campos PROJECT_NUMBER, PROJECT_ID, NAMESPACE e KSA_NAME são usados para criar o identificador principal da Workload Identity Federation para o GKE do seu projeto.

Crie um volume de ML do Hyperdisk com dados pré-carregados

Execute os passos seguintes para configurar a infraestrutura e a configuração do GKE necessárias para criar um volume de ML do Hyperdisk e para acionar e gerir o processo de transferência de dados automatizado através do GKE Volume Populator:

Crie um GCPDataSourcerecurso personalizado para definir a origem dos dados.
Crie uma StorageClass para definir o tipo de armazenamento persistente (um volume de ML do Hyperdisk) a ser usado.
Crie um PersistentVolumeClaim para ativar o aprovisionamento dinâmico do armazenamento e permitir o acesso ao volume do Hyperdisk ML recém-aprovisionado.
(Opcional) Veja o progresso da transferência de dados.
Crie e implemente um pod que consuma o volume de ML do Hyperdisk.

Crie um `GCPDataSource` recurso personalizado

Crie um recurso personalizado GCPDataSource no GKE para especificar a localização do contentor do Cloud Storage de origem e a conta de serviço com as autorizações necessárias para aceder a esse contentor. Esta definição de recurso personalizado (CRD) é específica do GKE Volume Populator.

Guarde o seguinte manifesto 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/
```
Substitua os seguintes valores:
- GCP_DATA_SOURCE: o nome do CRD que contém uma referência ao seu contentor do Cloud Storage.GCPDataSource Para mais informações, consulte a GCPDataSourcereferência CRD.
- NAMESPACE: o mesmo espaço de nomes no qual as suas cargas de trabalho são executadas. O recurso personalizado GCPDataSource é criado neste espaço de nomes.
- KSA_NAME: o nome da conta de serviço do Kubernetes que especificou no recurso GCPDataSource. A tarefa de transferência criada pelo GKE Volume Populator usa esta conta de serviço para fazer a autenticação nas Google Cloud APIs. O valor cloudStorage.serviceAccountName é a conta de serviço do Kubernetes que configurou para a federação de identidades da carga de trabalho para o GKE na secção Configure as autorizações necessárias.
- GCS_BUCKET: o nome do seu contentor do Cloud Storage. O campo uri especifica os dados de origem.
  - Para copiar todo o contentor, use gs://GCS_BUCKET/.
  - Para copiar dados de uma pasta específica no contentor, use o formato gs://GCS_BUCKET/PATH_INSIDE_BUCKET/. Por exemplo, para copiar dados da pasta gemma/v1.0/weights/ no contentor my-project-llm-models, o URI seria gs://my-project-llm-models/gemma/v1.0/weights/. Certifique-se de que o caminho termina com uma barra para indicar uma pasta.
Para criar o recurso GCPDataSource, aplique o manifesto:
```
kubectl apply -f gcpdatasource.yaml
```

Crie uma StorageClass do Hyperdisk ML

Crie uma StorageClass que use o aprovisionador pd.csi.storage.gke.io para aprovisionar um volume do Hyperdisk ML na zona escolhida. Se quiser que as cópias dos seus dados estejam acessíveis em mais do que uma zona, pode criar uma StorageClass multizonal. Segue-se um exemplo de uma StorageClass de várias zonas.

Guarde o seguinte manifesto 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
```
Substitua ZONE pela zona de destino onde quer que o volume do Hyperdisk ML seja criado:
- Para o cluster padrão do GKE sem aprovisionamento automático de nós, o valor de ZONE tem de ser a localização onde criou os nós.
- Para clusters do GKE Autopilot ou Standard com aprovisionamento automático de nós, o valor de ZONE tem de ser a localização onde o cluster pode ser expandido e criar novos nós, se necessário.
(Opcional) Para apresentar uma lista das localizações dos nós do cluster, execute o seguinte comando:
```
gcloud container clusters describe CLUSTER_NAME --location=LOCATION --format="value(locations)"
```
Substitua o seguinte:
- CLUSTER_NAME: o nome do cluster.
- LOCATION: a zona de computação ou a região do cluster. Por exemplo, us-central1-a ou us-central1.
Para criar a StorageClass, aplique o manifesto :
```
kubectl apply -f hdml-class.yaml
```

Crie uma PersistentVolumeClaim para aceder ao volume

O manifesto seguinte mostra um exemplo de como criar um PersistentVolumeClaim no modo de acesso ReadOnlyMany que faz referência à StorageClass que criou anteriormente.

Guarde o seguinte manifesto 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
```
Substitua os seguintes valores:
- PVC_NAME: o nome do PersistentVolumeClaim para o qual quer transferir os seus dados.
- NAMESPACE: o espaço de nomes onde as suas cargas de trabalho vão ser executadas.
- DISK_SIZE: o tamanho do disco, em gigabytes, que vai ser criado para preencher os dados. Para preencher os dados com êxito, certifique-se de que o tamanho do disco pedido é superior ao tamanho dos dados do seu modelo que se encontram no contentor do Cloud Storage. Para estar em conformidade com o intervalo suportado para os volumes de ML do Hyperdisk, o valor de DISK_SIZE tem de ser superior a 4 Gi. Para mais informações, consulte os limites de tamanho dos volumes do Hyperdisk.
- GCP_DATA_SOURCE: o nome do GCPDataSource CRD que contém uma referência ao seu contentor do Cloud Storage.
Pode personalizar a transferência de dados adicionando anotações opcionais ao seu PVC. Estas anotações influenciam o comportamento da tarefa de transferência subjacente que copia os dados para o volume de ML do Hyperdisk.
- volume-populator.datalayer.gke.io/cpu-request: use esta anotação para especificar um pedido de recurso de CPU diferente para a transferência Job. Se não especificar um pedido de recursos de CPU diferente, o PVC pede 24 vCPUs por predefinição para otimizar o desempenho da transferência.
- volume-populator.datalayer.gke.io/transfer-path: use esta anotação para especificar o caminho de destino no novo volume que vai armazenar os dados copiados do seu recurso GCPDataSource. Se não especificar um caminho diferente, os dados são copiados para o caminho raiz no volume de ML do Hyperdisk.

Para criar o PVC, aplique o manifesto:

kubectl apply -f volume-populator-pvc.yaml

Tenha em atenção os seguintes pontos:

Se definir o campo volumeBindingMode na sua StorageClass como immediate, a transferência de dados é acionada imediatamente após a implementação do PVC.
Se definir o campo volumeBindingMode na sua StorageClass como WaitForFirstConsumer, a transferência de dados só é acionada depois de implementar um Pod que peça o PVC e esse Pod seja agendado com êxito para um nó. Embora o seu Pod possa ser agendado, os respetivos contentores aguardam o início até que a transferência de dados seja concluída e o volume esteja pronto a ser usado.

Para verificar o progresso da transferência de dados, consulte o artigo Veja o progresso da transferência de dados. Se encontrar erros durante o aprovisionamento de recursos ou a transferência de dados, consulte o artigo Resolução de problemas de transferência de dados do GKE Volume Populator.

(Opcional) Veja o progresso da transferência de dados

Esta secção mostra como pode acompanhar o progresso e o êxito das suas transferências de dados de um contentor do Cloud Storage para um volume de ML do Hyperdisk.

Para verificar o estado do PersistentVolumeClaim, execute o seguinte comando. Também pode executar este comando se a operação de associação PersistentVolumeClaim demorar demasiado tempo a ser concluída.
```
kubectl describe pvc PVC_NAME -n NAMESPACE
```
Substitua o seguinte:
- PVC_NAME: o nome do PVC que criou na secção Crie um PersistentVolumeClaim para aceder ao volume.
- NAMESPACE: o espaço de nomes usado ao longo deste guia, que criou na secção Configure as autorizações necessárias.

Na saída, reveja os eventos PersistentVolumeClaim para monitorizar o progresso da transferência de dados. O GKE regista os eventos aproximadamente uma vez por minuto. O resultado é semelhante ao seguinte:

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

A operação de preenchimento pode demorar vários minutos a iniciar, consoante o tamanho dos dados. Se não vir qualquer progresso na transferência de dados após vários minutos, consulte o artigo Resolução de problemas de transferência de dados do GKE Volume Populator para obter ajuda.

Para transferências de dados de volumes de Hyperdisk ML em várias zonas, a tarefa é marcada como concluída apenas se os dados forem transferidos com êxito para todas as zonas especificadas na StorageClass. Se a tarefa de transferência falhar para uma ou mais zonas, o GKE Volume Populator tenta transferir os dados indefinidamente, desde que o PVC exista.

Crie e implemente um Pod que consuma o volume

Para criar um pod para validar o conteúdo de um PVC preenchido com dados:

Guarde o seguinte manifesto 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

Substitua o seguinte:

NAMESPACE: o espaço de nomes onde o PVC está localizado e onde quer criar o pod verify-data.
PVC_NAME: o nome do PVC que criou para o preenchimento de dados na secção Crie um PersistentVolumeClaim para aceder ao volume.

Crie o pod com o seguinte comando:
```
kubectl create -f verify-data.yaml
```
Para apresentar uma lista dos ficheiros, execute o seguinte comando:
```
kubectl exec -it verify-data -- /bin/sh
# cd /models && ls
```

Se o comando for bem-sucedido, pode encontrar os dados preenchidos no diretório /models no seu contentor do Cloud Storage.

Limpar

Para evitar custos desnecessários e remover recursos mal configurados ou órfãos, siga os passos para eliminar corretamente o PersistentVolumeClaim.

Elimine o PersistentVolumeClaim durante o aprovisionamento dinâmico

Se precisar de eliminar o seu PersistentVolumeClaim enquanto os dados ainda estão a ser transferidos durante o aprovisionamento dinâmico, siga os passos abaixo para uma eliminação elegante. A eliminação simples pode demorar algum tempo a ser concluída.

Substitua as seguintes variáveis relevantes durante o processo de eliminação:

POD_NAME: o nome do pod que criou na secção Crie e implemente um pod que consuma o volume.
NAMESPACE: o espaço de nomes onde o PVC está localizado.
PVC_NAME: o nome do PVC que criou na secção Crie um PersistentVolumeClaim para aceder ao volume.
GCP_DATA_SOURCE: o nome do recurso personalizado GCPDataSource que criou na secção Crie um recurso personalizado GCPDataSource.

Elimine o pod de carga de trabalho:

kubectl delete pod POD_NAME -n NAMESPACE

Encontre o nome do PersistentVolumeClaim temporário:

# 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}

Elimine o PVC que foi criado no espaço de nomes:
```
kubectl delete pvc PVC_NAME -n NAMESPACE
```

O PVC pode estar preso no estado Terminating:

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

Se for o caso, limpe manualmente o PVC removendo os respetivos finalizadores:

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

Elimine o recurso GCPDataSource apenas depois de o PVC ser eliminado. Se eliminar primeiro o recurso GCPDataSource, a eliminação do PVC fica bloqueada.
```
kubectl delete gcpdatasource GCP_DATA_SOURCE -n NAMESPACE
```
Verifique se os recursos temporários foram eliminados.

O que se segue?

Saiba acerca do GKE Volume Populator.
Para obter ajuda com problemas de transferência de dados, consulte o artigo Resolução de problemas de transferência de dados do GKE Volume Populator.
Para ver um exemplo avançado de carga de trabalho de ML do Hyperdisk, consulte o artigo Acelere o carregamento de dados de IA/ML com o Hyperdisk ML.

Automatize a transferência de dados do Cloud Storage para um volume de ML do Hyperdisk através do GKE Volume Populator Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Gestão do conjunto de nós para o GKE Volume Populator com o Hyperdisk ML

Objetivos

Antes de começar

Requisitos

Custos

Prepare o seu ambiente

Como funcionam as classes de computação com diferentes tipos de clusters para o Hyperdisk ML

Crie o seu cluster do GKE

Piloto automático

Padrão (com aprovisionamento automático de nós)

Padrão (sem aprovisionamento automático de nós)

Crie a sua classe de computação

Com o aprovisionamento automático de nós

Sem o aprovisionamento automático de nós

Configure as autorizações necessárias

Crie um volume de ML do Hyperdisk com dados pré-carregados

Crie um GCPDataSource recurso personalizado

Crie uma StorageClass do Hyperdisk ML

Crie uma PersistentVolumeClaim para aceder ao volume

(Opcional) Veja o progresso da transferência de dados

Crie e implemente um Pod que consuma o volume

Limpar

Elimine o PersistentVolumeClaim durante o aprovisionamento dinâmico

O que se segue?

Automatize a transferência de dados do Cloud Storage para um volume de ML do Hyperdisk através do GKE Volume Populator

Crie um `GCPDataSource` recurso personalizado