Projetar para capacidade de obtenção de recursos no GKE com o Gemini

Este documento explica como projetar clusters resilientes do Google Kubernetes Engine (GKE) e estratégias de programação de cargas de trabalho que ajudam a conseguir recursos, como GPUs, TPUs e CPUs de alta performance. Ao aproveitar o Gemini em Cloud de Confiance by S3NS e o Compute Advisor (visualização), é possível evitar pods pendentes e melhorar a programação confiável para cargas de trabalho de IA.

Este documento é destinado a arquitetos de nuvem e administradores e operadores de plataforma que gerenciam a infraestrutura do GKE e querem otimizar o planejamento e a programação da capacidade.

Visão geral da disponibilidade de recursos no GKE

A programação do Kubernetes depende de solicitações de recursos declaradas. Ao programar aceleradores de grande escala, como GPUs ou TPUs, solicitações de recursos rigorosas podem fazer com que os clusters não escalonar verticalmente se um hardware específico não estiver disponível. É possível otimizar a disponibilidade de capacidade no GKE usando os seguintes recursos:

  • Criação automática de pools de nós:criação dinâmica de pool de nós de várias famílias.
  • Fallbacks no nível da carga de trabalho:tolerâncias e seletores de nós configurados para aceitar hardware alternativo.
  • Programação geográfica e regional:recursos multizonal e multirregional do GKE.
  • Gerenciamento de reservas:consumir a capacidade pré-comprada antes de solicitar recursos sob demanda.

Práticas recomendadas para disponibilidade de recursos no GKE

Esta seção fornece recomendações para aumentar a disponibilidade de capacidade ao programar cargas de trabalho no GKE. Essas práticas recomendadas abrangem estratégias como a criação de requisitos de hardware flexíveis, a configuração da criação automática de pools de nós e o aproveitamento da distribuição geográfica para se adaptar às restrições de recursos. A criação automática de pools de nós gerencia automaticamente os pools de nós com base nas especificações do pod. Em vez de pré-definir pools de nós, especifique os requisitos de recursos nos manifestos do pod e deixe que o GKE crie nós dinamicamente.

Também é possível descobrir e implementar as práticas recomendadas a seguir usando o Compute Advisor. Para mais informações, consulte Usar o Compute Advisor.

Opções de flexibilidade de hardware

Para otimizar a disponibilidade de capacidade, é possível instruir o GKE a evitar a vinculação de cargas de trabalho a uma única família de máquinas estáticas ou tipo de acelerador. Confira a seguir exemplos de como configurar pools de nós flexíveis e regras de afinidade de pods para diferentes classes de carga de trabalho. As alternativas específicas escolhidas dependem das demandas de recursos do aplicativo:

  • Pools de nós de CPU de uso geral:

    • Exemplo principal:N2 (uso geral baseado em Intel).
    • Exemplos de alternativas:N2D (AMD EPYC), C2 ou C2D (otimizado para computação) ou E2 (otimizado para custos).
    • Padrão de implementação: configure as especificações do pod com afinidade de nós ou tolerâncias que permitam a programação em vários rótulos de família de máquinas, por exemplo, cloud.google.com/machine-family em ["n2", "n2d", "c2d"]. Essa configuração permite que o GKE provisione qualquer pool que tenha capacidade disponível.
  • Pools de nós da GPU:

    • Exemplo principal:série A2 (GPUs NVIDIA A100).
    • Exemplos de alternativas:L4 (IA/ML universal) ou T4 (inferência).
    • Padrão de implementação:configure pools de nós separados ou ComputeClasses para diferentes níveis de GPU. Para cargas de trabalho que podem ser executadas sem recursos específicos da A100, permita que os pods façam fallback para pools L4 ou T4 se o provisionamento da A2 estiver restrito.
  • Pools de nós da TPU:

    • Exemplo principal:TPU Ironwood (TPU7x).
    • Exemplos de alternativas:TPU v6 (Trillium) ou TPU v5 (v5e ou v5p).
    • Padrão de implementação:o provisionamento de fatias de TPU pode ser altamente restrito. Projete cargas de trabalho de treinamento com flexibilidade no nível do framework (por exemplo, configurações JAX ou PyTorch que oferecem suporte a topologias de fatias variáveis) para implantação em fatias v6 ou v5 quando a capacidade da TPU Ironwood (TPU7x) não estiver disponível.

A tabela a seguir resume as seleções principais e as alternativas de hardware para diferentes tipos de cargas de trabalho:

Tipo de carga de trabalho Exemplo de seleção principal Exemplos de alternativas Considerações arquitetônicas
Cargas de trabalho do sistema ou principais N2 N2D, C2D, E2 Abrange pools de hardware Intel e AMD para criação automática de pool de nós.
Inferência e processamento de GPU A2 (A100) L4, T4 Segmenta de forma flexível pools de nós de GPU de custo mais baixo ou maior disponibilidade.
Treinamento de modelo de TPU TPU Ironwood (TPU7x) TPU v6, TPU v5 (v5e ou v5p) Utiliza topologias flexíveis para programação baseada em fatias.

Implementar a criação automática de pool de nós e ComputeClasses

Para otimizar a disponibilidade de capacidade, combine a criação automática de pool de nós com ComputeClasses. A lista a seguir inclui práticas recomendadas:

  • Definir ComputeClasses:crie recursos ComputeClass que especifiquem uma lista priorizada de famílias de máquinas, tipos de GPU ou modelos de provisionamento. O GKE tenta provisionar nós usando a configuração de maior prioridade disponível na classe. Uma lista de fallback priorizada ajuda significativamente a conseguir os recursos necessários para suas cargas de trabalho. Por exemplo, para evitar que o GKE faça fallback para máquinas de uso geral quando um acelerador especializado preferencial não estiver disponível, adicione a configuração whenUnsatisfiable: DoNotScaleUp à configuração do ComputeClass. Para mais informações, consulte Controlar atributos de nós com escalonamento automático usando ComputeClasses personalizadas.

  • Referenciar ComputeClasses nas especificações do pod:nas especificações do pod da carga de trabalho, use o rótulo cloud.google.com/compute-class para segmentar sua ComputeClass personalizada em vez de uma família de máquinas ou tipo de GPU específico. Para mais informações, consulte Solicitar uma ComputeClass em uma carga de trabalho.

  • Definir várias tolerâncias: se você não usar ComputeClasses, use regras de afinidade de nós nas especificações do pod que permitam um intervalo de famílias de máquinas (como cloud.google.com/machine-family em ["n2", "n2d"]). Para mais informações, consulte Configurar a criação automática de pool de nós de nós.

Flexibilidade geográfica e multirregional no GKE

Para aumentar a disponibilidade de capacidade, implante clusters do GKE que abrangem várias zonas ou execute arquiteturas de vários clusters:

  • Clusters multizonais:verifique se os pools de nós estão configurados para escalonamento automático em todas as zonas disponíveis em uma região.

  • Federação de clusters multirregionais:para jobs assíncronos grandes (como inferência em lote off-line ou treinamento distribuído), implante um orquestrador de vários clusters (como Kueue ou Cluster Director) para enfileirar cargas de trabalho globalmente e enviá-las para uma região com capacidade disponível.

  • Pods em execução em VMs do Spot:execute cargas de trabalho interrompíveis em VMs do Spot adicionando tolerâncias e instruindo o GKE a distribuir a capacidade excedente em diferentes zonas.

Outras práticas recomendadas para disponibilidade do GKE

Além da diversificação de hardware, incorpore estas práticas recomendadas do GKE para otimizar o sucesso do escalonamento de clusters:

  • Implementar o provisionamento excessivo de pods (buffers de capacidade) : implante pods de "pausa" de baixa prioridade que reservam a capacidade do nó com antecedência. Quando cargas de trabalho de IA de alta prioridade são enviadas e a capacidade regional é restrita, o Kubernetes imediatamente interrompe os pods de pausa, permitindo que os contêineres sejam iniciados sem esperar pelo provisionamento de novos nós. Para mais informações, consulte Sobre buffers de capacidade.
  • Usar o início flexível com provisionamento enfileirado:para grandes jobs treinamento de modelo de IA e em lote, use o início flexível com provisionamento enfileirado, que se integra ao Kueue e ao Programador dinâmico de cargas de trabalho. O início flexível com provisionamento enfileirado oferece alocação de nós atômica completa, o que evita falhas parciais de escalonamento de clusters. Para mais informações, consulte Executar uma carga de trabalho de grande escala com início flexível com provisionamento enfileirado.
  • Ativar o streaming de imagens e o pré-carregamento de imagens de contêiner:para imagens de contêiner de IA grandes (como imagens do PyTorch ou TensorFlow que excedam 10 GB), ative o streaming de imagens do GKE ou use discos de inicialização secundários para pré-carregamento de imagens. Essa configuração reduz o tempo de aquecimento do nó, o que permite que os nós recém-provisionados comecem a executar cargas de trabalho em segundos. Para mais informações, consulte Usar o streaming de imagens para extrair imagens de contêiner e Usar discos de inicialização secundários para pré-carregar dados ou imagens de contêiner.
  • Definir a política de localização do escalonador automático de cluster como ANY: configure pools de nós (especialmente para VMs do Spot ou início flexível) com a ANY política de localização. Essa configuração instrui o escalonador automático de cluster a pesquisar a capacidade solicitada em todas as zonas especificadas. O escalonador automático de cluster encontra capacidade ao equilibrar as contagens de nós. Para mais informações, consulte Visão geral do escalonador automático de cluster.
  • Otimizar a utilização do acelerador com o compartilhamento de GPU:para cargas de trabalho que não exigem uma GPU dedicada, use o compartilhamento de tempo de GPU, GPUs de várias instâncias (MIG) ou NVIDIA MPS para permitir que vários contêineres compartilhem um único acelerador. Essa abordagem otimiza a capacidade efetiva em pools de nós. Para mais informações, consulte Sobre estratégias de compartilhamento de GPU no GKE.

