Atribua recursos de rede através da DRANET gerida do GKE

Padrão

Pré-visualização

Esta funcionalidade está sujeita aos "Termos das Ofertas de Pré-DG" na secção Termos Gerais de Serviço dos Termos Específicos do Serviço. As funcionalidades de pré-DG estão disponíveis "tal como estão" e podem ter apoio técnico limitado. Para mais informações, consulte as descrições das fases de lançamento.

O GKE DRANET (Distributed Resource Allocation Network) é uma funcionalidade gerida do GKE que se baseia no projeto DRANET de código aberto, que implementa a API Kubernetes DRA para recursos de rede. O DRANET permite-lhe pedir e atribuir recursos de rede de alto desempenho para os seus pods, incluindo interfaces de rede que suportam o acesso direto à memória remoto (RDMA). Esta abordagem oferece uma API portátil e alinhada a montante para a gestão de recursos de rede.

Este documento oferece uma vista geral conceptual da DRANET do GKE e mostra-lhe como atribuir recursos de rede a cargas de trabalho nos seus clusters do GKE.

Este documento destina-se a arquitetos da nuvem e especialistas em redes que criam redes para as respetivas organizações. Para uma vista geral de toda a documentação do GKE, consulte o artigo Explore a documentação do GKE. Para saber mais sobre as funções e as tarefas comuns referenciadas no conteúdo, consulte o artigo Funções e tarefas comuns do utilizador do GKE. Google Cloud

Antes de ler este documento, certifique-se de que conhece o seguinte:

• Atribuição dinâmica de recursos
• Acerca da atribuição dinâmica de recursos no GKE
• Conceitos do Kubernetes
• Redes do GKE
• Princípios básicos de redes do GKE

Como funciona a DRANET gerida do GKE

O DRANET gerido do GKE é implementado através de um networking-dra-driver DaemonSet. Este DaemonSet é executado em nós com GPUs ou TPUs que têm o GKE DRANET ativado. Funciona como um agente ao nível do nó para tornar as interfaces de rede detetáveis e atribuíveis a pods através das APIs de atribuição dinâmica de recursos (DRA) do Kubernetes.

Nas versões 1.34.1-gke.1829001 e posteriores do GKE, o GKE instala automaticamente recursos DeviceClass para redes. Estas classes definem os tipos de dispositivos de rede que pode pedir. Por exemplo, o GKE cria a classe mrdma.google.com para dispositivos compatíveis com RDMA e a classe netdev.google.com para outros dispositivos de rede.

Para usar o GKE DRANET, primeiro, ative o controlador GKE DRANET num conjunto de nós com GPUs ou TPUs.

Para pedir dispositivos de rede para uma carga de trabalho, defina um ResourceClaimTemplate. Este modelo especifica o DeviceClass e o modo de atribuição, como pedir todos os dispositivos disponíveis num nó. Na especificação do pod, faça referência a este modelo num campo resourceClaims para conceder ao pod acesso às interfaces de rede pedidas no nó.

Quando usar o DRANET gerido do GKE

O GKE DRANET oferece uma forma padronizada de gerir recursos de rede que têm conhecimento da topologia e das dependências. Esta normalização torna-o numa solução adequada para cargas de trabalho de IA e ML que requerem redes de alto desempenho.

Os exemplos de utilização comuns para pedir interfaces de rede para um pod incluem:

• Pedir todas as interfaces compatíveis com RDMA disponíveis.
• Pedir um número específico de interfaces compatíveis com RDMA.
• Pedir todas as interfaces não RDMA disponíveis.
• Pedir um número específico de interfaces não RDMA.

Principais considerações ao usar o DRANET gerido do GKE para trabalhar em rede

Considere os seguintes pontos quando usar o GKE DRANET para redes:

• Interfaces de rede dedicadas

  Quando usa o GKE DRANET para reivindicar uma interface de rede para um pod, essa interface é dedicada a esse pod. Outros pods no mesmo nó não podem partilhá-lo. Isto garante que o Pod tem acesso exclusivo à largura de banda total e aos recursos dessa interface, o que é uma vantagem fundamental para cargas de trabalho sensíveis ao desempenho.

• Use o controlador DRANET gerido do GKE de forma independente

  Pode ativar o controlador DRA do GKE para gerir recursos de rede sem ativar outros controladores DRANET do GKE. Para tal, adicione a etiqueta cloud.google.com/gke-networking-dra-driver=true a um conjunto de nós com GPUs e TPUs.

