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, na sigla em inglês) 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 à DRA

O DRA é um recurso integrado do Kubernetes que permite solicitar, alocar e compartilhar hardware de forma flexível no cluster entre pods e contêineres. O DRA melhora a experiência de alocação de hardware conectado, como aceleradores, permitindo que os fornecedores de dispositivos e administradores de plataformas declarem classes de dispositivos que podem ser solicitados e alocados. Os operadores de apps podem pedir configurações de dispositivo específicas nessas classes e, em seguida, solicitar essas configurações nas cargas de trabalho. O Kubernetes e o GKE gerenciam a programação 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. Os operadores de apps podem filtrar os dispositivos nessa classe com base nos requisitos de carga de trabalho, como filtrar um mínimo de 80 GB de memória de 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 de 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 os recursos de um nó inteiro a um único pod, solicite o número exato de dispositivos conectados aos nós.

Com a DRA, a experiência de alocação de dispositivos para pods é semelhante à alocação de volumes para armazenamento. Você define classes de dispositivos, solicita dispositivos nessas classes e, em seguida, atribui os dispositivos solicitados às cargas de trabalho. A DRA oferece uma superfície muito mais extensível para filtrar dispositivos com base na carga de trabalho e nas necessidades da empresa. A abordagem de 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.
  • Redução da complexidade 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.
  • Redução da complexidade para os desenvolvedores: o Kubernetes programa pods com base na configuração de dispositivo referenciada. Os operadores de apps não precisam selecionar nós específicos nas cargas de trabalho e não precisam garantir que cada pod solicite exatamente o número de dispositivos conectados a esses nós.
  • Gerenciamento de infraestrutura centralizado: os administradores da plataforma podem definir centralmente configurações de hardware que atendam a requisitos específicos de negócios. Por exemplo, um administrador de plataforma pode declarar uma configuração de alto desempenho com GPUs H100 e uma pequena configuração de inferência com GPUs Tesla T4.
  • Seleção flexível de hardware: a DRA permite usar expressões CEL para filtrar dispositivos com atributos específicos. O uso de expressões oferece a flexibilidade de filtrar dispositivos ideais para cargas de trabalho específicas.

Quando usar a DRA

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

  • Melhorar a disponibilidade de GPU: para cargas de trabalho que precisam de acesso a hardware de GPU, use o DRA para solicitar qualquer GPU disponível no cluster em vez de especificar um modelo de GPU. 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 do nó de GPU durante a escalação: o número de GPUs conectadas que uma carga de trabalho exige pode mudar dependendo do tipo de GPU. É possível usar uma classe de computação do GKE para provisionar nós com base na disponibilidade de GPU, cota ou reservas de capacidade. Em seguida, use a DRA nas cargas de trabalho para configurar os pods para serem executados em qualquer nó provisionado pelo GKE para a classe de computação. O uso da DRA com classes de computação permite minimizar o risco de cargas de trabalho não programadas, além de garantir que elas sejam executadas em hardware otimizado.

Terminologia

Os provedores de Kubernetes gerenciados e de código aberto, 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 personalizadas que definem configurações específicas do dispositivo.
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 seu 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 dispositivo semelhantes, especialmente ao usar um controlador de carga de trabalho, como implantações ou StatefulSets.

Os operadores de apps implantam ResourceClaimTemplates e, em seguida, fazem referência aos modelos nas 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

O uso de DRA nos clusters e workloads é uma experiência semelhante ao uso de 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 app seguem para alocar dispositivos usando a DRA:

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

  1. Os administradores do cluster instalam drivers de dispositivo que oferecem suporte à DRA nos nós.
  2. Os administradores de cluster criam DeviceClasses que filtram hardware que atenda a requisitos específicos, como todas as GPUs com mais de 40 GB de memória. Alguns dispositivos também podem incluir DeviceClasses integradas.
  3. Os operadores de aplicativos criam ResourceClaimTemplates ou ResourceClaims que solicitam configurações do dispositivo. O caso de uso principal para cada tipo de reclamaçã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 referenciar 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 qualificados e disponíveis ao ResourceClaim de cada pod.
  3. O programador coloca cada pod em um nó que tenha 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 para atender à solicitação de recurso.

