Criar um cluster do GKE otimizado para IA com o Cluster Toolkit

Neste documento, mostramos como criar um cluster do Google Kubernetes Engine (GKE) otimizado para IA que usa instâncias do Compute Engine A4X, A4, A3 Ultra, A3 Mega e A3 High (8 GPUs) para dar suporte às suas cargas de trabalho de IA e ML.

As séries de máquinas A4X, A4, A3 Ultra, A3 Mega e A3 High (8 GPUs) foram projetadas para permitir que você execute clusters de IA/ML em grande escala com recursos como posicionamento de carga de trabalho direcionado, controles avançados de manutenção de cluster e programação com reconhecimento de topologia. Para mais informações, consulte Visão geral do gerenciamento de clusters.

O GKE fornece uma única plataforma para executar um conjunto diversificado de cargas de trabalho para as necessidades da sua organização. Essas cargas de trabalho incluem pré-treinamento distribuído de alto desempenho, ajuste de modelos, inferência de modelos, exibição de aplicativos e serviços de suporte. O GKE reduz a carga operacional de gerenciar várias plataformas.

Escolher como criar um cluster do GKE otimizado para IA

As opções a seguir para a criação de clusters oferecem diferentes graus de facilidade e flexibilidade na configuração de clusters e na programação de cargas de trabalho:

Antes de começar

Antes de começar, verifique se você realizou as tarefas a seguir:

  • Ative a API Google Kubernetes Engine.
    • Ativar a API Google Kubernetes Engine
  • Para usar a Google Cloud CLI nesta tarefa, instale e inicialize a CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando o comando gcloud components update. Talvez as versões anteriores da CLI gcloud não sejam compatíveis com a execução dos comandos neste documento.
  • Verifique se você tem as permissões necessárias para criar e gerenciar o cluster do GKE e as contas de serviço associadas:
    • Administrador do Kubernetes Engine (roles/container.admin)
    • Administrador do Compute (roles/compute.admin)
    • Administrador do Storage (roles/storage.admin)
    • Administrador de IAM do projeto (roles/resourcemanager.projectIamAdmin)
    • Administrador da conta de serviço (roles/iam.serviceAccountAdmin)
    • Usuário da conta de serviço (roles/iam.serviceAccountUser)
    • Consumidor do Service Usage (roles/serviceusage.serviceUsageConsumer)
    • Administrador de papel (roles/iam.roleAdmin)
    • Gerenciador de versões de secret do Secret Manager (roles/secretmanager.secretVersionManager)
    • Para consumir uma reserva de projeto único: Administrador da instância do Compute (v1) (roles/compute.instanceAdmin.v1) no projeto
    • Para consumir uma reserva compartilhada: Administrador da instância do Compute (v1) (roles/compute.instanceAdmin.v1) no projeto proprietário e em qualquer projeto consumidor em que você queira consumir a reserva

Escolher uma opção de consumo e obter capacidade

Para obter capacidade, siga estas etapas:

  1. Escolha uma opção de consumo: faça sua escolha com base em como você quer receber e usar os recursos de GPU. Para saber mais, consulte Escolher uma opção de consumo.

    Para o GKE, considere as seguintes informações adicionais ao escolher uma opção de consumo:

  2. Obter capacidade: o processo para obter capacidade é diferente para cada opção de consumo. Para saber mais sobre o processo da opção de consumo escolhida, consulte Visão geral da capacidade.

Requisitos

Os requisitos a seguir se aplicam a um cluster do GKE otimizado para IA:

  • Para o A4X Max, use uma das seguintes versões:

    • Para a versão 1.35 ou mais recente, use o GKE versão 1.35.0-gke.2745000 ou mais recente.
    • Para a versão 1.34, use o GKE 1.34.3-gke.1318000 ou mais recente.

    Essas versões ajudam a garantir que o A4X Max use o seguinte:

    • R580.95.05, a versão mínima do driver de GPU para o A4X Max, que é ativada por padrão.
    • Gerenciamento de memória baseado em driver coerente (CDMM, na sigla em inglês), que é ativado por padrão. A NVIDIA recomenda que os clusters do Kubernetes ativem esse modo para resolver o excesso de relatórios de memória. O CDMM permite que a memória da GPU seja gerenciada pelo driver, em vez do sistema operacional (SO). Essa abordagem ajuda a evitar que o SO coloque a memória da GPU on-line e a expõe como um nó de acesso não uniforme à memória (NUMA) para o SO. As GPUs de várias instâncias não são compatíveis quando o CDMM está ativado. Para mais informações sobre o CDMM, consulte Suporte de hardware e software.
    • GPUDirect RDMA e MNNVL, que são recomendados para permitir que os pools de nós do A4X Max usem os recursos de rede do A4X Max.

  • Para o A4X, use uma das seguintes versões:

    • Para a versão 1.33 ou mais recente, use a versão 1.33.4-gke.1036000 ou mais recente do GKE.
    • Para a versão 1.32, use o GKE 1.32.8-gke.1108000 ou mais recente.

    Essas versões ajudam a garantir que o A4X use o seguinte:

    • R580, a versão mínima do driver de GPU para A4X, que é ativada por padrão.
    • Gerenciamento de memória baseado em driver coerente (CDMM, na sigla em inglês), que é ativado por padrão. A NVIDIA recomenda que os clusters do Kubernetes ativem esse modo para resolver o excesso de relatórios de memória. O CDMM permite que a memória da GPU seja gerenciada pelo driver, em vez do sistema operacional (SO). Essa abordagem ajuda a evitar que o SO coloque a memória da GPU on-line e a expõe como um nó de acesso não uniforme à memória (NUMA) para o SO. As GPUs de várias instâncias não são compatíveis quando o CDMM está ativado. Para mais informações sobre o CDMM, consulte Suporte de hardware e software.
    • GPUDirect RDMA e MNNVL, que são recomendados para permitir que os pools de nós A4X usem os recursos de rede do A4X.

  • Use a versão mínima do driver da GPU, dependendo do tipo de máquina:

    • A4X Max: as GPUs GB300 em instâncias bare metal A4X Max exigem uma versão mínima do driver de GPU R580.95.05. Consulte os requisitos de versão mencionados anteriormente.
    • A4X: as GPUs GB200 em instâncias A4X exigem, no mínimo, a versão R580 do driver de GPU. Consulte os requisitos de versão mencionados anteriormente.
    • A4: as GPUs B200 em instâncias A4 exigem, no mínimo, a versão R570 do driver de GPU. Por padrão, o GKE instala automaticamente essa versão do driver em todos os nós A4 que executam a versão mínima necessária para A4, 1.32.1-gke.1729000 ou mais recente.
    • A3 Ultra: as GPUs H200 nas instâncias A3 Ultra exigem, no mínimo, a versão R550 do driver de GPU, que está disponível no GKE 1.31 como a versão do driver latest. Para o A3 Ultra, é necessário definir gpu-driver-version=latest com o GKE 1.31. No GKE versão 1.31.5-gke.1169000 ou mais recente, o GKE instala automaticamente as versões do driver de GPU R550 nos nós A3 Ultra.
    • A3 Mega e A3 High: as GPUs H100 nas instâncias A3 High e A3 Mega são compatíveis com a versão padrão do driver de GPU em todas as versões do GKE. Também é possível definir gpu-driver-version=latest para acessar drivers de produção mais recentes disponíveis nas versões compatíveis do GKE.

  • Para pools de nós A3 Ultra, defina o tipo de disco como hyperdisk-balanced.

  • Para usar o GPUDirect RDMA, use as seguintes versões mínimas, dependendo do tipo de máquina:

    • A4X Max: consulte os requisitos de versão mencionados anteriormente.
    • A4X: consulte os requisitos de versão mencionados anteriormente.
    • A4: use 1.32.2-gke.1475000 ou mais recente.
    • A3 Ultra: use a versão 1.31.4-gke.1183000 ou mais recente.

  • Para usar o GPUDirect-TCPXO (para A3 Mega) e o GPUDirect-TCPX (para A3 High), use as seguintes versões do GKE:

    • A3 High: use qualquer versão disponível do GKE anterior à 1.34.
    • A3 Mega: use qualquer versão disponível do GKE.

  • Para usar o GPUDirect RDMA, os nós do GKE precisam usar uma imagem de nó do Container-Optimized OS. As imagens de nós do Ubuntu e do Windows não são compatíveis.

  • Use o modelo de provisionamento vinculado à reserva para criar clusters com A4X Max e A4X. Outros modelos de provisionamento não são compatíveis.

