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 oferecer 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 executar 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 oferece uma única plataforma para executar um conjunto diversificado de cargas de trabalho para as necessidades da sua organização. Isso inclui pré-treinamento distribuído de alto desempenho, ajuste fino e inferência de modelos, disponibilizaçã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 criação de clusters oferecem diferentes graus de facilidade e flexibilidade na configuração de clusters e no agendamento 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
  • Se você quiser usar a Google Cloud CLI para essa 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 papéis (roles/iam.roleAdmin)
    • Gerenciador de versões de secret do Secret Manager (roles/secretmanager.secretVersionManager)

Escolher uma opção de consumo e obter capacidade

  1. Escolha uma opção de consumo. Faça sua escolha com base em como você quer receber e usar 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 seguintes requisitos 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 a versão 1.35.0-gke.2745000 ou mais recente do GKE.
    • Para a versão 1.34, use a versão 1.34.3-gke.1318000 ou mais recente do GKE.

    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 coerente baseado em driver (CDMM), 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. Com o CDMM, a memória da GPU pode ser gerenciada pelo driver em vez do sistema operacional (SO). Essa abordagem ajuda a evitar a ativação on-line da memória da GPU pelo SO e expõe a memória da GPU como um nó de acesso à memória não uniforme (NUMA) para o SO. Não há suporte para GPUs de várias instâncias 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 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 o GKE versão 1.33.4-gke.1036000 ou mais recente.
    • 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 coerente baseado em driver (CDMM), 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. Com o CDMM, a memória da GPU pode ser gerenciada pelo driver em vez do sistema operacional (SO). Essa abordagem ajuda a evitar a ativação on-line da memória da GPU pelo SO e expõe a memória da GPU como um nó de acesso à memória não uniforme (NUMA) para o SO. Não há suporte para GPUs de várias instâncias 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 de 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 nas instâncias de máquina virtual (VM) A4X exigem uma versão mínima do driver de GPU R580. Consulte os requisitos de versão mencionados anteriormente.
    • A4: as GPUs B200 em instâncias de VM 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 de VM A3 Ultra exigem uma versão mínima do driver de GPU R550, que está disponível no GKE 1.31 como a versão do driver latest. Para A3 Ultra, defina gpu-driver-version=latest com o GKE 1.31. Para o GKE versão 1.31.5-gke.1169000 ou mais recente, o GKE, por padrão, instala automaticamente as versões do driver de GPU R550 nos nós A3 Ultra.
    • A3 Mega e A3 High: as GPUs H100 nas VMs 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 compatíveis. 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 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 antes da 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.

  • É necessário usar o modelo de provisionamento vinculado à reserva para criar clusters com A4X Max e A4X. Outros modelos de provisionamento estão indisponí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 cluster, garantindo que seu projeto siga as práticas recomendadas e atenda aos requisitos de um cluster do GKE otimizado para IA. Esta seção também mostra como usar o Terraform para provisionar e gerenciar a infraestrutura da implantação.

A4X Max

  1. Inicie o Cloud Shell. Você pode usar um ambiente diferente, mas 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. Instale 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 sua implantação:

    • BUCKET: o nome do bucket do Cloud Storage criado na etapa anterior.
    • PROJECT_ID: o ID do projeto Google Cloud .
    • DEPLOYMENT_NAME: um nome exclusivo para o 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-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 usar 18 nós para obter a topologia de GPU de 1x72 em um subbloco usando um domínio NVLink.
    • AUTHORIZED_CIDR: o intervalo de endereços IP que você quer permitir se conectar 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.

    • 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 dela (RESERVATION_NAME).

      • Para segmentar um bloco específico na sua 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.

    • RESERVATION_PROJECT_ID: o ID do projeto 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 maior que 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. Gere as credenciais padrão do aplicativo (ADC) para dar acesso ao Terraform. Se você estiver usando o Cloud Shell, faça login e configure o ADC:

    gcloud auth application-default login

  6. Use o comando gcluster deploy para implantar o blueprint e provisionar a infraestrutura do GKE usando tipos de máquinas 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 \
--deployment DEPLOYMENT_NAME

    Substitua DEPLOYMENT_NAME pelo nome da implantação.

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

    • O blueprint cria redes VPC, uma rede VPC de RDMA de GPU, 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, os recursosGoogle Cloud buckets, armazenamento de rede e volumes permanentes são criados.

