Sobre a alocação dinâmica de recursos no GKE

Nesta página, você encontra informações sobre a alocação dinâmica de recursos (DRA) no Google Kubernetes Engine (GKE). Nesta página, você vai aprender os fundamentos da DRA, como ela funciona no GKE e os benefícios de usar a DRA para alocar hardware, como GPUs e TPUs.

Esta página é destinada às seguintes funções:

Antes de ler esta página, confira se você conhece os seguintes recursos:

Introdução ao DRA

O DRA é um recurso integrado do Kubernetes que permite solicitar, alocar e compartilhar hardware de maneira flexível no cluster entre pods e contêineres. A DRA melhora a experiência de alocação de hardware conectado, como aceleradores, permitindo que fornecedores de dispositivos e administradores de plataforma declarem classes de dispositivos que podem ser solicitados e alocados. Os operadores de apps podem pedir configurações específicas de dispositivos dentro dessas classes e solicitar essas configurações nas cargas de trabalho. O Kubernetes e o GKE gerenciam o agendamento de pods, as atribuições de nós e a alocação de dispositivos com base nas solicitações de carga de trabalho.

Por exemplo, um administrador da plataforma pode definir uma classe de dispositivo que tenha apenas GPUs NVIDIA A100. Em seguida, os operadores de apps podem filtrar os dispositivos nessa classe com base nos requisitos de carga de trabalho, como um mínimo de 80 GB de memória da GPU. Quando o operador do app implanta uma carga de trabalho que solicita a configuração filtrada, o GKE coloca os pods em nós que atendem aos critérios selecionados. Neste exemplo, o GKE encontra nós com GPUs A100 (80 GB) disponíveis. O operador do app não precisa selecionar nós ou configurações de dispositivo específicos no manifesto da carga de trabalho.

Benefícios da DRA

Sem o DRA, a alocação de dispositivos de hardware no Kubernetes depende de plug-ins de dispositivo. Para anexar recursos de hardware a pods usando plug-ins de dispositivo, use rótulos de nó para colocar pods em nós específicos. Além disso, para dedicar todos os recursos de um nó a um único pod, solicite o número exato de dispositivos conectados aos nós.

Com a DRA, a experiência de alocar dispositivos para pods é semelhante à alocação de volumes para armazenamento. Você define classes de dispositivos, solicita dispositivos dentro dessas classes e atribui os dispositivos solicitados a cargas de trabalho. O DRA oferece uma superfície muito mais extensível para filtrar dispositivos com base na carga de trabalho e nas necessidades comerciais. A abordagem da DRA de usar expressões e modelos para reivindicar hardware e programar pods tem os seguintes benefícios:

  • Alocação declarativa de dispositivos: os administradores da plataforma podem definir configurações de dispositivos para tipos específicos de cargas de trabalho ou equipes.
  • Complexidade reduzida entre equipes: quando os administradores da plataforma provisionam nós com configurações de hardware especializadas, os operadores de apps não precisam saber quais nós têm configurações específicas. Os administradores da plataforma não precisam rotular nós nem comunicar informações sobre nós e dispositivos específicos aos operadores.
  • Complexidade reduzida para desenvolvedores: o Kubernetes programa pods com base na configuração do dispositivo referenciado. Os operadores de apps não precisam selecionar nós específicos nas cargas de trabalho nem garantir que cada pod solicite exatamente o número de dispositivos conectados a esses nós.
  • Gerenciamento centralizado da infraestrutura: os administradores da plataforma podem definir de maneira centralizada configurações de hardware que atendam a requisitos comerciais específicos. Por exemplo, um administrador de plataforma pode declarar uma configuração de alto desempenho com GPUs H100 e uma configuração de inferência pequena com GPUs Tesla T4.
  • Seleção flexível de hardware: a DRA permite usar expressões CEL para filtrar dispositivos com atributos específicos. Usar expressões oferece a flexibilidade de filtrar dispositivos ideais para cargas de trabalho específicas.

Quando usar o DRA