• Use outros controladores DRA do GKE

  Para alcançar um débito mais elevado em cargas de trabalho de IA/ML exigentes, combine a API DRA para aceleradores (como GPUs e TPUs) com a rede gerida DRANET do GKE. Esta abordagem combinada melhora o alinhamento dos recursos e a perceção da topologia. Para orientações sobre a utilização do DRA para outros recursos, consulte o artigo Prepare a infraestrutura do GKE para cargas de trabalho do DRA.

• Evite configurações em conflito

  O controlador GKE DRANET gere interfaces RDMA e gVNICs que não têm intervalos de endereços IP secundários configurados. Não use o controlador GKE DRANET e a API de várias redes do GKE com um recurso de rede do tipo Device no mesmo cluster. A utilização do controlador e da API em conjunto não é suportada porque ambas as APIs tentam gerir o mesmo conjunto de NICs, o que pode levar a uma configuração incorreta e a um comportamento imprevisível.

Requisitos

Para usar o DRANET gerido do GKE, o seu ambiente tem de cumprir os seguintes requisitos:

• Versão 1.34.1-gke.1829001 ou posterior do GKE.
• O GKE Dataplane V2 está ativado no cluster.
• (Pré-visualização) O GKE DRANET está disponível em máquinas A4X Max.

Limitações

O GKE DRANET tem as seguintes limitações:

• Não pode usar o GKE DRANET para atribuir a placa de interface de rede (NIC) predefinida ou NICs virtuais (como veth).
• O redimensionamento automático de clusters e o Autopilot não são suportados.
• Não pode usar o GKE DRANET com interfaces onde configurou um secondaryPodRange.

Antes de começar

Antes de começar, certifique-se de que realizou as seguintes tarefas:

• Ative a API Google Kubernetes Engine.
Ative a API Google Kubernetes Engine
• Se quiser usar a CLI gcloud para esta tarefa, instale-a e, em seguida, inicialize a CLI gcloud. Se instalou anteriormente a CLI gcloud, execute o comando gcloud components update para obter a versão mais recente. As versões anteriores da CLI gcloud podem não suportar a execução dos comandos neste documento.
  Nota: para instalações existentes da CLI gcloud, certifique-se de que define a compute/region propriedade. Se usar principalmente clusters zonais, defina o compute/zone. Ao definir uma localização predefinida, pode evitar erros na CLI gcloud, como os seguintes: One of [--zone, --region] must be supplied: Please specify location. Pode ter de especificar a localização em determinados comandos se a localização do seu cluster for diferente da predefinição que definiu.

Funções necessárias

Para receber as autorizações de que precisa para criar node pools e atribuir recursos de rede, peça ao seu administrador para lhe conceder a função do IAM Administrador do Kubernetes Engine (roles/container.admin) no seu projeto. Para mais informações sobre a atribuição de funções, consulte o artigo Faça a gestão do acesso a projetos, pastas e organizações.

Também pode conseguir as autorizações necessárias através de funções personalizadas ou outras funções predefinidas.

Crie um cluster

Crie um cluster padrão do GKE que use o GKE Dataplane V2:

gcloud container clusters create CLUSTER_NAME \
    --enable-dataplane-v2 \
    --region=CONTROL_PLANE_LOCATION \
    --project=PROJECT_ID \
    --cluster-version=CLUSTER_VERSION

Substitua o seguinte:

• CLUSTER_NAME: o nome do novo cluster.
• CONTROL_PLANE_LOCATION: a região ou a zona do plano de controlo do cluster, como us-central1 ou us-central1-a.
• PROJECT_ID: o ID do seu Google Cloud projeto.
• CLUSTER_VERSION: a versão do GKE do seu cluster. Esta versão tem de ser 1.34.1-gke.1829001 ou posterior.

Use interfaces RDMA a partir de um node pool de GPU

As secções seguintes descrevem como configurar um conjunto de nós de GPU e uma carga de trabalho para usar interfaces de rede RDMA com o GKE DRANET.

Ative o controlador DRANET gerido do GKE num pool de nós de GPU

Para ativar o controlador GKE DRANET num conjunto de nós de GPU que suporte RDMA, adicione a etiqueta cloud.google.com/gke-networking-dra-driver=true quando criar o conjunto de nós.

gcloud beta container node-pools create NODE_POOL_NAME \
  --region=REGION \
  --cluster=CLUSTER_NAME \
  --node-locations=NODE_LOCATIONS \
  --accelerator type=ACCELERATOR_TYPE,count=ACCELERATOR_COUNT,gpu-driver-version=DRIVER_VERSION \
  --machine-type=MACHINE_TYPE \
  --num-nodes=NUM_NODES \
  --reservation-affinity=specific \
  --reservation=projects/RESERVATION_PROJECT/reservations/RESERVATION_NAME/reservationBlocks/RESERVATION_BLOCK \
  --accelerator-network-profile=auto \
  --node-labels=cloud.google.com/gke-networking-dra-driver=true