Criar um cluster com o Cluster Toolkit

Use as instruções a seguir para criar um cluster usando o Cluster Toolkit. Esta seção orienta você no processo de criação de clusters, garantindo que seu projeto siga as práticas recomendadas e atenda aos requisitos de um cluster do GKE otimizado para IA. Nesta seção, também mostramos como usar o Terraform para provisionar e gerenciar a infraestrutura da implantação.

A4X Max

  1. Inicie o Cloud Shell. É possível usar um ambiente diferente. No entanto, recomendamos o Cloud Shell porque as dependências já estão pré-instaladas para o Cluster Toolkit. Se você não quiser usar o Cloud Shell, siga as instruções para instalar dependências e preparar um ambiente diferente.

  2. Instalar o Cluster Toolkit.

  3. Crie um bucket do Cloud Storage com o controle de versões ativado para armazenar o estado da implantação do Terraform:

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    Substitua as seguintes variáveis:

    • BUCKET_NAME: o nome do novo bucket do Cloud Storage, que precisa atender aos requisitos de nomenclatura de bucket.
    • PROJECT_ID: o ID do projeto Google Cloud .
    • COMPUTE_REGION_TERRAFORM_STATE: a região de computação em que você quer armazenar o estado da implantação do Terraform.

  4. No blueprint examples/gke-a4x-max-bm/gke-a4x-max-bm-deployment.yaml do repositório do GitHub, preencha as seguintes configurações nas seções terraform_backend_defaults e vars para corresponder aos valores específicos da implantação:

    • BUCKET: o nome do bucket do Cloud Storage que você criou na etapa anterior.
    • PROJECT_ID: o ID do projeto Google Cloud .
    • DEPLOYMENT_NAME: um nome exclusivo para a implantação, que precisa ter entre 6 e 30 caracteres. Se o nome da implantação não for exclusivo em um projeto, a criação do cluster falhará. O valor padrão é gke-a4x-max-bm.
    • REGION: a região de computação do cluster.
    • ZONE: a zona do Compute para o pool de nós de máquinas A4X Max. Essa zona precisa corresponder à zona em que as máquinas estão disponíveis na sua reserva.
    • STATIC_NODE_COUNT: o número de nós A4X Max no pool de nós do cluster, que precisa ser de 18 nós ou menos. Recomendamos que você use 18 nós para receber a topologia de GPU de 1x72 em um sub-bloco usando um domínio NVLink.
    • AUTHORIZED_CIDR: o intervalo de endereços IP que você quer que se conecte ao cluster. Esse bloco CIDR precisa incluir o endereço IP da máquina que chama o Terraform. Para mais informações, consulte Como as redes autorizadas funcionam.

    • Para o campo reservation, use uma das seguintes opções, dependendo se você quer segmentar blocos específicos em uma reserva ao provisionar o pool de nós:

    • Para colocar o pool de nós em qualquer lugar da reserva, forneça o nome da reserva (RESERVATION_NAME).

    • Para segmentar um bloco específico na reserva, use os nomes da reserva e do bloco no seguinte formato:

      RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      Se você não souber quais blocos estão disponíveis na sua reserva, consulte Ver a topologia de uma reserva.

    • RESERVATION_PROJECT_ID: o ID do projeto do Google Cloud que tem a reserva. Sua reserva pode estar em um projeto diferente de PROJECT_ID.

    • NUM_NODE_POOLS: o número de pools de nós a serem ativados no cluster. Se você quiser um cluster com mais de 18 nós, especifique vários pools de nós. O valor padrão é 1.

    Para modificar as configurações avançadas, edite o arquivo examples/gke-a4x-max-bm/gke-a4x-max-bm.yaml.

  5. Opcional: configure o Google Cloud Managed Lustre para armazenamento compartilhado de alto desempenho. O blueprint do GKE do A4X Max ativa o driver CSI do Managed Lustre por padrão. Para provisionar uma instância do Managed Lustre e um volume permanente com o cluster, faça o seguinte:

    1. Abra o arquivo examples/gke-a4x-max-bm/gke-a4x-max-bm.yaml .
    2. Na seção vars, remova a marca de comentário das variáveis lustre_instance_id, lustre_size_gib e per_unit_storage_throughput.
    3. Na seção # --- MANAGED LUSTRE ADDITIONS ---, remova a marca de comentário dos módulos private_service_access, lustre_firewall_rule, managed-lustre e lustre-pv.

  6. Gere o Application Default Credentials (ADC) para fornecer acesso ao Terraform. Se você estiver usando o Cloud Shell, use o comando gcloud auth application-default login:

    gcloud auth application-default login

  7. Use o comando gcluster deploy para implantar o blueprint e provisionar a infraestrutura do GKE usando os tipos de máquina A4X Max:

    cd ~/cluster-toolkit