A4X

  1. Inicie o Cloud Shell. Você pode usar um ambiente diferente, mas 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. Instale 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 sua implantação:

    • BUCKET: o nome do bucket do Cloud Storage criado na etapa anterior.
    • PROJECT_ID: o ID do projeto Google Cloud .
    • DEPLOYMENT_NAME: um nome exclusivo para o 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-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 usar 18 nós para obter a topologia de GPU de 1x72 em um subbloco usando um domínio NVLink.
    • AUTHORIZED_CIDR: o intervalo de endereços IP que você quer permitir se conectar 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.

    • 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 dela (RESERVATION_NAME).

      • Para segmentar um bloco específico na sua 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.

    • RESERVATION_PROJECT_ID: o ID do projeto 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 maior que 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. Gere as credenciais padrão do aplicativo (ADC) para dar acesso ao Terraform. Se você estiver usando o Cloud Shell, faça login e configure o ADC:

    gcloud auth application-default login

  6. Implante o blueprint para 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

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

    • O blueprint cria redes VPC, uma rede VPC de RDMA de GPU, 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, os recursosGoogle Cloud buckets, armazenamento de rede e volumes permanentes são criados.

A4

  1. Inicie o Cloud Shell. Você pode usar um ambiente diferente, mas 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. Instale 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. Os arquivos que você precisa editar para criar um cluster dependem da opção de consumo que está usando para sua implantação. Selecione a guia que corresponde ao modelo de provisionamento da sua opção de consumo.

    Vinculada à reserva

    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 sua implantação:

    • BUCKET: o nome do bucket do Cloud Storage criado na etapa anterior.
    • PROJECT_ID: o ID do projeto Google Cloud .
    • DEPLOYMENT_NAME: um nome exclusivo para o 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. 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 A4 no cluster.
    • AUTHORIZED_CIDR: o intervalo de endereços IP que você quer permitir que se conectem 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.

    • 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 dela (RESERVATION_NAME).

      • Para segmentar um bloco específico na sua 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 sua implantação:

      • BUCKET: o nome do bucket do Cloud Storage criado na etapa anterior.
      • PROJECT_ID: o ID do projeto Google Cloud .
      • DEPLOYMENT_NAME: um nome exclusivo para o 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 conectem 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 mudanças:

      • No bloco vars, remova static_node_count.
      • No bloco vars, verifique se o número version_prefix é "1.32." ou maior. Para usar o início flexível no GKE, seu 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 do 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 este bloco pelas seguintes linhas:

        • enable_flex_start: $(vars.enable_flex_start)
        • auto_repair: false
        • Para o provisionamento em fila, se você quiser ativar, adicione as seguintes linhas:
          • 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 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 (a seguir, consulte a etapa de definição de ClusterQueue). 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 a 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 sua implantação:

      • BUCKET: o nome do bucket do Cloud Storage criado na etapa anterior.
      • PROJECT_ID: o ID do projeto Google Cloud .
      • DEPLOYMENT_NAME: um nome exclusivo para o 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 conectem 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 linha reservation) por spot: true.

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

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

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

        • spot: $(vars.spot)

  5. Gere as credenciais padrão do aplicativo (ADC) para dar acesso ao Terraform. Se você estiver usando o Cloud Shell, faça login e configure o ADC:

    gcloud auth application-default login

  6. Implante o blueprint para 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

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

    • O blueprint cria redes VPC, uma rede VPC de RDMA de GPU, 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, os recursosGoogle Cloud buckets, armazenamento de rede e volumes permanentes são criados.