Quando usar ResourceClaims e ResourceClaimTemplates

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

Se você criar um ResourceClaim e o referenciar em vários pods, todos esses pods poderão acessar os dispositivos que o Kubernetes aloca para esse ResourceClaim. Por exemplo, esse acesso compartilhado pode acontecer se você referenciar 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 pode 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 o próprio dispositivo alocado em vez de compartilhar o acesso ao dispositivo com outros pods. Esses ResourceClaims gerados automaticamente são vinculados à duração 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 dispositivos 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 Recursos de reivindicação e a criação de Recursos de reivindicação pelo Kubernetes usando um modelo de Recurso de reivindicação:

ResourceClaims criados manualmente ResourceClaims criados automaticamente
Gerenciado por você Gerenciadas pelo Kubernetes
Oferece acesso aos mesmos dispositivos em vários pods Oferece 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

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

  1. Um administrador de cluster cria nós que têm dispositivos conectados, como GPUs.
  2. O administrador do cluster comunica informações sobre nós específicos e os dispositivos conectados aos 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ó que tenha 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 que os contêineres vão consumir 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 do cluster se comuniquem sobre quais nós ou pools de nós específicos têm certas configurações de dispositivo. Elas precisam coordenar as solicitações de carga de trabalho para corresponder aos dispositivos nos nós, ou a implantação falha. Em comparação, a DRA permite usar expressões para filtrar de forma flexível dispositivos com base em atributos e não exige que os operadores de carga de trabalho saibam a configuração exata dos nós no cluster.

A tabela a seguir compara a DRA com os plug-ins do dispositivo:

DRA Alocação manual
Seleção flexível de dispositivos usando expressões CEL Seleção de nó específica usando seletores e solicitações de recurso
Decisões de programação feitas pelo Kubernetes Decisões de programação feitas pelo operador usando seletores de nó
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 classes 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 do rótulo do nó ou os modelos de dispositivo conectados a cada nó. Os operadores de apps precisam saber quais nós têm modelos específicos e quantidades de determinados dispositivos conectados.

Dispositivos do GKE com suporte para a 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 com suporte do GKE, consulte os seguintes recursos:

Limitações da DRA no GKE

A DRA tem as seguintes limitações nos 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 de vários processos (MPS).
  • Não é possível usar a DRA em clusters do Autopilot.
  • Use o GKE versão 1.32.1-gke.1489001 ou mais recente.

Esta seção oferece recomendações para administradores de plataforma ou operadores de apps que querem usar a DRA para alocar dispositivos a cargas de trabalho. O DRA muda significativamente o método pelo qual você solicita 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 de dispositivos detalhada, considere as seguintes orientações:

Melhorar a disponibilidade de nós durante o escalonamento

As ComputeClasses no GKE permitem definir o comportamento de fallback prioritário que o GKE segue ao criar novos nós em clusters. É possível usar as classes de computação para configurar uma série priorizada de configurações de nós e dispositivos que o GKE usa ao criar nós para executar cargas de trabalho. Em seguida, use a DRA para garantir que a carga de trabalho possa ser executada em qualquer nó da ComputeClass sem precisar selecionar manualmente os nós 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. É possível criar uma ComputeClass que priorize a criação de nós com uma GPU A100 (40 GB), mas que possa voltar a criar nós com duas GPUs L4 por nó. Você pode usar 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 a DRA, o GKE pode colocar a carga de trabalho no primeiro nó disponível, independentemente do modelo da GPU, do rótulo do nó ou da contagem de GPU.

Para saber mais, leia as seguintes páginas:

A seguir