Alocar recursos de rede usando o DRANET gerenciado pelo GKE

Standard

Pré-lançamento

Este recurso está sujeito aos "Termos da Oferta Pré-GA" na seção Termos Gerais de Serviço dos Termos Específicos de Serviço. Os recursos pré-GA estão disponíveis no estado em que se encontram e podem ter assistência limitada. Para mais informações, consulte as descrições das fases de lançamento.

O DRANET do Google Kubernetes Engine (GKE) é um recurso gerenciado do GKE que se baseia no projeto DRANET de código aberto (em inglês), que implementa a API DRA do Kubernetes para recursos de rede. Com o DRANET, é possível solicitar e alocar recursos de rede de alta performance para seus pods, incluindo interfaces de rede que oferecem suporte ao acesso direto à memória remota (RDMA, na sigla em inglês). Essa abordagem fornece uma API portátil e alinhada ao upstream para gerenciamento de recursos de rede.

Este documento oferece uma visão geral conceitual do GKE DRANET e mostra como alocar recursos de rede para cargas de trabalho nos clusters do GKE.

Este documento é destinado a arquitetos de nuvem e especialistas em Rede que projetam redes para as organizações. Para uma visão geral de toda a documentação do GKE, consulte Conheça a documentação do GKE. Para saber mais sobre papéis e tarefas comuns referenciados no conteúdo do Google Cloud , consulte Funções e tarefas de usuário comuns do GKE.

Antes de ler este documento, confira se você conhece os seguintes tópicos:

• Alocação dinâmica de recursos
• Sobre a alocação dinâmica de recursos no GKE
• Conceitos do Kubernetes
• Rede do GKE
• Princípios básicos de rede do GKE

Como funciona o DRANET gerenciado do GKE

O DRANET gerenciado pelo GKE é implementado por um DaemonSet networking-dra-driver. Esse DaemonSet é executado em nós com GPUs ou TPUs que têm o GKE DRANET ativado. Ele funciona como um agente no nível do nó para tornar as interfaces de rede detectáveis e alocáveis a pods pelas APIs de alocação dinâmica de recursos (DRA, na sigla em inglês) do Kubernetes.

Nas versões 1.34.1-gke.1829001 e mais recentes do GKE, o GKE instala automaticamente recursos DeviceClass para rede. Essas classes definem os tipos de dispositivos de rede que podem ser solicitados. 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 driver do GKE DRANET em um pool de nós com GPUs ou TPUs.

Para solicitar dispositivos de rede para uma carga de trabalho, defina um ResourceClaimTemplate. Esse modelo especifica o DeviceClass e o modo de alocação, como solicitar todos os dispositivos disponíveis em um nó. Na especificação do pod, faça referência a esse modelo em um campo resourceClaims para conceder ao pod acesso às interfaces de rede solicitadas no nó.

Quando usar o DRANET gerenciado pelo GKE

O GKE DRANET oferece uma maneira padronizada de gerenciar recursos de rede que conhecem a topologia e as dependências. Essa padronização a torna uma solução adequada para cargas de trabalho de IA e ML que exigem redes de alto desempenho.

Os casos de uso comuns para solicitar interfaces de rede para um pod incluem:

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

Principais considerações ao usar o DRANET gerenciado pelo GKE para rede

Considere os seguintes pontos ao usar o GKE DRANET para rede:

• Interfaces de rede dedicadas

  Quando você 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 compartilhá-lo. Isso garante que o pod tenha acesso exclusivo à largura de banda e aos recursos completos dessa interface, o que é um benefício fundamental para cargas de trabalho sensíveis à performance.

• Usar o driver DRANET gerenciado do GKE de forma independente

  É possível ativar o driver DRA do GKE para gerenciar recursos de rede sem ativar outros drivers DRANET do GKE. Para fazer isso, adicione o rótulo cloud.google.com/gke-networking-dra-driver=true a um pool de nós com GPUs e TPUs.

• Usar outros drivers de DRA do GKE

  Para alcançar maior capacidade de processamento em cargas de trabalho exigentes de IA/ML, combine a API DRA para aceleradores (como GPUs e TPUs) com a rede gerenciada DRANET do GKE. Essa abordagem combinada melhora o alinhamento de recursos e a percepção da topologia. Para orientações sobre como usar o DRA com outros recursos, consulte Preparar a infraestrutura do GKE para cargas de trabalho do DRA.

• Evite configurações conflitantes

  O driver DRANET do GKE gerencia interfaces RDMA e gVNICs que não têm intervalos de endereços IP secundários configurados. Não use o driver DRANET do GKE e a API de várias redes do GKE com um recurso de rede do tipo Device no mesmo cluster. Não é possível usar o driver e a API juntos porque ambos tentam gerenciar o mesmo conjunto de NICs, o que pode levar a uma configuração incorreta e um comportamento imprevisível.

Requisitos

Para usar o DRANET gerenciado do GKE, seu ambiente precisa atender aos seguintes requisitos:

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

Limitações

O GKE DRANET tem as seguintes limitações:

• Não é possível usar o GKE DRANET para alocar a placa de interface de rede (NIC) padrão ou NICs virtuais (como veth).
• O escalonamento automático de cluster e o Autopilot não são compatíveis.
• Não é possível usar o GKE DRANET com interfaces em que você configurou um secondaryPodRange.

Antes de começar

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