./gcluster deploy -d \
    examples/gke-a4x-max-bm/gke-a4x-max-bm-deployment.yaml \
    examples/gke-a4x-max-bm/gke-a4x-max-bm.yaml

  8. Quando solicitado, selecione (A)plicar para implantar o blueprint.

    • O blueprint cria redes VPC, uma rede VPC de GPU RDMA, contas de serviço, um cluster e um pool de nós.
    • Para oferecer suporte ao modelo de job fio-bench-job-template no blueprint, são criados buckets doGoogle Cloud , armazenamento de rede e recursos de volume persistente.

A4X

  1. Inicie o Cloud Shell. É possível usar um ambiente diferente. No entanto, recomendamos o Cloud Shell porque as dependências já estão pré-instaladas para o Cluster Toolkit. Se você não quiser usar o Cloud Shell, siga as instruções para instalar dependências e preparar um ambiente diferente.

  2. Instalar o Cluster Toolkit.

  3. Crie um bucket do Cloud Storage com o controle de versões ativado para armazenar o estado da implantação do Terraform:

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    Substitua as seguintes variáveis:

    • BUCKET_NAME: o nome do novo bucket do Cloud Storage, que precisa atender aos requisitos de nomenclatura de bucket.
    • PROJECT_ID: o ID do projeto Google Cloud .
    • COMPUTE_REGION_TERRAFORM_STATE: a região de computação em que você quer armazenar o estado da implantação do Terraform.

  4. No blueprint examples/gke-a4x/gke-a4x-deployment.yaml do repositório do GitHub, preencha as seguintes configurações nas seções terraform_backend_defaults e vars para corresponder aos valores específicos da implantação:

    • BUCKET: o nome do bucket do Cloud Storage que você criou na etapa anterior.
    • PROJECT_ID: o ID do projeto Google Cloud .
    • DEPLOYMENT_NAME: um nome exclusivo para a implantação, que precisa ter entre 6 e 30 caracteres. Se o nome da implantação não for exclusivo em um projeto, a criação do cluster falhará. O valor padrão é gke-a4x.
    • REGION: a região de computação do cluster.
    • ZONE: a zona do Compute para o pool de nós de máquinas A4X. Essa zona precisa corresponder à zona em que as máquinas estão disponíveis na sua reserva.
    • STATIC_NODE_COUNT: o número de nós A4X no pool de nós do cluster, que precisa ser de 18 nós ou menos. Recomendamos que você use 18 nós para conseguir a topologia de GPU de 1x72 em um sub-bloco usando um domínio NVLink.
    • AUTHORIZED_CIDR: o intervalo de endereços IP que você quer que se conecte ao cluster. Esse bloco CIDR precisa incluir o endereço IP da máquina que chama o Terraform. Para mais informações, consulte Como as redes autorizadas funcionam.

    • Para o campo reservation, use uma das seguintes opções, dependendo se você quer segmentar blocos específicos em uma reserva ao provisionar o pool de nós:

    • Para colocar o pool de nós em qualquer lugar da reserva, forneça o nome da reserva (RESERVATION_NAME).

    • Para segmentar um bloco específico na reserva, use os nomes da reserva e do bloco no seguinte formato:

      RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      Se você não souber quais blocos estão disponíveis na sua reserva, consulte Ver a topologia de uma reserva.

    • RESERVATION_PROJECT_ID: o ID do projeto do Google Cloud que tem a reserva. Sua reserva pode estar em um projeto diferente de PROJECT_ID.

    • NUM_NODE_POOLS: o número de pools de nós a serem ativados no cluster. Se você quiser um cluster com mais de 18 nós, especifique vários pools de nós. O valor padrão é 1.

    Para modificar as configurações avançadas, edite o arquivo examples/gke-a4x/gke-a4x.yaml.

  5. Opcional: configure o Managed Lustre para armazenamento compartilhado de alto desempenho. O blueprint do GKE do A4X ativa o driver CSI do Managed Lustre por padrão. Para provisionar uma instância do Managed Lustre e um volume permanente com o cluster, faça o seguinte:

    1. Abra o arquivo examples/gke-a4x/gke-a4x.yaml .
    2. Na seção vars, remova a marca de comentário das variáveis lustre_instance_id, lustre_size_gib e per_unit_storage_throughput.
    3. Na seção # --- MANAGED LUSTRE ADDITIONS ---, remova a marca de comentário dos módulos private_service_access, lustre_firewall_rule, managed-lustre e lustre-pv.

  6. Gere o Application Default Credentials (ADC) para fornecer acesso ao Terraform. Se você estiver usando o Cloud Shell, use o comando gcloud auth application-default login:

    gcloud auth application-default login

  7. Use o comando gcluster deploy para implantar o blueprint e provisionar a infraestrutura do GKE usando tipos de máquina A4X:

    cd ~/cluster-toolkit
./gcluster deploy -d \
    examples/gke-a4x/gke-a4x-deployment.yaml \
    examples/gke-a4x/gke-a4x.yaml

  8. Quando solicitado, selecione (A)plicar para implantar o blueprint.

    • O blueprint cria redes VPC, uma rede VPC de GPU RDMA, contas de serviço, um cluster e um pool de nós.
    • Para oferecer suporte ao modelo de job fio-bench-job-template no blueprint, são criados buckets doGoogle Cloud , armazenamento de rede e recursos de volume persistente.