Substitua o seguinte:

• NODE_POOL_NAME: o nome do novo node pool.
• REGION: a Google Cloud região do seu cluster.
• CLUSTER_NAME: o nome do seu cluster.

• ACCELERATOR_TYPE: o tipo de acelerador de GPU:

  Por exemplo:

  • VMs A4: introduza nvidia-b200.
  • VMs A3 Ultra: introduza nvidia-h200-141gb.

• ACCELERATOR_COUNT: o número de GPUs a associar aos nós no node pool. Por exemplo, para as VMs a4-highgpu-8g e a3-ultragpu-8g, a quantidade de GPUs é 8.

• DRIVER_VERSION: a versão do controlador da GPU a usar. Por exemplo, default ou latest.

• MACHINE_TYPE: o tipo de máquina do node pool, por exemplo, a3-ultragpu-8g.

• NUM_NODES: o número de nós para o node pool. Para o início flexível, este valor tem de ser definido como 0.

• RESERVATION_PROJECT: o ID do projeto da reserva.

• RESERVATION_NAME: o nome da sua reserva. Para encontrar este valor, consulte o artigo Veja pedidos de reserva futuros.

• RESERVATION_BLOCK: o nome de um bloco específico na reserva. Para encontrar este valor, consulte o artigo Veja pedidos de reserva futuros.

Este comando usa perfis de rede de aceleradores para configurar automaticamente redes VPC e sub-redes para as suas VMs de acelerador. Em alternativa, pode especificar explicitamente a sua rede de VPC e sub-redes.

Implemente recursos RDMA de uma carga de trabalho

Para atribuir recursos RDMA a um pod, especifique um ResourceClaimTemplate.

1. Crie um ResourceClaimTemplate para definir como atribuir os dispositivos RDMA. O seguinte manifesto pede todos os dispositivos mrdma disponíveis no nó. Guarde o manifesto como all-mrdma-template.yaml:

   apiVersion: resource.k8s.io/v1
   kind: ResourceClaimTemplate
   metadata:
     name: all-mrdma
   spec:
     spec:
       devices:
         requests:
         - name: req-mrdma
           exactly:
             deviceClassName: mrdma.google.com
             allocationMode: All
   

2. Aplique o manifesto:

   kubectl apply -f all-mrdma-template.yaml
   

3. Implemente a sua carga de trabalho e consulte o ResourceClaimTemplate. O manifesto seguinte implementa um Pod que faz referência ao modelo all-mrdma, o que concede ao Pod acesso às interfaces RDMA no nó. Guarde o manifesto como agnhost-rdma-pod.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: agnhost-rdma
     namespace: default
     labels:
       app: agnhost
   spec:
     containers:
     - name: agnhost
       image: registry.k8s.io/e2e-test-images/agnhost:2.39
       args: ["netexec", "--http-port", "80"]
       ports:
       - name: agnhost-port
         containerPort: 80
       resources:
         claims:
         - name: rdma
         limits:
           nvidia.com/gpu: 1
     resourceClaims:
     - name: rdma
       resourceClaimTemplateName: all-mrdma
   

4. Aplique o manifesto:

   kubectl apply -f agnhost-rdma-pod.yaml
   

5. Verifique se as interfaces de rede adicionais atribuídas estão visíveis no Pod.

   kubectl exec agnhost-rdma -- ls /sys/class/net
   

   O exemplo de saída seguinte mostra as interfaces eth0 e lo predefinidas, bem como as interfaces RDMA atribuídas, como gpu0rdma0. O número e os nomes das interfaces de rede (NICs) variam consoante o tipo de máquina do nó do GKE.

   eth0
   gpu0rdma0
   gpu1rdma0
   gpu2rdma0
   gpu3rdma0
   lo
   

Use interfaces de rede não RDMA num node pool de TPU

As secções seguintes descrevem como configurar um conjunto de nós de TPU e uma carga de trabalho para usar interfaces de rede não RDMA com o GKE DRANET.

Valide as DeviceClasses de rede

Verifique se os recursos de DeviceClass rede existem no seu cluster.

kubectl get deviceclass netdev.google.com

O resultado é semelhante ao seguinte:

NAME                AGE
netdev.google.com   2d22h

Ative o controlador DRANET gerido pelo GKE num conjunto de nós de fatia de TPU

Para ativar o controlador DRANET do GKE ao criar um conjunto de nós de fatia de TPU, adicione a etiqueta cloud.google.com/gke-networking-dra-driver=true.