• Ativar a API Google Kubernetes Engine.
Ativar a API Google Kubernetes Engine
• Se você quiser usar a CLI do Google Cloud para essa tarefa, instale e inicialize a gcloud CLI. Se você instalou a gcloud CLI anteriormente, instale a versão mais recente executando o comando gcloud components update. Talvez as versões anteriores da gcloud CLI não sejam compatíveis com a execução dos comandos neste documento.
  Observação: em instalações prévias da gcloud CLI, defina a propriedade compute/region. Se você usa principalmente clusters zonais, defina compute/zone. Ao definir um local padrão, é possível evitar erros na gcloud CLI como: One of [--zone, --region] must be supplied: Please specify location. Talvez seja necessário especificar o local em determinados comandos se o local do cluster for diferente do padrão definido.

Funções exigidas

Para receber as permissões necessárias para criar pools de nós e alocar recursos de rede, peça ao administrador para conceder a você o papel do IAM de Administrador do Kubernetes Engine (roles/container.admin) no seu projeto. Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

Também é possível conseguir as permissões necessárias usando papéis personalizados ou outros papéis predefinidos.

Criar um cluster

Crie um cluster do GKE Standard que usa 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:

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

Usar interfaces RDMA de um pool de nós de GPU

As seções a seguir descrevem como configurar um pool de nós e uma carga de trabalho de GPU para usar interfaces de rede RDMA com o GKE DRANET.

Ativar o driver DRANET gerenciado pelo GKE em um pool de nós de GPU

Para ativar o driver DRANET do GKE em um pool de nós de GPU que oferece suporte a RDMA, adicione o rótulo cloud.google.com/gke-networking-dra-driver=true ao criar o pool 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:

• NODE_POOL_NAME: o nome do novo pool de nós.
• REGION: a região Google Cloud do cluster.
• CLUSTER_NAME: o nome do cluster.

• ACCELERATOR_TYPE: o tipo de acelerador de GPU:

  Exemplo:

  • VMs A4: insira nvidia-b200.
  • VMs A3 ultra: insira nvidia-h200-141gb.

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

• DRIVER_VERSION: a versão do driver da GPU a ser usada. Por exemplo, default ou latest.

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

• NUM_NODES: o número de nós para o pool de nós. Para "flex-start", esse valor precisa ser definido como 0.

• RESERVATION_PROJECT: o ID do projeto da reserva.

• RESERVATION_NAME: o nome da sua reserva. Para encontrar esse valor, consulte Ver solicitações de reserva adiantadas.

• RESERVATION_BLOCK: o nome de um bloco específico dentro da reserva. Para encontrar esse valor, consulte Ver solicitações de reserva adiantadas.

Esse comando usa perfis de rede de aceleradores para configurar automaticamente redes e sub-redes VPC para suas VMs aceleradoras. Como alternativa, é possível especificar explicitamente sua rede VPC e sub-redes.

Implantar recursos de RDMA de carga de trabalho

Para alocar recursos de RDMA para um pod, especifique um ResourceClaimTemplate.

1. Crie um ResourceClaimTemplate para definir como alocar os dispositivos RDMA. O manifesto a seguir solicita todos os dispositivos mrdma disponíveis no nó. Salve 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. Implante a carga de trabalho e consulte o ResourceClaimTemplate. O manifesto a seguir implanta um pod que faz referência ao modelo all-mrdma, o que concede ao pod acesso às interfaces RDMA no nó. Salve 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 alocadas extras estão visíveis dentro do pod.

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

   O exemplo de saída a seguir mostra as interfaces eth0 e lo padrão, bem como as interfaces RDMA alocadas, como gpu0rdma0. O número e os nomes das interfaces de rede (NICs) variam de acordo com o tipo de máquina do nó do GKE.

   eth0
   gpu0rdma0
   gpu1rdma0
   gpu2rdma0
   gpu3rdma0
   lo
   

Usar interfaces de rede não RDMA em um pool de nós da TPU

As seções a seguir descrevem como configurar um pool de nós e uma carga de trabalho da TPU para usar interfaces de rede não RDMA com o GKE DRANET.

Verificar DeviceClasses de rede

Verifique se os recursos DeviceClass para rede existem no cluster.

kubectl get deviceclass netdev.google.com

O resultado será o seguinte:

NAME                AGE
netdev.google.com   2d22h

Ativar o driver DRANET gerenciado pelo GKE em um pool de nós de fração de TPU

Para ativar o driver DRANET do GKE ao criar um pool de nós de fração de TPU, adicione o rótulo 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:

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

Para mais informações, consulte Criar um pool de nós de fração de TPU de host único.

Implantar uma carga de trabalho reivindicando todos os dispositivos de rede

Para alocar dispositivos de rede não RDMA para um pod, especifique um ResourceClaimTemplate.

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

   Salve 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. Implante a carga de trabalho e consulte o ResourceClaimTemplate. O manifesto a seguir implanta um pod que usa o modelo all-netdev para conceder ao pod acesso a todos os dispositivos de rede não RDMA no nó. Salve 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:

   • 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 alocadas extras estão visíveis dentro do pod.

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

   O exemplo de saída a seguir mostra as interfaces padrão eth0 e lo, além dos dispositivos de rede alocados, que têm nomes como eth1 e eth2. O número de NICs e os nomes deles variam de acordo com o tipo de máquina do nó do GKE.

   eth0
   eth1
   eth2
   lo
   

Solicitar um número específico de dispositivos de rede

Os exemplos anteriores mostram como solicitar todos os dispositivos de rede disponíveis de um determinado tipo definindo allocationMode como All. Se você precisar solicitar um número específico de dispositivos, defina allocationMode como ExactCount no seu ResourceClaimTemplate.

O exemplo a seguir solicita 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

A seguir

• Saiba mais sobre a alocação dinâmica de recursos.
• Saiba mais sobre Configurar rede automatizada para VMs aceleradoras.