A4

  1. Inicie o Cloud Shell. Embora seja possível usar um ambiente diferente, recomendamos o uso do Cloud Shell, porque as dependências já estão pré-instaladas para o Cluster Toolkit. Se você não quiser usar o Cloud Shell, siga as instruções para instalar dependências e preparar um ambiente diferente.

  2. Instalar o Cluster Toolkit.

  3. Crie um bucket do Cloud Storage com o controle de versões ativado para armazenar o estado da implantação do Terraform:

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    Substitua as seguintes variáveis:

    • BUCKET_NAME: o nome do novo bucket do Cloud Storage, que precisa atender aos requisitos de nomenclatura de bucket.
    • PROJECT_ID: o ID do projeto Google Cloud .
    • COMPUTE_REGION_TERRAFORM_STATE: a região de computação em que você quer armazenar o estado da implantação do Terraform.

  4. Escolha uma opção de consumo para sua implantação do GKE:

    Por padrão, o arquivo de implantação é configurado para consumir reservas específicas. Para usar um modelo de consumo alternativo (como VMs spot ou modo de provisionamento de início flexível), atualize o arquivo YAML de implantação. Para mais informações, consulte Opções de consumo do GKE.

  5. No blueprint examples/gke-a4/gke-a4-deployment.yaml do repositório do GitHub, preencha as seguintes configurações nas seções terraform_backend_defaults e vars para corresponder aos valores específicos da implantação:

    • BUCKET: o nome do bucket do Cloud Storage que você criou na etapa anterior.
    • PROJECT_ID: o ID do projeto Google Cloud .
    • DEPLOYMENT_NAME: um nome exclusivo para a implantação, que precisa ter entre 6 e 30 caracteres. Se o nome da implantação não for exclusivo em um projeto, a criação do cluster falhará. O valor padrão é gke-a4.
    • REGION: a região de computação do cluster.
    • ZONE: a zona do Compute para o pool de nós de máquinas A4. Essa zona precisa corresponder à zona em que as máquinas estão disponíveis na sua reserva.
    • AUTHORIZED_CIDR: o intervalo de endereços IP que você quer que se conecte ao cluster. Esse bloco CIDR precisa incluir o endereço IP da máquina que chama o Terraform. Para mais informações, consulte Como as redes autorizadas funcionam.
    • Na seção de reserva específica, defina as seguintes configurações:

    • No bloco reservation_affinity, na lista specific_reservations, especifique o campo de reserva name:

      • Para colocar o pool de nós em qualquer lugar da reserva, forneça o nome da reserva (RESERVATION_NAME).
      • Para segmentar um bloco específico na reserva, use os nomes da reserva e do bloco no seguinte formato:
      RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      Se você não souber quais blocos estão disponíveis na sua reserva, consulte Ver uma topologia de reserva.

      Para modificar as configurações avançadas, edite examples/gke-a4/gke-a4.yaml.

    Início flexível

    1. No blueprint examples/gke-a4/gke-a4-deployment.yaml do repositório do GitHub, preencha as seguintes configurações nas seções terraform_backend_defaults e vars para corresponder aos valores específicos da implantação:

      • BUCKET: o nome do bucket do Cloud Storage que você criou na etapa anterior.
      • PROJECT_ID: o ID do projeto Google Cloud .
      • DEPLOYMENT_NAME: um nome exclusivo para a implantação, que precisa ter entre 6 e 30 caracteres. Se o nome da implantação não for exclusivo em um projeto, a criação do cluster vai falhar. O valor padrão é gke-a4.
      • REGION: a região de computação do cluster.
      • ZONE: a zona do Compute para o pool de nós de máquinas A4.
      • AUTHORIZED_CIDR: o intervalo de endereços IP que você quer permitir que se conecte ao cluster. Esse bloco CIDR precisa incluir o endereço IP da máquina que você quer usar para chamar o Terraform. Para mais informações, consulte Como funcionam as redes autorizadas.
      • Remova o campo reservation e substitua-o por enable_flex_start: true. Adicione na próxima linha enable_queued_provisioning: true se você também quiser usar o provisionamento em fila. Para mais informações, consulte Usar pools de nós com início flexível com provisionamento em fila.
      • Remova static_node_count.

    2. No blueprint examples/gke-a4/gke-a4.yaml do repositório do GitHub, faça as seguintes alterações:

      • No bloco vars, remova static_node_count.
      • No bloco vars, verifique se o número version_prefix é "1.32." ou mais recente. Para usar o início flexível no GKE, o cluster precisa usar a versão 1.32.2-gke.1652000 ou mais recente.
      • No bloco vars, substitua todo o bloco reservation (incluindo a própria linha reservation) por enable_flex_start: true e, opcionalmente, enable_queued_provisioning: true.
      • No bloco vars, se você não precisar de provisionamento em fila, remova a seguinte linha: kueue_configuration_path: $(ghpc_stage("./kueue-configuration.yaml.tftpl")).
      • Em id: a4-pool, remova a seguinte linha: static_node_count: $(vars.static_node_count).

      • Em id: a4-pool, remova o bloco reservation_affinity. Substitua esse bloco pelas seguintes linhas:

        • enable_flex_start: $(vars.enable_flex_start)
        • auto_repair: false
        • Para o provisionamento em fila, se você quiser ativá-lo, adicione as seguintes linhas extras:
          • enable_queued_provisioning: $(vars.enable_queued_provisioning)
          • autoscaling_total_min_nodes: 0

      • Em id: workload-manager-install, remova o seguinte bloco:

         kueue:
    install: true
    config_path: $(vars.kueue_configuration_path)
    config_template_vars:
       num_gpus: $(a3-ultragpu-pool.static_gpu_count)
       accelerator_type: $(vars.accelerator_type)

        • Para o início flexível com provisionamento em fila, faça o seguinte:

          1. Adicione gpu_nominal_quota: NOMINAL_QUOTA ao bloco vars. O valor gpu_nominal_quota é usado para definir o nominalQuota de GPUs na especificação ClusterQueue (veja a etapa de configuração de ClusterQueue a seguir). Neste exemplo, o ClusterQueue só aceita cargas de trabalho se a soma das solicitações de GPU for menor ou igual ao valor NOMINAL_QUOTA. Para mais informações sobre ClusterQueue, consulte o seguinte documento do Kueue sobre fila de cluster.

          2. Atualize o bloco kueue para o seguinte:

            kueue:
   install: true
   config_path: $(vars.kueue_configuration_path)
   config_template_vars:
      num_gpus: $(vars.gpu_nominal_quota)

          3. Substitua o conteúdo do arquivo kueue-configuration.yaml.tftpl pelo seguinte:

            apiVersion: kueue.x-k8s.io/v1beta1
kind: ResourceFlavor
metadata:
   name: "default-flavor"
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: AdmissionCheck
metadata:
   name: dws-prov
spec:
   controllerName: kueue.x-k8s.io/provisioning-request
   parameters:
      apiGroup: kueue.x-k8s.io
      kind: ProvisioningRequestConfig
      name: dws-config
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ProvisioningRequestConfig
metadata:
   name: dws-config
spec:
   provisioningClassName: queued-provisioning.gke.io
   managedResources:
   - nvidia.com/gpu
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ClusterQueue
metadata:
   name: "dws-cluster-queue"
