Esta página foi traduzida pela API Cloud Translation.

Automatizar a transferência de dados do Cloud Storage para um volume de ML do Hyperdisk usando o GKE Volume Populator

Autopilot Standard

Este guia descreve como pré-carregar grandes quantidades de dados de um bucket do Cloud Storage para um volume do Hyperdisk ML do Google Kubernetes Engine (GKE) durante o provisionamento dinâmico usando o GKE Volume Populator. Para mais informações, consulte Sobre o GKE Volume Populator.

Este guia é destinado a especialistas em armazenamento que criam e alocam armazenamento, gerenciam a segurança e o acesso aos dados. Para saber mais sobre papéis comuns e tarefas de exemplo que mencionamos no conteúdo do Google Cloud , consulte Funções e tarefas comuns do usuário do GKE.

Gerenciamento de pool de nós para o GKE Volume Populator com Hyperdisk ML

O dimensionamento, o provisionamento e o escalonamento eficientes do pool de nós são cruciais para executar com sucesso os jobs de transferência de dados criados pelo GKE Volume Populator para preencher os volumes de ML do Hyperdisk. Você usa uma classe de computação para definir os requisitos do nó, como tipo e tamanho da máquina, para esses jobs de transferência de dados específicos. Uma classe de computação permite controlar o custo e o desempenho do processo de transferência de dados. Para mais informações, consulte Benefícios das classes de computação personalizadas.

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

Objetivos

Neste guia, você vai realizar as seguintes tarefas:

Configure o ambiente do cluster do GKE para oferecer suporte a transferências de dados usando o GKE Volume Populator, incluindo criação de cluster, definição de classe de computação e configuração de permissões.
Crie um GCPDataSource recurso personalizado para especificar o bucket de origem do Cloud Storage.
Defina um StorageClass para o Hyperdisk ML.
Crie um PersistentVolumeClaim que faça referência ao GCPDataSource para acionar o preenchimento de dados em um volume de ML do Hyperdisk.
Verifique a transferência de dados.
Consuma o volume preenchido em um pod.
Limpe os recursos.

Antes de começar

Verifique se você realizou as seguintes tarefas:

Ative as APIs GKE e Cloud Storage.

Ative as APIs
Verifique se o faturamento está ativado para seu Google Cloud projeto.
Faça o download e instale a ferramenta de linha de comando da CLI do Google Cloud ou use o Cloud Shell para executar comandos gcloud CLI e kubectl. O Cloud Shell é um ambiente shell para gerenciar recursos hospedados no Google Cloud. Ele vem pré-instalado com as ferramentas de linha de comando gcloud e kubectl.
Defina uma região e uma zona padrão.
Crie ou use um bucket do Cloud Storage. Neste guia, pressupomos que você já tenha um bucket do Cloud Storage preenchido com os dados de treinamento do modelo.
Ative o driver CSI do Persistent Disk do Compute Engine em clusters padrão que possam ter o driver desativado explicitamente. Em novos clusters do Autopilot e Standard, o GKE ativa o driver por padrão. O armazenamento de hiperdisco ML de destino que você criar precisa ser gerenciado pelo driver CSI de disco permanente do Compute Engine.
Ative a federação de identidade da carga de trabalho do GKE no cluster. Isso permite que a conta de serviço do Kubernetes usada pelo GKE Volume Populator acesse o bucket de origem do Cloud Storage. Para mais informações, consulte Configurar as permissões necessárias.

Requisitos

Para transferir dados usando o GKE Volume Populator, atenda aos seguintes requisitos:

Seu cluster do GKE precisa estar executando a versão 1.33.2-gke.4780000 ou mais recente.
O recurso personalizado GCPDataSource precisa estar no mesmo namespace que a carga de trabalho do GKE. Não é possível usar fontes de dados que abrangem namespaces diferentes.
Selecione uma VM compatível ao criar sua classe de computação. Confirme se o projeto tem cota suficiente para o tipo de máquina selecionado.
O nome da classe de computação gcs-to-hdml-compute-class é predefinido para o job de transferência e precisa ser especificado exatamente ao criar a classe.