A3 Ultra

  1. Inicie o Cloud Shell. Você pode usar um ambiente diferente, mas 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. Instale 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. Os arquivos que você precisa editar para criar um cluster dependem da opção de consumo que está usando para sua implantação. Selecione a guia que corresponde ao modelo de provisionamento da sua opção de consumo.

    Vinculada à reserva

    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 sua implantação:

    • BUCKET_NAME: o nome do bucket do Cloud Storage criado na etapa anterior.
    • DEPLOYMENT_NAME: um nome exclusivo para o 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. Essa zona precisa corresponder à zona em que as máquinas estão disponíveis na sua reserva.

    • IP_ADDRESS/SUFFIX: o intervalo de endereços IP que você quer permitir para se conectar 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.

    • 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 dela (RESERVATION_NAME).

      • Para segmentar um bloco específico na sua 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.

    • NODE_COUNT: o número de nós A3 Ultra no seu 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 sua implantação:

      • BUCKET_NAME: o nome do bucket do Cloud Storage criado na etapa anterior.
      • DEPLOYMENT_NAME: um nome exclusivo para o 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 para se conectar 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 mudanças:

      • 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, seu 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 este bloco pelas seguintes linhas:

        • enable_flex_start: $(vars.enable_flex_start)
        • auto_repair: false
        • Para o provisionamento em fila, se você quiser ativar, adicione as seguintes linhas:
          • 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 usar 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ó 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 a 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 sua implantação:

      • BUCKET_NAME: o nome do bucket do Cloud Storage criado na etapa anterior.
      • DEPLOYMENT_NAME: um nome exclusivo para o 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 para se conectar 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 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 mudanças:

      • 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)

  5. Gere as Application Default Credentials (ADC) para fornecer acesso ao Terraform. Se você estiver usando o Cloud Shell, faça login e configure o ADC:

    gcloud auth application-default login

  6. Implante o blueprint para provisionar a infraestrutura do GKE usando 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

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

    • O blueprint cria redes VPC, uma rede VPC de RDMA de GPU, 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, os recursosGoogle Cloud buckets, armazenamento de rede e volumes permanentes são criados.

A3 Mega

  1. Inicie o Cloud Shell. Você pode usar um ambiente diferente, mas 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, prepare um ambiente diferente seguindo as instruções para instalar dependências.

  2. Instale 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. Os arquivos que você precisa editar para criar um cluster dependem da opção de consumo que está usando para sua implantação. Selecione a guia que corresponde ao modelo de provisionamento da sua opção de consumo.

    Vinculada à reserva

    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 sua implantação:

    • BUCKET: o nome do bucket do Cloud Storage criado na etapa anterior.
    • DEPLOYMENT_NAME: um nome exclusivo para o 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 .
    • 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 permitir que se conectem 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.

    • 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 dela (RESERVATION_NAME).

      • Para segmentar um bloco específico na sua 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 examples/gke-a3-megagpu/gke-a3-megagpu.yaml.

    Início flexível

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

      • BUCKET: o nome do bucket do Cloud Storage criado na etapa anterior.
      • DEPLOYMENT_NAME: um nome exclusivo para o 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 .
      • 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.
      • AUTHORIZED_CIDR: o intervalo de endereços IP que você quer permitir que se conectem 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. Se você também quiser usar o provisionamento em fila, adicione enable_queued_provisioning: true à seguinte linha. 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-megagpu/gke-a3-megagpu.yaml do repositório do GitHub, faça as seguintes mudanças:

      • 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, seu 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_megagpu_pool, remova a seguinte linha: static_node_count: $(vars.static_node_count).

      • Em id: a3_megagpu_pool, remova o bloco reservation_affinity. Substitua este bloco pelas seguintes linhas:

        • enable_flex_start: $(vars.enable_flex_start)
        • auto_repair: false
        • Para o provisionamento em fila, se você quiser ativar, adicione as seguintes linhas:
          • 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: $(a3_megagpu_pool.static_gpu_count)
  accelerator_type: $(vars.accelerator_type)

        • Para usar 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ó 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 a 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 o valor da variável node_count por 2.

    Spot

    1. No blueprint examples/gke-a3-megagpu/gke-a3-megagpu-deployment.yaml do repositório do GitHub, atualize as seguintes variáveis para corresponder aos valores específicos da sua implantação:

      • BUCKET: o nome do bucket do Cloud Storage criado na etapa anterior.
      • DEPLOYMENT_NAME: um nome exclusivo para o 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 .
      • 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.
      • AUTHORIZED_CIDR: o intervalo de endereços IP que você quer permitir que se conectem 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 linha reservation) por provisioning_model: SPOT.
      • STATIC_NODE_COUNT: o número de nós A3 Mega no cluster.

    2. No blueprint examples/gke-a3-megagpu/gke-a3-megagpu.yaml do repositório do GitHub, faça as seguintes mudanças:

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

      • Na seção id: a3_megagpu_pool, remova o bloco reservation_affinity. Substitua esse bloco pela seguinte linha:

        • spot: $(vars.spot)

  5. Gere as Application Default Credentials (ADC) para fornecer acesso ao Terraform. Se você estiver usando o Cloud Shell, execute o comando a seguir:

    gcloud auth application-default login

  6. Implante o blueprint para 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.yaml

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

    • O blueprint cria redes VPC, uma rede VPC de RDMA de GPU, 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, os recursosGoogle Cloud buckets, armazenamento de rede e volumes permanentes são criados.