spec:
   namespaceSelector: {}
   resourceGroups:
   - coveredResources: ["nvidia.com/gpu"]
      flavors:
      - name: "default-flavor"
      resources:
      - name: "nvidia.com/gpu"
         nominalQuota: ${num_gpus}
   admissionChecks:
   - dws-prov
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: LocalQueue
metadata:
   namespace: "default"
   name: "dws-local-queue"
spec:
   clusterQueue: "dws-cluster-queue"
---

      • Em id: job-template, substitua a variável node_count por 2.

    Spot

    1. No blueprint examples/gke-a4/gke-a4-deployment.yaml do repositório do GitHub, preencha as seguintes configurações nas seções terraform_backend_defaults e vars para corresponder aos valores específicos da implantação:

      • BUCKET: o nome do bucket do Cloud Storage que você criou na etapa anterior.
      • PROJECT_ID: o ID do projeto Google Cloud .
      • DEPLOYMENT_NAME: um nome exclusivo para a implantação, que precisa ter entre 6 e 30 caracteres. Se o nome da implantação não for exclusivo em um projeto, a criação do cluster vai falhar. O valor padrão é gke-a4.
      • REGION: a região de computação do cluster.
      • ZONE: a zona do Compute para o pool de nós de máquinas A4.
      • STATIC_NODE_COUNT: o número de nós A4 no cluster.
      • AUTHORIZED_CIDR: o intervalo de endereços IP que você quer permitir que se conecte ao cluster. Esse bloco CIDR precisa incluir o endereço IP da máquina que você quer usar para chamar o Terraform. Para mais informações, consulte Como funcionam as redes autorizadas.
      • Substitua todo o bloco reservation (incluindo a própria linha reservation) por spot: true.

    2. No blueprint examples/gke-a4/gke-a4.yaml do repositório do GitHub, faça as seguintes alterações:

      • No bloco vars, substitua todo o bloco reservation (incluindo a própria linha reservation) por spot: true.

      • Em id: a4-pool, remova o bloco reservation_affinity. Substitua esse bloco pela seguinte linha:

        • spot: $(vars.spot)

  6. Opcional: configure o Managed Lustre para armazenamento compartilhado de alto desempenho. O blueprint do GKE A4 ativa o driver CSI do Managed Lustre por padrão. Para provisionar uma instância do Managed Lustre e um volume permanente com o cluster, faça o seguinte:

    1. Abra o arquivo examples/gke-a4/gke-a4.yaml .
    2. Na seção vars, remova a marca de comentário das variáveis lustre_instance_id, lustre_size_gib e per_unit_storage_throughput.
    3. Na seção # --- MANAGED LUSTRE ADDITIONS ---, remova a marca de comentário dos módulos private_service_access, lustre_firewall_rule, managed-lustre e lustre-pv.

  7. Gere o Application Default Credentials (ADC) para fornecer acesso ao Terraform. Se você estiver usando o Cloud Shell, use o comando gcloud auth application-default login:

    gcloud auth application-default login

  8. Use o comando gcluster deploy para implantar o blueprint e provisionar a infraestrutura do GKE usando tipos de máquina A4:

    cd ~/cluster-toolkit
./gcluster deploy -d \
    examples/gke-a4/gke-a4-deployment.yaml \
    examples/gke-a4/gke-a4.yaml

  9. Quando solicitado, selecione (A)plicar para implantar o blueprint.

    • O blueprint cria redes VPC, uma rede VPC de GPU RDMA, contas de serviço, um cluster e um pool de nós.
    • Para oferecer suporte ao modelo de job fio-bench-job-template no blueprint, são criados buckets doGoogle Cloud , armazenamento de rede e recursos de volume persistente.

A3 Ultra

  1. Inicie o Cloud Shell. Embora seja possível usar um ambiente diferente, recomendamos o uso do Cloud Shell, porque as dependências já estão pré-instaladas para o Cluster Toolkit. Se você não quiser usar o Cloud Shell, siga as instruções para instalar dependências e preparar um ambiente diferente.

  2. Instalar o Cluster Toolkit.

  3. Crie um bucket do Cloud Storage com o controle de versões ativado para armazenar o estado da implantação do Terraform:

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    Substitua as seguintes variáveis:

    • BUCKET_NAME: o nome do novo bucket do Cloud Storage, que precisa atender aos requisitos de nomenclatura de bucket.
    • PROJECT_ID: o ID do projeto Google Cloud .
    • COMPUTE_REGION_TERRAFORM_STATE: a região de computação em que você quer armazenar o estado da implantação do Terraform.

  4. Escolha uma opção de consumo para sua implantação do GKE:

    Por padrão, o arquivo de implantação é configurado para consumir reservas específicas. Para usar um modelo de consumo alternativo (como VMs spot ou modo de provisionamento de início flexível), atualize o arquivo YAML de implantação. Para mais informações, consulte Opções de consumo do GKE.

  5. No blueprint examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml do repositório do GitHub, preencha as seguintes configurações nas seções terraform_backend_defaults e vars para corresponder aos valores específicos da implantação:

    • BUCKET: o nome do bucket do Cloud Storage que você criou na etapa anterior.
    • PROJECT_ID: o ID do projeto Google Cloud .
    • DEPLOYMENT_NAME: um nome exclusivo para a implantação, que precisa ter entre 6 e 30 caracteres. Se o nome da implantação não for exclusivo em um projeto, a criação do cluster falhará. O valor padrão é gke-a3-ultragpu.
    • REGION: a região de computação do cluster.
    • ZONE: a zona do Compute para o pool de nós de máquinas A3 Ultra. Essa zona precisa corresponder à zona em que as máquinas estão disponíveis na sua reserva.
    • AUTHORIZED_CIDR: o intervalo de endereços IP que você quer que se conecte ao cluster. Esse bloco CIDR precisa incluir o endereço IP da máquina que chama o Terraform. Para mais informações, consulte Como as redes autorizadas funcionam.
    • Na seção de reserva específica, defina as seguintes configurações:

    • No bloco reservation_affinity, na lista specific_reservations, especifique o campo de reserva name:

      • Para colocar o pool de nós em qualquer lugar da reserva, forneça o nome da reserva (RESERVATION_NAME).
      • Para segmentar um bloco específico na reserva, use os nomes da reserva e do bloco no seguinte formato:
      RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      Se você não souber quais blocos estão disponíveis na sua reserva, consulte Ver a topologia de uma reserva.

    • STATIC_NODE_COUNT: o número de nós A3 Ultra no cluster.

      Para modificar as configurações avançadas, edite examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml.

    Início flexível

    1. No blueprint examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml do repositório do GitHub, substitua as seguintes variáveis nas seções terraform_backend_defaults e vars para corresponder aos valores específicos da implantação:

      • BUCKET_NAME: o nome do bucket do Cloud Storage que você criou na etapa anterior.
      • DEPLOYMENT_NAME: um nome exclusivo para a implantação, que precisa ter entre 6 e 30 caracteres. Se o nome da implantação não for exclusivo em um projeto, a criação do cluster vai falhar.
      • PROJECT_ID: o ID do projeto Google Cloud .
      • COMPUTE_REGION: a região de computação do cluster.
      • COMPUTE_ZONE: a zona do Compute para o pool de nós de máquinas A3 Ultra.
      • IP_ADDRESS/SUFFIX: o intervalo de endereços IP que você quer permitir que se conecte ao cluster. Esse bloco CIDR precisa incluir o endereço IP da máquina que você quer usar para chamar o Terraform. Para mais informações, consulte Como as redes autorizadas funcionam.
      • Remova o campo reservation e substitua-o por enable_flex_start: true. Adicione na próxima linha enable_queued_provisioning: true se você também quiser usar o provisionamento em fila. Para mais informações, consulte Usar pools de nós com início flexível com provisionamento em fila.
      • Remova static_node_count.

    2. No blueprint examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml do repositório do GitHub, faça as seguintes alterações:

      • No bloco vars, remova static_node_count.
      • No bloco vars, atualize o número version_prefix para "1.32." ou mais recente. Para usar o início flexível no GKE, o cluster precisa usar a versão 1.32.2-gke.1652000 ou mais recente.
      • No bloco vars, substitua todo o bloco reservation (incluindo a própria linha reservation) por enable_flex_start: true e, opcionalmente, enable_queued_provisioning: true.
      • No bloco vars, remova a seguinte linha: kueue_configuration_path: $(ghpc_stage("./kueue-configuration.yaml.tftpl")).
      • Em id: a3-ultragpu-pool, remova a seguinte linha: static_node_count: $(vars.static_node_count).

      • Em id: a3-ultragpu-pool, remova o bloco reservation_affinity. Substitua esse bloco pelas seguintes linhas:

        • enable_flex_start: $(vars.enable_flex_start)
        • auto_repair: false
        • Para o provisionamento em fila, se você quiser ativá-lo, adicione as seguintes linhas extras:
          • enable_queued_provisioning: $(vars.enable_queued_provisioning)
          • autoscaling_total_min_nodes: 0

      • Em id: workload-manager-install, remova o seguinte bloco:

        config_path: $(vars.kueue_configuration_path)