Custos

Embora não haja custo direto para usar o GKE Volume Populator, o armazenamento e as transferências de dados geram cobranças de faturamento. Os custos indiretos associados incluem:

Instâncias do Compute Engine usadas pelo GKE: o custo dos nós usados para executar os jobs de transferência de dados. As implicações de custo e gerenciamento de nós variam de acordo com os tipos de cluster. Para mais informações, consulte os respectivos tipos de cluster em Criar um cluster do GKE.
Tamanho do nó do job de transferência: para um desempenho ideal da transferência, um job de transferência aumenta verticalmente um nó com 24 vCPUs por padrão. Isso se aplica a todos os tipos de cluster. Se quiser ajustar o tamanho e o tipo do nó para otimizações específicas de custo ou desempenho, faça isso ao criar sua classe de computação.
Armazenamento usado no seu bucket do Cloud Storage: para mais informações, consulte Preços do Cloud Storage.
Custos de volume do Hyperdisk ML: incluem a capacidade de armazenamento e o desempenho (IOPS/capacidade de processamento) dos volumes do Hyperdisk ML criados. Para mais informações, consulte Preços do Hyperdisk.

Preparar o ambiente

Nesta seção, você cria a infraestrutura do cluster do GKE com o hardware adequado e configura as permissões necessárias para acessar seus dados no Cloud Storage.

Antes de criar um cluster para usar o GKE Volume Populator com o Hyperdisk ML, entenda como uma classe de computação é aplicada a diferentes tipos de clusters e quem é responsável pelo gerenciamento de nós: o GKE ou você.

Como as classes de computação funcionam 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 serem usados nos jobs de transferência de dados. A tabela a seguir descreve o comportamento da sua classe de computação dependendo da configuração do cluster:

Consideração	GKE Autopilot e GKE Standard com provisionamento automático de nós	GKE Standard sem provisionamento automático de nós
Configuração da classe de computação	`nodePoolAutoCreation` ativado	O recurso `nodePoolAutoCreation` foi desativado
Gerenciamento de nós	O GKE cria e gerencia nós automaticamente.	Você cria e gerencia nós manualmente.
Escalonamento de nós	Automático	Manual
Rotulagem de nós	Não relevante	Você precisa rotular os nós com `cloud.google.com/compute-class=gcs-to-hdml-compute-class`.
Mais informações	Provisionamento automático de nós e classes de computação	Configurar pools de nós criados manualmente

O GKE inicia o job de transferência de dados depois de provisionar o PersistentVolume para o PersistentVolumeClaim. Para preencher o volume de ML do Hyperdisk, esse PersistentVolumeClaim precisa fazer referência ao GCPDataSource, que define os dados de origem no Cloud Storage.

Criar o cluster do GKE

É possível implantar o pipeline de transferência de dados usando um cluster Standard ou Autopilot com a versão 1.33.2-gke.4780000 ou mais recente do GKE. Cada tipo de cluster tem vantagens específicas e modelos de preços diferentes.

Escolha o Autopilot para facilitar o gerenciamento de clusters, a eficiência de custos e o dimensionamento automático.
Escolha Standard com provisionamento automático de nós ativado se precisar de escalonamento automático com mais controle sobre o provisionamento de nós.
Escolha o Standard sem o provisionamento automático de nós ativado se você precisar de controle máximo e se sentir à vontade para gerenciar todos os aspectos do provisionamento, escalonamento e manutenção de nós.

Piloto automático

Nos clusters do GKE Autopilot, o GKE processa automaticamente a criação e exclusão dos nós necessários para os jobs de transferência de dados. Quando o job de transferência é concluído, os recursos do nó são reduzidos automaticamente. Não é necessário excluir manualmente os pods de transferência ou os nós em que eles foram executados.

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

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

Substitua:

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

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