Durante o pré-lançamento, o principal motivo para usar o DRA no GKE é a flexibilidade com que você pode solicitar dispositivos para cargas de trabalho. É possível escrever um manifesto uma vez e implantar a carga de trabalho em diferentes clusters com tipos de dispositivos diferentes sem precisar mudar o manifesto. Essa flexibilidade é ideal para casos de uso como os seguintes:

  • Melhorar a disponibilidade de GPU: para cargas de trabalho que precisam de acesso ao hardware de GPU, use o DRA para solicitar qualquer GPU disponível no cluster em vez de especificar um modelo. Se essas cargas de trabalho tiverem requisitos específicos de memória de GPU (VRAM), você poderá solicitar qualquer GPU no cluster que tenha uma quantidade mínima de memória. Esse tipo de solicitação flexível expande o conjunto de nós de GPU em que uma carga de trabalho pode ser executada, o que reduz o risco de a carga de trabalho não ser programada devido a recursos indisponíveis.
  • Otimizar a disponibilidade de nós de GPU durante o escalonamento: o número de GPUs anexadas que uma carga de trabalho exige pode mudar dependendo do tipo de GPU. Você pode usar uma classe de computação do GKE para provisionar nós com base na disponibilidade, cota ou reservas de capacidade de GPU. Em seguida, use a DRA nas cargas de trabalho para configurar os pods para serem executados em qualquer nó que o GKE provisionar para a classe de computação. Usar o DRA com classes de computação permite minimizar o risco de cargas de trabalho não programadas e garantir que elas sejam executadas em hardware otimizado.

Terminologia

O Kubernetes de código aberto e os provedores de Kubernetes gerenciados, como o GKE, usam os seguintes termos de DRA:

ResourceSlice
Um ResourceSlice lista um ou mais dispositivos de hardware no cluster que os nós podem acessar. Por exemplo, em um nó que pode acessar uma única GPU, o ResourceSlice lista a GPU e o nome do nó. Os drivers de dispositivo DRA em cada nó criam ResourceSlices. O programador do Kubernetes usa ResourceSlices para decidir quais dispositivos alocar para atender às solicitações de carga de trabalho.
DeviceClass
Uma DeviceClass define uma categoria de dispositivos, como GPUs, que estão disponíveis para solicitação de cargas de trabalho. Alguns drivers de dispositivo fornecem DeviceClasses integradas, como a gpu.nvidia.com DeviceClass para GPUs NVIDIA. Os administradores da plataforma também podem criar DeviceClasses personalizados que definem configurações específicas de dispositivos.
ResourceClaim

Um ResourceClaim permite que um pod ou um usuário solicite recursos de hardware filtrando determinados parâmetros em uma DeviceClass. Quando uma carga de trabalho faz referência a um ResourceClaim, o Kubernetes atribui dispositivos que correspondem aos parâmetros especificados a esse ResourceClaim.

Por exemplo, considere um cenário em que você cria um ResourceClaim para uma GPU A100 (40 GB) e implanta uma carga de trabalho que seleciona esse ResourceClaim. O Kubernetes atribui uma GPU A100 (40 GB) disponível ao ResourceClaim e programa o pod em um nó que pode acessar essa GPU.

ResourceClaimTemplate

Um ResourceClaimTemplate define um modelo que os pods podem usar para criar automaticamente novos ResourceClaims por pod. Os ResourceClaimTemplates são úteis quando você tem várias cargas de trabalho que precisam de acesso a configurações de dispositivos semelhantes, especialmente ao usar um controlador de carga de trabalho, como implantações ou StatefulSets.

Os operadores de apps implantam ResourceClaimTemplates e referenciam os modelos em cargas de trabalho. O Kubernetes cria ResourceClaims para cada pod com base no modelo especificado, aloca dispositivos e programa os pods. Quando os pods são encerrados, o Kubernetes limpa os ResourceClaims correspondentes.

Como a DRA funciona

Usar o DRA em clusters e cargas de trabalho é semelhante a usar StorageClasses, PersistentVolumeClaims e PersistentVolumes para provisionar volumes dinamicamente para pods.

O diagrama a seguir mostra as etapas que os administradores de cluster e os operadores de apps seguem para alocar dispositivos usando o DRA:

Neste diagrama, os administradores de cluster e os operadores de apps fazem o seguinte:

  1. Os administradores de cluster instalam drivers de dispositivo compatíveis com DRA nos nós.
  2. Os administradores de cluster criam DeviceClasses que filtram hardware que atende a requisitos específicos, como todas as GPUs com mais de 40 GB de memória. Alguns dispositivos também podem incluir DeviceClasses integrados.
  3. Os operadores de aplicativos criam ResourceClaimTemplates ou ResourceClaims que solicitam configurações de dispositivo. O principal caso de uso de cada tipo de reivindicação é o seguinte:
    • Um ResourceClaim permite que vários pods compartilhem o acesso ao mesmo dispositivo.
    • Um ResourceClaimTemplate permite que vários pods acessem dispositivos separados e semelhantes gerando automaticamente ResourceClaims por pod.
  4. Os operadores de aplicativos adicionam os ResourceClaimTemplates ou ResourceClaims aos manifestos de carga de trabalho.
  5. Os operadores de aplicativos implantam a carga de trabalho.

Quando você implanta uma carga de trabalho que faz referência a um ResourceClaimTemplate ou a um ResourceClaim, o Kubernetes executa as seguintes etapas de programação:

  1. Se a carga de trabalho fizer referência a um ResourceClaimTemplate, o Kubernetes vai criar um novo objeto ResourceClaim para cada instância da carga de trabalho (por exemplo, cada réplica em uma implantação).
  2. O programador do Kubernetes usa os ResourceSlices no cluster para alocar dispositivos disponíveis e qualificados para o ResourceClaim de cada pod.
  3. O programador coloca cada pod em um nó que tem acesso aos dispositivos alocados ao ResourceClaim do pod.
  4. O kubelet no nó de destino chama o driver DRA no nó para anexar o hardware alocado ao pod e atender à solicitação de recursos.

Quando usar ResourceClaims e ResourceClaimTemplates

Com ResourceClaims e ResourceClaimTemplates, você pode indicar ao Kubernetes que quer dispositivos que atendam a requisitos específicos. Quando um ResourceClaim é referenciado em um pod, o Kubernetes aloca dispositivos ao recurso da API ResourceClaim correspondente no servidor da API Kubernetes. Essa alocação acontece independente de você ter criado o ResourceClaim ou de o Kubernetes ter criado o ResourceClaim de um ResourceClaimTemplate.

Se você criar um ResourceClaim e referenciá-lo em vários pods, todos eles poderão acessar os dispositivos que o Kubernetes aloca para esse ResourceClaim. Por exemplo, esse acesso compartilhado pode acontecer se você fizer referência a um ResourceClaim específico em um manifesto de implantação com várias réplicas. No entanto, se os dispositivos alocados não estiverem configurados para serem compartilhados por vários processos, esse acesso compartilhado a dispositivos em pods poderá resultar em comportamento não intencional.

Um ResourceClaimTemplate permite definir modelos que o Kubernetes usa para criar automaticamente ResourceClaims individuais para pods. Por exemplo, se você referenciar um ResourceClaimTemplate em uma implantação com várias réplicas, o Kubernetes vai criar um ResourceClaim separado para cada pod replicado. Como resultado, cada pod recebe um dispositivo alocado em vez de compartilhar o acesso com outros pods. Esses ResourceClaims gerados automaticamente são vinculados ao ciclo de vida do pod correspondente e são excluídos quando o pod é encerrado. Se você tiver pods independentes que precisam de acesso a configurações de dispositivo semelhantes, use um ResourceClaimTemplate para alocar dispositivos a cada pod separadamente.

A tabela a seguir descreve algumas diferenças entre a criação manual de ResourceClaims e a permissão para que o Kubernetes crie ResourceClaims com um ResourceClaimTemplate:

ResourceClaims criados manualmente ResourceClaims criados automaticamente
Gerenciado por você Gerenciadas pelo Kubernetes
Fornece acesso aos mesmos dispositivos de vários pods Fornece acesso a dispositivos de um único pod
Existe no cluster independentemente dos pods Vinculado ao ciclo de vida do pod correspondente
Ideal para várias cargas de trabalho que precisam compartilhar um dispositivo específico Ideal para várias cargas de trabalho que precisam de acesso independente ao dispositivo

Comparação da DRA com a alocação manual de dispositivos

Com o DRA, a alocação de dispositivos conectados é uma experiência semelhante ao provisionamento dinâmico de PersistentVolumes. O Kubernetes também permite alocar dispositivos usando plug-ins de dispositivo. Esse método envolve as seguintes etapas:

  1. Um administrador de cluster cria nós com dispositivos conectados, como GPUs.
  2. O administrador do cluster comunica informações sobre nós específicos e dispositivos conectados a operadores de carga de trabalho.
  3. Um operador de carga de trabalho solicita dispositivos no manifesto da carga de trabalho da seguinte maneira:
    • Selecione um nó com a configuração de dispositivo necessária, como o modelo de GPU ou o tipo e a topologia de TPU, usando um campo nodeSelector.
    • Especifique o número exato de dispositivos para os contêineres consumirem usando o campo resources na especificação do pod.