config_template_vars:
  num_gpus: $(a4-pool.static_gpu_count)
  accelerator_type: $(vars.accelerator_type)

        • Para o início flexível com provisionamento em fila, siga estas três etapas:

          1. Adicione gpu_nominal_quota: NOMINAL_QUOTA ao bloco vars. O valor gpu_nominal_quota é usado para definir o nominalQuota de GPUs na especificação ClusterQueue. Neste exemplo, o ClusterQueue só admite cargas de trabalho se a soma das solicitações de GPU for menor ou igual ao valor de NOMINAL_QUOTA. Para mais informações sobre ClusterQueue, consulte o seguinte documento do Kueue sobre fila de cluster.

          2. Atualize o bloco kueue para o seguinte:

            kueue:
   install: true
   config_path: $(vars.kueue_configuration_path)
   config_template_vars:
      num_gpus: $(vars.gpu_nominal_quota)

          3. Substitua o conteúdo do arquivo kueue-configuration.yaml.tftpl pelo seguinte:

            apiVersion: kueue.x-k8s.io/v1beta1
kind: ResourceFlavor
metadata:
   name: "default-flavor"
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: AdmissionCheck
metadata:
   name: dws-prov
spec:
   controllerName: kueue.x-k8s.io/provisioning-request
   parameters:
      apiGroup: kueue.x-k8s.io
      kind: ProvisioningRequestConfig
      name: dws-config
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ProvisioningRequestConfig
metadata:
   name: dws-config
spec:
   provisioningClassName: queued-provisioning.gke.io
   managedResources:
   - nvidia.com/gpu
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ClusterQueue
metadata:
   name: "dws-cluster-queue"
spec:
   namespaceSelector: {}
   resourceGroups:
   - coveredResources: ["nvidia.com/gpu"]
      flavors:
      - name: "default-flavor"
      resources:
      - name: "nvidia.com/gpu"
         nominalQuota: ${num_gpus}
   admissionChecks:
   - dws-prov
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: LocalQueue
metadata:
   namespace: "default"
   name: "dws-local-queue"
spec:
   clusterQueue: "dws-cluster-queue"
---

        • No campo id: job-template, substitua a variável node_count por 2.

    Spot

    1. No blueprint examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml do repositório do GitHub, preencha as seguintes configurações nas seções terraform_backend_defaults e vars para corresponder aos valores específicos da implantação:

      • BUCKET_NAME: o nome do bucket do Cloud Storage que você criou na etapa anterior.
      • DEPLOYMENT_NAME: um nome exclusivo para a implantação, que precisa ter entre 6 e 30 caracteres. Se o nome da implantação não for exclusivo em um projeto, a criação do cluster vai falhar.
      • PROJECT_ID: o ID do projeto Google Cloud .
      • COMPUTE_REGION: a região de computação do cluster.
      • COMPUTE_ZONE: a zona do Compute para o pool de nós de máquinas A3 Ultra.
      • IP_ADDRESS/SUFFIX: o intervalo de endereços IP que você quer permitir que se conecte ao cluster. Esse bloco CIDR precisa incluir o endereço IP da máquina que você quer usar para chamar o Terraform. Para mais informações, consulte Como funcionam as redes autorizadas.
      • Substitua todo o bloco reservation (incluindo a própria linha reservation) por spot: true.
      • NODE_COUNT: o número de nós A3 Ultra no cluster.

    2. No blueprint examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml do repositório do GitHub, faça as seguintes alterações:

      • No bloco vars, substitua toda a variável reservation por spot: true.

      • Na seção id: a3-ultragpu-pool, remova o bloco reservation_affinity. Substitua esse bloco pela seguinte linha:

        • spot: $(vars.spot)

  6. Opcional: configure o Managed Lustre para armazenamento compartilhado de alto desempenho. O blueprint do GKE do A3 Ultra ativa o driver CSI do Managed Lustre por padrão. Para provisionar uma instância do Managed Lustre e um volume permanente com o cluster, faça o seguinte:

    1. Abra o arquivo examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml .
    2. Na seção vars, remova a marca de comentário das variáveis lustre_instance_id, lustre_size_gib e per_unit_storage_throughput.
    3. Na seção # --- MANAGED LUSTRE ADDITIONS ---, remova a marca de comentário dos módulos private_service_access, lustre_firewall_rule, managed-lustre e lustre-pv.

  7. Gere o Application Default Credentials (ADC) para fornecer acesso ao Terraform. Se você estiver usando o Cloud Shell, use o comando gcloud auth application-default login:

    gcloud auth application-default login

  8. Use o comando gcluster deploy para implantar o blueprint e provisionar a infraestrutura do GKE usando os tipos de máquina A3 Ultra:

    cd ~/cluster-toolkit