Em clusters padrão do GKE com o provisionamento automático de nós ativado, o GKE processa automaticamente a criação e exclusão dos nós necessários para os jobs de transferência de dados. Quando o job de transferência é concluído, os recursos do nó são reduzidos automaticamente. Não é necessário excluir manualmente os pods de transferência ou os nós em que eles foram executados.

Para criar um cluster padrão com o provisionamento 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:

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

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

Para usar o GKE Volume Populator em um cluster Standard em que o provisionamento automático de nós não está ativado, use um pool de nós atual ou crie um pool de nós de transferência dedicado. Os nós precisam ter capacidade para executar os jobs de transferência e rótulos correspondentes ao compute-class.

Especifique a classe de computação gcs-to-hdml-compute-class como um rótulo de nó ao criar o cluster e o pool de nós. O nome da classe de computação, gcs-to-hdml-compute-class, é predefinido para o job de transferência e precisa ser especificado exatamente.

Para criar um cluster padrão sem provisionamento automático de nós e um novo pool 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:

CLUSTER_NAME: o nome do cluster que você está criando sem o provisionamento automático de nós ativado.
CLUSTER_VERSION: a versão do GKE para o cluster. Use 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 projeto Google Cloud .
NODE_POOL_NAME: o nome do pool de nós que você está criando no novo cluster. Esse pool de nós é usado pelo GKE Volume Populator para implantar os jobs temporários de transferência de dados.

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

Criar sua classe de computação

Para criar uma classe de computação que especifique e priorize os tipos de VMs que podem ser usadas como nós no cluster, siga estas etapas:

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

Para clusters do Autopilot e clusters padrão com o provisionamento automático de nós ativado, defina a classe de computação com a seção nodePoolAutoCreation da seguinte maneira. Quando o provisionamento automático de nós está ativado, o GKE cria automaticamente novos pools de nós com o rótulo da 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 provisionamento automático de nós

Para clusters padrão sem o provisionamento automático de nós ativado, defina a classe de computação sem a seção nodePoolAutoCreation da seguinte maneira. Verifique se você já criou um pool de nós com o rótulo da 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
Você pode especificar qualquer machineFamily compatível para atender às suas necessidades de transferência de dados. Para mais informações sobre como selecionar um tipo de máquina adequado, consulte Suporte a séries de máquinas para o Hyperdisk ML.
Para criar a classe de computação, aplique o manifesto:
```
kubectl apply -f computeclass.yaml
```

Configurar as permissões necessárias

Para transferir dados de um bucket do Cloud Storage, configure as permissões necessárias para a Federação de Identidade da Carga de Trabalho para GKE. Com as permissões adequadas, o job de transferência criado pelo GKE Volume Populator pode acessar seu bucket do Cloud Storage. Este guia pressupõe que você já tem um bucket do Cloud Storage preenchido com os dados de treinamento do modelo que quer transferir.

Crie um namespace do Kubernetes:
```
kubectl create namespace NAMESPACE
```
Substitua NAMESPACE pelo namespace em que você quer executar as cargas de trabalho.

Pule esta etapa se você estiver usando um namespace.

Observação: use o mesmo namespace para criar todos os recursos neste guia.
Crie uma conta de serviço do Kubernetes:
```
kubectl create serviceaccount KSA_NAME \
    --namespace=NAMESPACE
```
Substitua:
- KSA_NAME: o nome da conta de serviço do Kubernetes que você vai especificar no recurso GCPDataSource. O job de transferência criado pelo GKE Volume Populator usa essa conta de serviço para autenticar APIs Google Cloud .
- NAMESPACE: o namespace do Kubernetes que você criou na etapa anterior.
Cuidado: reutilizar essa conta de serviço do Kubernetes em outras cargas de trabalho no mesmo namespace permite que o pod acesse o bucket do Cloud Storage que você está usando neste guia. Não recomendamos reutilizar essa conta de serviço para outras cargas de trabalho no namespace.
Conceda à sua conta de serviço do IAM o papel adequado para acessar seu bucket 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:
- GCS_BUCKET: seu nome do bucket do Cloud Storage
- PROJECT_NUMBER: o identificador numérico do seu Google Cloud projeto em que você criou o cluster. Para encontrar o número do projeto, consulte Identificar projetos.
- PROJECT_ID: o ID do projeto Google Cloud .
- NAMESPACE: o namespace que você criou anteriormente e onde as cargas de trabalho serão executadas.
- KSA_NAME: o nome da conta de serviço do Kubernetes especificada no recurso GCPDataSource. O job de transferência criado pelo GKE Volume Populator usa essa conta de serviço para autenticar APIs Google Cloud .
- ROLE: o papel do IAM que você quer conceder à sua conta de serviço. Para os fins deste guia, conceda o papel roles/storage.objectViewer para permitir a leitura do bucket.
Os PROJECT_NUMBER, PROJECT_ID, NAMESPACE e KSA_NAME são usados para construir o identificador principal da federação de identidade da carga de trabalho para o GKE do seu projeto.

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

