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

É possível usar a alocação dinâmica de recursos (DRA) para alocar GPUs às cargas de trabalho do Google Kubernetes Engine (GKE). Este documento explica os fundamentos da DRA, como usá-la no GKE e os benefícios de usar a DRA.

Este documento é destinado às seguintes funções:

Você já precisa conhecer os seguintes conceitos:

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 anexados aos nós.

Com a DRA, alocar dispositivos para pods é semelhante a alocar 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 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: é possível 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

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 a hardware de GPU, use o DRA para solicitar qualquer GPU disponível no cluster, sem precisar 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 durante o escalonamento: a quantidade de dispositivos que uma carga de trabalho exige pode mudar dependendo de fatores como o tipo de dispositivo e suas funcionalidades. É possível usar as ComputeClasses do GKE para colocar pods acelerados em pools de nós específicos com base na disponibilidade de dispositivos. Em seguida, configure os pods para reivindicar os dispositivos em qualquer nó em que o GKE os coloca.

    Usar o DRA com ComputeClasses permite minimizar o risco de cargas de trabalho não programadas e ajuda a executar cargas de trabalho em hardware otimizado.

Terminologia

O Kubernetes de código aberto e os provedores de Kubernetes gerenciados, como o GKE, usam os seguintes tipos principais de API 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 escalonador 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.

Para mais informações sobre os tipos de API DRA, consulte Terminologia da DRA.

Como a DRA funciona

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

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

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

  1. Os administradores de cluster instalam drivers de dispositivo que oferecem suporte ao 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 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 escalonador 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

Use ResourceClaims ou ResourceClaimTemplates para 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 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.

Para alocar dispositivos separados para pods, use um ResourceClaimTemplate, que é um modelo que o Kubernetes usa para criar automaticamente ResourceClaims individuais. Por exemplo, se você referenciar um ResourceClaimTemplate em um Deployment que tenha 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 estã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 criação automática pelo Kubernetes com um ResourceClaimTemplate:

Tabela 1. Comparação de ResourceClaims e ResourceClaimTemplates
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

A DRA torna a alocação de dispositivos anexados 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 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, 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. Caso contrário, a implantação falhará. Em comparação, a 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 saibam a configuração exata dos nós no cluster.

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

Tabela 2. Comparação entre a DRA e a alocação manual de dispositivos
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, as informações de rótulo do nó nem os modelos de dispositivos conectados a cada nó. Os operadores de apps precisam saber quais nós têm modelos e quantidades específicas de determinados dispositivos conectados.

DRA e escalonamento automático de infraestrutura

Para ajustar automaticamente o número de nós em um pool de nós do modo padrão, use o escalonador automático de cluster. É possível ativar o escalonador automático de cluster em qualquer pool de nós criado manualmente, incluindo aqueles com drivers DRA.

Para pools de nós que usam DRA, a utilização do dispositivo afeta a forma como o escalonador automático de cluster adiciona e remove nós em um pool de nós. Para calcular a utilização do dispositivo em um pool de nós, o escalonador automático de cluster considera os seguintes fatores:

  • Todos os dispositivos em um pool de recursos precisam estar locais a um nó específico. Se um ResourceSlice tiver um pool de dispositivos anexados a vários nós, o escalonador automático de cluster vai ignorar esses dispositivos.
  • Todos os dispositivos no pool de nós são igualmente importantes e idênticos.
  • Os dispositivos DRA têm maior prioridade do que a CPU ou a memória. Em pools de nós da DRA, o autoescalador de cluster ignora o uso de CPU e memória.

Esses fatores podem significar que você vai notar um comportamento de redução diferente nos pools de nós do DRA do que em outros pools de nós.

Dispositivos do GKE compatíveis com o DRA

A tabela a seguir descreve os dispositivos que podem ser alocados para cargas de trabalho com DRA no GKE:

Tabela 3. Dispositivos compatíveis com DRA no GKE
Dispositivos compatíveis com a DRA
GPUs Qualquer tipo de GPU disponível na sua região. Para mais informações, consulte Locais de GPU.
Interfaces de rede Vários tipos de interfaces de rede, como interfaces compatíveis com RDMA, instalando o driver DRANET gerenciado. Para mais informações, consulte Alocar recursos de rede usando o DRANET gerenciado pelo GKE.

Limitações

As seguintes limitações se aplicam ao usar a DRA:

  • Modo de operação: o DRA está disponível apenas em clusters do modo padrão.

  • Tipo de acelerador: durante a visualização, o DRA no GKE é compatível apenas com GPUs.

  • GPUs:

  • Interfaces de rede (prévia): consulte Limitações em "Alocar recursos de rede usando o DRANET gerenciado pelo GKE".

  • Escalonamento automático:

    • Para drivers DRA de terceiros que você instala, o escalonador automático de cluster exige que os pools de nós tenham pelo menos um nó. Para impedir que pools de nós que usam drivers de terceiros sejam escalonados para zero nós, defina o número mínimo de nós como pelo menos 1.
    • O autoescalador de cluster pode não funcionar corretamente com drivers DRA de terceiros. Se você usa drivers de terceiros, verifique se eles publicam informações apenas para dispositivos locais de nós específicos.
    • Para DaemonSets em pools de nós com escalonamento automático que usam um ResourceClaim estático para compartilhar o acesso ao dispositivo entre os pods, o escalonamento automático oferece suporte a até 128 pods do DaemonSet. Para evitar essa limitação, faça o seguinte:
    • Se os pods referenciam ResourceClaims e têm uma PriorityClass que define a política de preempção como PreemptLowerPriority, a latência do escalonamento automático pode aumentar. PreemptLowerPriority é a política de preempção padrão para PriorityClass. Portanto, verifique se as PriorityClasses definem explicitamente o campo preemptionPolicy como Never. Para mais informações, consulte PriorityClass não preemptivo.

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:

A seguir