./gcluster deploy -d \
    examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml \
    examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml

  9. Quando solicitado, selecione (A)plicar para implantar o blueprint.

    • O blueprint cria redes VPC, uma rede VPC de GPU RDMA, contas de serviço, um cluster e um pool de nós.
    • Para oferecer suporte ao modelo de job fio-bench-job-template no blueprint, são criados buckets doGoogle Cloud , armazenamento de rede e recursos de volume persistente.

A3 Mega

  1. Inicie o Cloud Shell. Embora seja possível usar um ambiente diferente, recomendamos o uso do Cloud Shell, porque as dependências já estão pré-instaladas para o Cluster Toolkit. Se você não quiser usar o Cloud Shell, prepare um ambiente diferente seguindo as instruções para instalar dependências.

  2. Instalar o Cluster Toolkit.

  3. Crie um bucket do Cloud Storage com o controle de versões ativado para armazenar o estado da implantação do Terraform:

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    Substitua as seguintes variáveis:

    • BUCKET_NAME: o nome do novo bucket do Cloud Storage, que precisa atender aos requisitos de nomenclatura de bucket.
    • PROJECT_ID: o ID do projeto Google Cloud .
    • COMPUTE_REGION_TERRAFORM_STATE: a região de computação em que você quer armazenar o estado da implantação do Terraform.

  4. No blueprint examples/gke-a3-megagpu/gke-a3-megagpu-deployment.yaml do repositório do GitHub, substitua as seguintes variáveis nas seções terraform_backend_defaults e vars para corresponder aos valores específicos da implantação:

    • BUCKET: o nome do bucket do Cloud Storage que você criou na etapa anterior.
    • DEPLOYMENT_NAME: um nome exclusivo para a implantação, que precisa ter entre 6 e 30 caracteres. Se o nome da implantação não for exclusivo em um projeto, a criação do cluster falhará.
    • PROJECT_ID: o ID do projeto Google Cloud .
    • REGION: a região de computação do cluster.
    • ZONE: a zona do Compute para o pool de nós de máquinas A3 Mega. Essa zona precisa corresponder à zona em que as máquinas estão disponíveis na sua reserva.
    • AUTHORIZED_CIDR: o intervalo de endereços IP que você quer que se conecte ao cluster. Esse bloco CIDR precisa incluir o endereço IP da máquina que chama o Terraform. Para mais informações, consulte Como as redes autorizadas funcionam. Para conseguir o endereço IP da máquina host, execute o comando curl -s https://ifconfig.me.

  5. Escolha uma opção de consumo para sua implantação do GKE:

    Por padrão, o arquivo de implantação é configurado para consumir reservas padrão ou adiantadas. Para usar um modelo de consumo alternativo (como capacidade sob demanda, VMs spot ou modo de provisionamento de início flexível), atualize o arquivo YAML de implantação. Para mais informações, consulte Opções de consumo do GKE.

    Para configurar uma reserva, defina os seguintes valores na seção de reserva específica:

    • No bloco reservation_affinity, na lista specific_reservations, especifique o campo de reserva name:
    • Para colocar o pool de nós em qualquer lugar da reserva, forneça o nome da reserva (RESERVATION_NAME).

    • Para segmentar um bloco específico na reserva, use os nomes da reserva e do bloco no seguinte formato:

      RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      Se você não souber quais blocos estão disponíveis na sua reserva, consulte Ver a topologia de uma reserva.

    • STATIC_NODE_COUNT: o número de nós A3 Mega no cluster.

    Para modificar as configurações avançadas, edite o blueprint examples/gke-a3-megagpu/gke-a3-megagpu.yaml do repositório do GitHub.

  6. Gere o Application Default Credentials (ADC) para fornecer acesso ao Terraform. Se você estiver usando o Cloud Shell, use o comando gcloud auth application-default login:

    gcloud auth application-default login

  7. Use o comando gcluster deploy para implantar o blueprint e provisionar a infraestrutura do GKE usando tipos de máquina A3 Mega:

    cd ~/cluster-toolkit
./gcluster deploy -d \
    examples/gke-a3-megagpu/gke-a3-megagpu-deployment.yaml \
    examples/gke-a3-megagpu/gke-a3-megagpu.yaml

  8. Quando solicitado, selecione (A)plicar para implantar o blueprint. O blueprint cria redes VPC, contas de serviço, um cluster e um pool de nós.