A3 High

  1. Inicie o Cloud Shell. Você pode usar um ambiente diferente, mas 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, prepare um ambiente diferente seguindo as instruções para instalar dependências.

  2. Instale o Cluster Toolkit.

  3. Crie um bucket do Cloud Storage 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.
    • 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. Os arquivos que você precisa editar para criar um cluster dependem da opção de consumo que está usando para sua implantação. Selecione a guia que corresponde ao modelo de provisionamento da sua opção de consumo.

    Vinculada à reserva

    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 sua implantação:

    • BUCKET: o nome do bucket do Cloud Storage criado na etapa anterior.
    • DEPLOYMENT_NAME: um nome exclusivo para o 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 .
    • REGION: a região de computação do cluster.
    • ZONE: a zona do Compute para o 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 permitir que se conectem 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.
    • STATIC_NODE_COUNT: o número de nós A3 High no cluster.

    • 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 dela (RESERVATION_NAME).

      • Para segmentar um bloco específico na sua 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.

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

    Início flexível

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

      • BUCKET: o nome do bucket do Cloud Storage criado na etapa anterior.
      • DEPLOYMENT_NAME: um nome exclusivo para o 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 .
      • REGION: a região de computação do cluster.
      • ZONE: a zona do Compute para o pool de nós de máquinas A3 High.
      • AUTHORIZED_CIDR: o intervalo de endereços IP que você quer permitir que se conectem 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. Se você também quiser usar o provisionamento em fila, adicione enable_queued_provisioning: true à seguinte linha. 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-highgpu/gke-a3-highgpu.yaml do repositório do GitHub, faça as seguintes mudanças:

      • 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, seu 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_highgpu_pool, remova a seguinte linha: static_node_count: $(vars.static_node_count).

      • Em id: a3_highgpu_pool, remova o bloco reservation_affinity. Substitua este bloco pelas seguintes linhas:

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

      • Em id: workload_component_install, remova o seguinte bloco:

        config_path: $(vars.kueue_configuration_path)
config_template_vars:
  num_gpus: $(a3_highgpu_pool.static_gpu_count)
  accelerator_type: $(vars.accelerator_type)

        • Para usar 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ó 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 a 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 o valor da variável node_count por 2.

    Spot

    1. No blueprint examples/gke-a3-highgpu/gke-a3-highgpu-deployment.yaml do repositório do GitHub, atualize as seguintes variáveis para corresponder aos valores específicos da sua implantação:

      • BUCKET: o nome do bucket do Cloud Storage criado na etapa anterior.
      • DEPLOYMENT_NAME: um nome exclusivo para o 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 .
      • REGION: a região de computação do cluster.
      • ZONE: a zona do Compute para o pool de nós de máquinas A3 High.
      • AUTHORIZED_CIDR: o intervalo de endereços IP que você quer permitir que se conectem 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 a linha reservation: por provisioning_model: SPOT.
      • STATIC_NODE_COUNT: o número de nós A3 High no cluster.

    2. No blueprint examples/gke-a3-highgpu/gke-a3-highgpu.yaml do repositório do GitHub, faça as seguintes mudanças:

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

      • Na seção id: a3_highgpu_pool, remova o bloco reservation_affinity. Substitua esse bloco pela seguinte linha:

        • spot: $(vars.spot)

  5. Gere as Application Default Credentials (ADC) para fornecer acesso ao Terraform. Se você estiver usando o Cloud Shell, execute o comando a seguir:

    gcloud auth application-default login

  6. Implante o blueprint para 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

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

    • O blueprint cria redes VPC, uma rede VPC de RDMA de GPU, 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, os recursosGoogle Cloud buckets, armazenamento de rede e volumes permanentes são criados.

Testar o desempenho da rede

Recomendamos que você valide a funcionalidade dos clusters provisionados. Para isso, use os testes do 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 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 instruções para concluir as seguintes tarefas:

  • Prepare seu ambiente.
  • Execute o comparativo.
  • Analise os resultados dos comparativos de mercado. Isso inclui os resultados do comparativo de mercado e registros detalhados para análise mais detalhada.

Para conferir todas as receitas disponíveis para treinamento e outros tipos de cargas de trabalho, consulte o repositório GPU recipes do GitHub (em inglês).

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 DEPLOYMENT_NAME.

A seguir