Siga estas etapas para configurar a infraestrutura e a configuração do GKE necessárias para criar um volume de ML do Hyperdisk e acionar e gerenciar o processo automatizado de transferência de dados usando o GKE Volume Populator:

Crie um GCPDataSource recurso personalizado para definir a origem dos dados.
Crie uma StorageClass para definir o tipo de armazenamento permanente (um volume do Hyperdisk ML) a ser usado.
Crie um PersistentVolumeClaim para ativar o provisionamento dinâmico do armazenamento e o acesso ao volume do Hyperdisk ML recém-provisionado.
(Opcional) Confira o progresso da transferência de dados.
Crie e implante um pod que consuma o volume de ML do Hyperdisk.

Criar um recurso personalizado `GCPDataSource`

Crie um recurso personalizado GCPDataSource no GKE para especificar o local do bucket de origem do Cloud Storage e a conta de serviço com as permissões necessárias para acessar esse bucket. Essa definição de recurso personalizada (CRD) é específica do GKE Volume Populator.

Salve o seguinte manifesto gcpdatasource.yaml como :
```
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 GCPDataSource que contém uma referência ao bucket do Cloud Storage. Para mais informações, consulte a referência de CRD GCPDataSource.
- NAMESPACE: o mesmo namespace em que suas cargas de trabalho são executadas. O recurso personalizado GCPDataSource é criado nesse namespace.
- KSA_NAME: o nome da conta de serviço do Kubernetes especificada no recurso GCPDataSource. O job de transferência criado pelo GKE Volume Populator usa essa conta de serviço para autenticar APIs Google Cloud . O valor cloudStorage.serviceAccountName é a conta de serviço do Kubernetes que você configurou para a federação de identidade da carga de trabalho para o GKE na seção Configurar as permissões necessárias.
- GCS_BUCKET: seu nome do bucket do Cloud Storage O campo uri especifica os dados de origem.
  - Para copiar o bucket inteiro, use gs://GCS_BUCKET/.
  - Para copiar dados de uma pasta específica no bucket, use o formato gs://GCS_BUCKET/PATH_INSIDE_BUCKET/. Por exemplo, para copiar dados da pasta gemma/v1.0/weights/ dentro do bucket my-project-llm-models, o URI seria gs://my-project-llm-models/gemma/v1.0/weights/. Verifique se o caminho termina com uma barra para indicar uma pasta.
Para criar o recurso GCPDataSource, aplique o manifesto:
```
kubectl apply -f gcpdatasource.yaml
```

Criar um StorageClass do Hyperdisk ML

Crie uma StorageClass que use o provisionador pd.csi.storage.gke.io para provisionar um volume de ML do Hyperdisk na zona escolhida. Se quiser disponibilizar cópias dos dados em mais de uma zona, crie uma StorageClass multizona. Confira um exemplo de StorageClass de várias zonas.

Salve o seguinte manifesto hdml-class.yaml como :
```
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 em que você quer criar o volume de ML do Hyperdisk:
- Para um cluster do GKE Standard sem provisionamento automático de nós, o valor de ZONE precisa ser o local em que você criou os nós.
- Para clusters do GKE Autopilot ou Standard com provisionamento automático de nós, o valor de ZONE precisa ser o local em que o cluster pode ser escalonado verticalmente e criar novos nós, se necessário.
(Opcional) Para listar os locais dos nós do cluster, execute o seguinte comando:
```
gcloud container clusters describe CLUSTER_NAME --location=LOCATION --format="value(locations)"
```
Substitua:
- CLUSTER_NAME: o nome do cluster.
- LOCATION: a zona ou região de computação do cluster. Por exemplo, us-central1-a ou us-central1.
Para criar a StorageClass, aplique o manifesto :
```
kubectl apply -f hdml-class.yaml
```