Usar o Compute Advisor

O Compute Advisor é uma interface com tecnologia de IA no Cloud de Confiance console, com tecnologia do Gemini, que ajuda a projetar arquiteturas resilientes para o GKE. O Compute Advisor fornece orientações de disponibilidade de VMs do Spot e de início flexível quase em tempo real, além de verificar as políticas da organização e as cotas de recursos antes da implantação. O Compute Advisor não fornece orientações de disponibilidade para cargas de trabalho que exigem recursos sob demanda.

Para acessar o Gemini no Cloud de Confiance console, siga as seguintes etapas:

  1. No Cloud de Confiance console, acesse a página Visão geral.

    Ir para Visão geral

  2. Na seção Projete sua infraestrutura com o Compute Advisor, envie um comando. O Gemini começa a gerar uma resposta.

  3. Para gerar recomendações arquitetônicas, execute um dos comandos de exemplo a seguir no Compute Advisor. Ao clicar nos botões Executar comando no Compute Advisor, o Cloud de Confiance console pode levar mais de 15 segundos para carregar:

    • Estratégia geral de acelerador:

      Caso de uso:use esse comando para analisar os indicadores de capacidade regional e receber recomendações sobre tipos de máquinas, zonas e estratégias de programação de fallback ao criar configurações de cluster.

      Configure a GKE cluster to improve chances of obtaining scarce GPU or TPU capacity.
      

      Executar comando no Compute Advisor

    • Flexibilidade geográfica e fallbacks:

      Caso de uso:use esse comando ao criar arquiteturas de vários clusters ou sistemas globais de enfileiramento de jobs (por exemplo, com o Kueue) para mudar a execução da carga de trabalho entre regiões, dependendo da disponibilidade de recursos.

      Configure multi-region fallbacks and geographic scheduling on GKE to increase GPU availability.
      

      Executar comando no Compute Advisor

    • Consumo de reserva de prioridade:

      Caso de uso:use esse comando para gerar padrões de configuração YAML para afinidade de pods e regras de escalonamento automático que priorizam a capacidade de reserva.

      Configure GKE autoscaling rules and Pod specs to prioritize consuming active reservations before scaling into on-demand pools.
      

      Executar comando no Compute Advisor

    • ComputeClasses para priorização de fallback:

      Caso de uso:use esse comando para gerar o manifesto YAML de uma ComputeClass CustomResourceDefinition que prioriza GPUs de alta performance, mas inclui fallbacks de nível inferior para garantir a programação da carga de trabalho.

      Define a ComputeClass manifest for GKE to prioritize A2 GPU nodes with automatic fallbacks to L4 or T4 GPUs.
      

      Executar comando no Compute Advisor

    • Criação automática de pools de nós para diversificação:

      Caso de uso:use esse comando para gravar o manifesto YAML dos limites de recursos do escalonador automático de cluster do GKE e regras de afinidade de pods que permitem que o NAP provisione nós de GPU ou CPU alternativos automaticamente.

      Configure GKE node pool auto-creation to diversify machine families and prevent pending pods when regional accelerator capacity is constrained.
      

      Executar comando no Compute Advisor

A seguir