gcloud beta container node-pools create NODE_POOL_NAME \
    --location=LOCATION \
    --cluster=CLUSTER_NAME \
    --node-locations=NODE_LOCATIONS \
    --machine-type=MACHINE_TYPE \
    --tpu-topology=TPU_TOPOLOGY \
    --num-nodes=NUM_NODES \
    --accelerator-network-profile=auto \
    --node-labels=cloud.google.com/gke-networking-dra-driver=true

Substitua o seguinte:

• NODE_POOL_NAME: o nome do novo node pool.
• LOCATION: a Google Cloud região ou a zona do seu cluster.
• CLUSTER_NAME: o nome do seu cluster.
• NODE_LOCATIONS: as Google Cloud zonas dos nós no node pool.
• MACHINE_TYPE: o tipo de máquina a usar para os nós. Para mais informações sobre os tipos de máquinas compatíveis com a TPU, consulte o artigo Escolha a versão da TPU.
• TPU_TOPOLOGY: a topologia da TPU, por exemplo, 2x4x4. O formato da topologia depende da versão da TPU. Para saber mais sobre as topologias de TPUs, consulte o artigo Escolha uma topologia.
• NUM_NODES: o número de nós no node pool.

Para mais informações, consulte o artigo Crie um conjunto de nós de fatia de TPU de host único.

Implemente uma carga de trabalho que reivindique todos os dispositivos de rede

Para atribuir dispositivos de rede não RDMA a um pod, especifique um ResourceClaimTemplate.

1. Crie um ResourceClaimTemplate que faça referência ao netdev.google.com DeviceClass. O manifesto seguinte pede todos os dispositivos de rede não RDMA disponíveis no nó.

   Guarde o manifesto como all-netdev-template.yaml:

   apiVersion: resource.k8s.io/v1
   kind: ResourceClaimTemplate
   metadata:
     name: all-netdev
   spec:
     spec:
       devices:
         requests:
         - name: req-netdev
           exactly:
             deviceClassName: netdev.google.com
             allocationMode: All
   

2. Aplique o manifesto:

   kubectl apply -f all-netdev-template.yaml
   

3. Implemente a sua carga de trabalho e consulte o ResourceClaimTemplate. O manifesto seguinte implementa um pod que usa o modelo all-netdev para conceder ao pod acesso a todos os dispositivos de rede não RDMA no nó. Guarde o manifesto como netdev-pod.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: agnhost-netdev
     namespace: default
     labels:
       app: agnhost
   spec:
     containers:
     - name: agnhost
       image: registry.k8s.io/e2e-test-images/agnhost:2.39
       args: ["netexec", "--http-port", "80"]
       ports:
       - name: agnhost-port
         containerPort: 80
       resources:
         claims:
         - name: netdev
         limits:
           google.com/tpu: 4
     nodeSelector:
       cloud.google.com/gke-tpu-accelerator: TPU_ACCELERATOR
       cloud.google.com/gke-tpu-topology: TPU_TOPOLOGY
     resourceClaims:
     - name: netdev
       resourceClaimTemplateName: all-netdev
   

   Substitua o seguinte:

   • TPU_ACCELERATOR: o tipo de acelerador de TPU, por exemplo, tpu-v5p-slice.
   • TPU_TOPOLOGY: a topologia da TPU, por exemplo, 2x4x4.

4. Aplique o manifesto:

   kubectl apply -f netdev-pod.yaml
   

5. Verifique se as interfaces de rede adicionais atribuídas estão visíveis no Pod.

   kubectl exec agnhost-netdev -- ls /sys/class/net
   

   O exemplo de saída seguinte mostra as interfaces eth0 e lo predefinidas, juntamente com os dispositivos de rede atribuídos, que têm nomes como eth1 e eth2. O número de NICs e os respetivos nomes variam consoante o tipo de máquina do nó do GKE.

   eth0
   eth1
   eth2
   lo
   

Peça um número específico de dispositivos de rede

Os exemplos anteriores mostram como pedir todos os dispositivos de rede disponíveis de um determinado tipo definindo allocationMode como All. Se, em alternativa, precisar de pedir um número específico de dispositivos, pode definir allocationMode como ExactCount na ResourceClaimTemplate.

O exemplo seguinte pede dois dispositivos de rede RDMA:

apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
  name: two-mrdma
spec:
  spec:
    devices:
      requests:
      - name: req-mrdma
        exactly:
          deviceClassName: mrdma.google.com
          allocationMode: ExactCount
          count: 2

O que se segue?

• Saiba mais acerca da atribuição dinâmica de recursos.
• Saiba como configurar a rede automatizada para VMs com acelerador.