Criar um PersistentVolumeClaim para acessar o volume

O manifesto a seguir mostra um exemplo de como criar um PersistentVolumeClaim no modo de acesso ReadOnlyMany que faz referência ao StorageClass criado anteriormente.

Salve 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 em que você quer transferir seus dados.
- NAMESPACE: o namespace em que as cargas de trabalho serão executadas.
- DISK_SIZE: o tamanho do disco, em gigabytes, que será criado para preencher os dados. Para preencher os dados corretamente, verifique se o tamanho do disco solicitado é maior que o tamanho dos dados do modelo no bucket do Cloud Storage. Para estar de acordo com o intervalo aceito para os volumes do Hyperdisk ML, o valor de DISK_SIZE precisa ser maior que 4 Gi. Para mais informações, consulte Limites de tamanho do volume do Hyperdisk.
- GCP_DATA_SOURCE: o nome do CRD GCPDataSource que contém uma referência ao bucket do Cloud Storage.
É possível personalizar a transferência de dados adicionando anotações opcionais ao PVC. Essas anotações influenciam o comportamento do job de transferência subjacente que copia dados para o volume de ML do Hyperdisk.
- volume-populator.datalayer.gke.io/cpu-request: use essa anotação para especificar uma solicitação de recurso de CPU diferente para a transferência Job. Se você não especificar uma solicitação de recurso de CPU diferente, a PVC vai solicitar 24 vCPUs por padrão para otimizar o desempenho da transferência.
- volume-populator.datalayer.gke.io/transfer-path: use essa anotação para especificar o caminho de destino dentro do novo volume que vai armazenar os dados copiados do recurso GCPDataSource. Se você não especificar um caminho diferente, os dados serão copiados para o caminho raiz no volume do Hyperdisk ML.

Para criar o PVC, aplique o manifesto:

kubectl apply -f volume-populator-pvc.yaml

Observe o seguinte:

Se você definir o campo volumeBindingMode na StorageClass como immediate, a transferência de dados será acionada imediatamente após a implantação do PVC.
Se você definir o campo volumeBindingMode no StorageClass como WaitForFirstConsumer, a transferência de dados será acionada somente depois que você implantar um pod que solicite o PVC e esse pod seja programado com êxito para um nó. Embora o pod possa ser programado, os contêineres vão esperar até que a transferência de dados seja concluída e o volume esteja pronto para uso.

Para verificar o andamento da transferência de dados, consulte Ver o andamento da transferência de dados. Se você encontrar erros durante o provisionamento de recursos ou a transferência de dados, consulte Solução de problemas de transferência de dados do GKE Volume Populator.

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

Esta seção mostra como acompanhar o progresso e o sucesso das transferências de dados de um bucket do Cloud Storage para um volume de ML do Hyperdisk.

Para verificar o status do PersistentVolumeClaim, execute o comando a seguir. Você também pode executar esse comando se a operação de vinculação do PersistentVolumeClaim demorar muito para ser concluída.
```
kubectl describe pvc PVC_NAME -n NAMESPACE
```
Substitua:
- PVC_NAME: o nome da PVC que você criou na seção Criar um PersistentVolumeClaim para acessar o volume.
- NAMESPACE: o namespace usado neste guia, que você criou na seção Configurar as permissões necessárias.