A3 High

  1. Inicie o Cloud Shell. Embora seja possível usar um ambiente diferente, recomendamos o uso do Cloud Shell, porque as dependências já estão pré-instaladas para o Cluster Toolkit. Se você não quiser usar o Cloud Shell, prepare um ambiente diferente seguindo as instruções para instalar dependências.

  2. Instalar o Cluster Toolkit.

  3. Crie um bucket do Cloud Storage com o controle de versões ativado para armazenar o estado da implantação do Terraform:

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    Substitua as seguintes variáveis:

    • BUCKET_NAME: o nome do novo bucket do Cloud Storage, que precisa atender aos requisitos de nomenclatura de bucket.
    • PROJECT_ID: o ID do projeto Google Cloud .
    • COMPUTE_REGION_TERRAFORM_STATE: a região de computação em que você quer armazenar o estado da implantação do Terraform.

  4. No blueprint examples/gke-a3-highgpu/gke-a3-highgpu-deployment.yaml do repositório do GitHub, substitua as seguintes variáveis nas seções terraform_backend_defaults e vars para corresponder aos valores específicos da implantação:

    • BUCKET: o nome do bucket do Cloud Storage que você criou na etapa anterior.
    • DEPLOYMENT_NAME: um nome exclusivo para a implantação, que precisa ter entre 6 e 30 caracteres. Se o nome da implantação não for exclusivo em um projeto, a criação do cluster falhará.
    • PROJECT_ID: o ID do projeto Google Cloud .
    • REGION: a região de computação do cluster.
    • ZONE: a zona do Compute do pool de nós de máquinas A3 High. Essa zona precisa corresponder à zona em que as máquinas estão disponíveis na sua reserva.
    • AUTHORIZED_CIDR: o intervalo de endereços IP que você quer que se conecte ao cluster. Esse bloco CIDR precisa incluir o endereço IP da máquina que chama o Terraform. Para mais informações, consulte Como as redes autorizadas funcionam. Para conseguir o endereço IP da máquina host, execute o comando curl -s https://ifconfig.me.

  5. Escolha uma opção de consumo para sua implantação do GKE:

    Por padrão, o arquivo de implantação é configurado para consumir reservas padrão ou adiantadas. Para usar um modelo de consumo alternativo (como capacidade sob demanda, VMs spot ou modo de provisionamento de início flexível), atualize o arquivo YAML de implantação. Para mais informações, consulte Opções de consumo do GKE.

    Para configurar uma reserva, defina os seguintes valores na seção de reserva específica:

    • No bloco reservation_affinity, na lista specific_reservations, especifique o campo de reserva name:
    • Para colocar o pool de nós em qualquer lugar da reserva, forneça o nome da reserva (RESERVATION_NAME).

    • Para segmentar um bloco específico na reserva, use os nomes da reserva e do bloco no seguinte formato:

      RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      Se você não souber quais blocos estão disponíveis na sua reserva, consulte Ver a topologia de uma reserva.

    • STATIC_NODE_COUNT: o número de nós A3 High no cluster.

    Para modificar as configurações avançadas, edite o blueprint examples/gke-a3-highgpu/gke-a3-highgpu.yaml do repositório do GitHub.

  6. Gere o Application Default Credentials (ADC) para fornecer acesso ao Terraform. Se você estiver usando o Cloud Shell, use o comando gcloud auth application-default login:

    gcloud auth application-default login

  7. Use o comando gcluster deploy para implantar o blueprint e provisionar a infraestrutura do GKE usando tipos de máquina A3 High:

    cd ~/cluster-toolkit
./gcluster deploy -d \
    examples/gke-a3-highgpu/gke-a3-highgpu-deployment.yaml \
    examples/gke-a3-highgpu/gke-a3-highgpu.yaml

  8. Quando solicitado, selecione (A)plicar para implantar o blueprint. O blueprint cria redes VPC, contas de serviço, um cluster e um pool de nós.

Executar jobs de amostra do Dynamic Workload Scheduler

Se você provisionou o cluster usando o Dynamic Workload Scheduler (provisionamento de início flexível ou provisionamento em fila), valide a programação de cargas de trabalho enviando jobs de amostra do Kubernetes.

Para mais informações sobre os modos de provisionamento do Dynamic Workload Scheduler, consulte Início flexível do Dynamic Workload Scheduler com provisionamento em fila.

Enviar um job de amostra

Selecione a guia que corresponde à sua opção de consumo:

Início flexível

Esta tarefa é opcional e só se aplica se você provisionou o cluster com o início flexível. As cargas de trabalho configuradas para o início flexível exigem o seletor de nós cloud.google.com/gke-flex-start: "true" na especificação do pod.

  1. Envie o job de amostra de início flexível:

    kubectl apply -f examples/dws-sample-workloads/sample-job-flex.yaml

  2. Monitore o status do job e dos pods:

    kubectl get jobs
kubectl describe job JOB_NAME
kubectl get pods
kubectl describe pod POD_NAME

    Substitua:

    • JOB_NAME: o nome do job.
    • POD_NAME: o nome do pod.

  3. Quando o job for concluído, exclua os recursos dele:

    kubectl delete -f examples/dws-sample-workloads/sample-job-flex.yaml

Provisionamento em fila

Esta tarefa é opcional e se aplica apenas se você tiver provisionado o cluster com o provisionamento em fila. As cargas de trabalho configuradas para provisionamento em fila exigem o seguinte rótulo e anotação na especificação do pod:

  • Rótulo: kueue.x-k8s.io/queue-name: dws-local-queue
  • Anotação: provreq.kueue.x-k8s.io/maxRunDurationSeconds: "MAX_RUN_DURATION"

Para mais informações, consulte Requisitos de manifesto de carga de trabalho para provisionamento em fila.

  1. Envie o job de provisionamento em fila de amostra:

    kubectl apply -f examples/dws-sample-workloads/sample-job-flex-queue.yaml

  2. Monitore o status do job e dos pods:

    kubectl get jobs
kubectl describe job JOB_NAME
kubectl get pods
kubectl describe pod POD_NAME

    Substitua:

    • JOB_NAME: o nome do job.
    • POD_NAME: o nome do pod.

  3. Quando o job for concluído, exclua os recursos dele:

    kubectl delete -f examples/dws-sample-workloads/sample-job-flex-queue.yaml

Teste a performance das redes

Recomendamos que você valide a funcionalidade dos clusters provisionados. Para isso, use os testes da NCCL, que são testes da NVIDIA Collective Communications Library (NCCL) otimizados para o ambiente do Google.

Executar comparativos reproduzíveis

Depois de criar um cluster usando o Cluster Toolkit, é possível reproduzir comparativos de mercado de pré-treinamento para modelos abertos de machine learning grandes na série de máquinas escolhida seguindo as receitas fornecidas no GitHub.

Cada receita fornece as instruções para concluir as seguintes tarefas:

  • Prepare o ambiente.
  • Execute o comparativo.
  • Analisar os resultados do comparativo de mercado. Essa revisão inclui os resultados do comparativo de mercado e registros detalhados para análise posterior.

Para conferir todas as receitas disponíveis para treinamento e outros tipos de cargas de trabalho, consulte o repositório do GitHub de receitas de GPU.

Limpar os recursos criados pelo Cluster Toolkit

Para evitar cobranças recorrentes pelos recursos usados nesta página, use o comando gcluster destroy para limpar os recursos provisionados pelo Cluster Toolkit, incluindo as redes VPC e o cluster do GKE:

   cd ~/cluster-toolkit
   ./gcluster destroy CLUSTER_NAME/

Substitua CLUSTER_NAME pelo nome do cluster. Para os clusters criados com o Cluster Toolkit, o nome do cluster é baseado no nome de DEPLOYMENT_NAME.

A seguir