Esse método de alocação manual exige que os operadores de aplicativos e os administradores de cluster se comuniquem sobre quais nós ou pools de nós específicos têm determinadas configurações de dispositivo. Eles precisam coordenar as solicitações de carga de trabalho para corresponder aos dispositivos nos nós, ou a implantação vai falhar. Em comparação, o DRA permite usar expressões para filtrar dispositivos de maneira flexível com base em atributos e não exige que os operadores de carga de trabalho conheçam a configuração exata dos nós no cluster.

A tabela a seguir compara o DRA com plug-ins de dispositivo:

DRA Alocação manual
Seleção flexível de dispositivos usando expressões CEL Seleção específica de nós usando seletores e solicitações de recursos
Decisões de programação tomadas pelo Kubernetes Decisões de programação tomadas pelo operador usando seletores de nós
A filtragem de dispositivos é separada da criação de cargas de trabalho A filtragem de dispositivos precisa ser feita no manifesto da carga de trabalho
Filtragem centralizada de dispositivos e aulas com base nas necessidades, gerenciadas por administradores da plataforma Filtragem de dispositivos isolados por operadores de aplicativos
Os operadores de apps não precisam saber a capacidade do nó, as informações de rótulo do nó ou os modelos de dispositivos anexados para cada nó. Os operadores de apps precisam saber quais nós têm modelos e quantidades específicas de determinados dispositivos conectados.

Dispositivos do GKE compatíveis com o DRA

É possível usar o DRA para alocar GPUs ou TPUs a cargas de trabalho do GKE. Você pode alocar qualquer um dos modelos de GPU e TPU compatíveis com o GKE. Para detalhes sobre as GPUs e TPUs compatíveis com o GKE, consulte os recursos a seguir:

Limitações do DRA no GKE

A DRA tem as seguintes limitações em clusters do GKE:

  • Não é possível usar a DRA com o provisionamento automático de nós.
  • Não é possível usar a DRA com os seguintes recursos de compartilhamento de GPU:
    • GPUs compartilhadas por tempo.
    • GPUs com várias instâncias.
    • Serviço multiprocesso (MPS).
  • Não é possível usar o DRA em clusters do Autopilot.
  • Use o GKE versão 1.32.1-gke.1489001 ou posterior.

Esta seção fornece recomendações para administradores de plataforma ou operadores de apps que querem usar o DRA para alocar dispositivos a cargas de trabalho. A DRA muda significativamente o método de solicitação de dispositivos conectados, tanto no GKE quanto no Kubernetes. Para aproveitar casos de uso mais avançados, como fallback entre dispositivos ou filtragem e seleção refinadas de dispositivos, siga estas orientações:

Melhorar a disponibilidade de nós durante o escalonamento

Com as ComputeClasses no GKE, é possível definir um comportamento de fallback baseado em prioridade que o GKE segue ao criar novos nós em clusters. Você pode usar ComputeClasses para configurar uma série priorizada de configurações de nó e dispositivo que o GKE usa ao criar nós para executar cargas de trabalho. Em seguida, use o DRA para garantir que sua carga de trabalho possa ser executada em qualquer nó na ComputeClass sem precisar selecionar nós manualmente por rótulo.

Por exemplo, uma carga de trabalho pode precisar de duas GPUs NVIDIA L4 ou uma GPU NVIDIA A100 (40 GB) para ser executada de maneira ideal. Você pode criar uma ComputeClass que prioriza a criação de nós com uma GPU A100 (40 GB), mas pode voltar a criar nós com duas GPUs L4 por nó. Em seguida, use o DRA para solicitar qualquer GPU disponível para sua carga de trabalho. Quando você implanta a carga de trabalho e seleciona essa ComputeClass, o GKE cria nós com uma das configurações de GPU especificadas. Com o DRA, o GKE pode colocar a carga de trabalho no primeiro nó disponível, independente do modelo de GPU, do rótulo do nó ou da contagem de GPUs.

Para saber mais, leia as seguintes páginas:

A seguir