Na saída, analise os eventos do PersistentVolumeClaim para monitorar o progresso da transferência de dados. O GKE registra os eventos aproximadamente uma vez por minuto. O resultado será assim:

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 levar vários minutos para começar, dependendo do tamanho dos dados. Se você não notar nenhum progresso na transferência de dados após alguns minutos, consulte Solução de problemas com a transferência de dados do GKE Volume Populator para receber ajuda.

Para transferências de dados de volume de ML do Hyperdisk de várias zonas, o job é marcado como concluído somente se os dados forem transferidos para todas as zonas especificadas na StorageClass. Se o job de transferência falhar em uma ou mais zonas, o GKE Volume Populator vai tentar transferir os dados indefinidamente enquanto o PVC existir.

Criar e implantar um pod que consuma o volume

Para criar um pod e verificar o conteúdo de uma PVC preenchida com dados:

Salve 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:

NAMESPACE: o namespace em que a PVC está localizada e onde você quer criar o pod verify-data.
PVC_NAME: o nome do PVC que você criou para preenchimento de dados na seção Criar um PersistentVolumeClaim para acessar o volume.

Crie o pod com o seguinte comando:
```
kubectl create -f verify-data.yaml
```

Para listar os arquivos, execute o seguinte comando:

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

Se o comando for bem-sucedido, você poderá encontrar os dados preenchidos no diretório /models no bucket do Cloud Storage.

Limpar

Para evitar custos desnecessários e remover recursos mal configurados ou órfãos, siga as etapas para excluir normalmente o PersistentVolumeClaim.

Excluir o PersistentVolumeClaim durante o provisionamento dinâmico

Se você precisar excluir seu PersistentVolumeClaim enquanto os dados ainda estão sendo transferidos durante o provisionamento dinâmico, siga estas etapas para uma exclusão normal. A exclusão normal pode levar algum tempo para ser concluída.

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

POD_NAME: o nome do pod que você criou na seção Criar e implantar um pod que consome o volume.
NAMESPACE: o namespace em que o PVC está localizado.
PVC_NAME: o nome do PVC que você criou na seção Criar um PersistentVolumeClaim para acessar o volume.
GCP_DATA_SOURCE: o nome do recurso personalizado GCPDataSource que você criou na seção Criar um recurso personalizado GCPDataSource.

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

Exclua a PVC criada no namespace:

kubectl delete pvc PVC_NAME -n NAMESPACE

A PVC pode estar presa 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 finalizadores:

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

Exclua o recurso GCPDataSource somente depois que a PVC for excluída. Se você excluir o recurso GCPDataSource primeiro, a exclusão do PVC vai ficar travada.
```
kubectl delete gcpdatasource GCP_DATA_SOURCE -n NAMESPACE
```
Verifique se os recursos temporários foram excluídos.

A seguir

Saiba Sobre o GKE Volume Populator.
Para ajuda com problemas de transferência de dados, consulte Solução de problemas de transferência de dados do GKE Volume Populator.
Para um exemplo avançado de carga de trabalho do Hyperdisk ML, consulte Acelerar o carregamento de dados de IA/ML com o Hyperdisk ML.

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

Gerenciamento de pool de nós para o GKE Volume Populator com Hyperdisk ML

Objetivos

Antes de começar

Requisitos

Custos

Preparar o ambiente

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

Criar o cluster do GKE

Piloto automático

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

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

Criar sua classe de computação

Com o provisionamento automático de nós

Sem provisionamento automático de nós

Configurar as permissões necessárias

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

Criar um recurso personalizado GCPDataSource

Criar um StorageClass do Hyperdisk ML

Criar um PersistentVolumeClaim para acessar o volume

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

Criar e implantar um pod que consuma o volume

Limpar

Excluir o PersistentVolumeClaim durante o provisionamento dinâmico

A seguir

Automatizar a transferência de dados do Cloud Storage para um volume de ML do Hyperdisk usando o GKE Volume Populator

Criar um recurso personalizado `GCPDataSource`