Acerca da atribuição dinâmica de recursos no GKE

Esta página fornece informações sobre a atribuição dinâmica de recursos (DRA) no Google Kubernetes Engine (GKE). Nesta página, vai saber mais sobre os princípios básicos da DRA, como funciona no GKE e as vantagens de usar a DRA para atribuir hardware, como GPUs e TPUs.

Esta página destina-se às seguintes funções:

Antes de ler esta página, certifique-se de que conhece os seguintes recursos:

Introdução à DRA

A DRA é uma funcionalidade do Kubernetes incorporada que lhe permite pedir, atribuir e partilhar hardware de forma flexível no seu cluster entre pods e contentores. A DRA melhora a experiência de atribuição de hardware ligado, como aceleradores, permitindo que os fornecedores de dispositivos e os administradores da plataforma declarem classes de dispositivos que podem ser pedidos e atribuídos. Os operadores de apps podem pedir configurações de dispositivos específicas nessas classes e, em seguida, pedir essas configurações nas respetivas cargas de trabalho. O Kubernetes e o GKE gerem o agendamento de pods, as atribuições de nós e a alocação de dispositivos com base em pedidos de cargas de trabalho.

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

Vantagens da DRA

Sem a DRA, a atribuição de dispositivos de hardware no Kubernetes baseia-se em plug-ins de dispositivos. Para associar recursos de hardware a pods através da utilização de plug-ins de dispositivos, usa etiquetas de nós para colocar pods em nós específicos. Além disso, para dedicar os recursos de um nó inteiro a um único pod, pede o número exato de dispositivos associados aos nós.

Com a DRA, a experiência de atribuição de dispositivos a Pods é semelhante à atribuição de volumes para armazenamento. Define classes de dispositivos, pede dispositivos nessas classes e, em seguida, atribui esses dispositivos pedidos a cargas de trabalho. A DRA oferece uma superfície significativamente mais extensível para filtrar dispositivos com base na carga de trabalho e nas necessidades empresariais. A abordagem DRA de usar expressões e modelos para reivindicar hardware e agendar pods tem as seguintes vantagens:

  • Atribuição declarativa de dispositivos: os administradores da plataforma podem definir configurações de dispositivos para tipos específicos de cargas de trabalho ou equipas.
  • Complexidade entre equipas reduzida: quando os administradores da plataforma aprovisionam nós com configurações de hardware especializadas, os operadores de apps não precisam de saber que nós têm configurações específicas. Os administradores da plataforma não precisam de etiquetar nós nem comunicar informações sobre nós e dispositivos específicos aos operadores.
  • Complexidade do programador reduzida: o Kubernetes agenda pods com base na configuração do dispositivo referenciada. Os operadores de apps não precisam de selecionar nós específicos nas respetivas cargas de trabalho nem garantir que cada Pod pede exatamente o número de dispositivos anexados a esses nós.
  • Gestão de infraestrutura centralizada: os administradores da plataforma podem definir centralmente configurações de hardware que cumprem requisitos empresariais específicos. Por exemplo, um administrador da plataforma pode declarar uma configuração de alto desempenho com GPUs H100 juntamente com uma pequena configuração de inferência com GPUs Tesla T4.
  • Seleção de hardware flexível: a DRA permite-lhe usar expressões CEL para filtrar dispositivos com atributos específicos. A utilização de expressões oferece a flexibilidade de filtrar dispositivos que são ideais para cargas de trabalho específicas.

Quando usar o DRA

Durante a pré-visualização, o principal motivo para usar o DRA no GKE é a flexibilidade com que pode pedir dispositivos para cargas de trabalho. Pode escrever um manifesto uma vez e implementar a carga de trabalho em diferentes clusters com diferentes tipos de dispositivos sem ter de alterar o manifesto. Esta flexibilidade é ideal para exemplos de utilização como os seguintes:

  • Melhore a obtenção de GPUs: para cargas de trabalho que precisam de acesso ao hardware de GPU, pode usar o DRA para pedir qualquer GPU disponível no cluster, em vez de ter de especificar um modelo de GPU. Se essas cargas de trabalho tiverem requisitos específicos de memória da GPU (VRAM), pode pedir qualquer GPU no cluster que tenha uma quantidade mínima de memória. Este tipo de pedido flexível expande o conjunto de nós da GPU em que uma carga de trabalho pode ser executada, o que reduz o risco de a carga de trabalho não ser agendada devido a recursos indisponíveis.
  • Otimize a disponibilidade de nós de GPU durante o dimensionamento: o número de GPUs anexadas que uma carga de trabalho requer pode mudar consoante o tipo de GPU. Pode usar uma classe de computação do GKE para aprovisionar nós com base na disponibilidade, na quota ou nas reservas de capacidade da GPU. Em seguida, pode usar o DRA nas suas cargas de trabalho para configurar os pods de modo a serem executados em qualquer nó que o GKE aprovisione para a classe de computação. A utilização da DRA com classes de computação permite-lhe minimizar o risco de cargas de trabalho não agendadas e garantir que as cargas de trabalho são executadas em hardware otimizado.

Terminologia

O Kubernetes de código aberto e os fornecedores de Kubernetes geridos, como o GKE, usam os seguintes termos da DRA:

ResourceSlice
Um ResourceSlice apresenta um ou mais dispositivos de hardware no cluster aos quais os nós podem aceder. Por exemplo, num nó que pode aceder a uma única GPU, o ResourceSlice apresenta a GPU e o nome do nó. Os controladores de dispositivos DRA em cada nó criam ResourceSlices. O programador do Kubernetes usa ResourceSlices para decidir que dispositivos atribuir para satisfazer os pedidos de cargas de trabalho.
DeviceClass
Uma DeviceClass define uma categoria de dispositivos, como GPUs, que estão disponíveis para pedido para cargas de trabalho. Alguns controladores de dispositivos fornecem DeviceClasses incorporadas, como a gpu.nvidia.com DeviceClass para GPUs NVIDIA. Os administradores da plataforma também podem criar DeviceClasses personalizadas que definem configurações de dispositivos específicas.
ResourceClaim

Um ResourceClaim permite que um Pod ou um utilizador solicitem recursos de hardware filtrando determinados parâmetros numa 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 cria um ResourceClaim para uma GPU A100 (40 GB) e, em seguida, implementa uma carga de trabalho que seleciona esse ResourceClaim. O Kubernetes atribui uma GPU A100 (40 GB) disponível ao ResourceClaim e agenda o seu pod num nó que pode aceder a 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 tem várias cargas de trabalho que precisam de acesso a configurações de dispositivos semelhantes, especialmente quando usa um controlador de carga de trabalho como Implementações ou StatefulSets.

Os operadores de apps implementam ResourceClaimTemplates e, em seguida, referenciam os modelos em cargas de trabalho. O Kubernetes cria ResourceClaims para cada pod com base no modelo especificado, atribui dispositivos e agenda os pods. Quando os pods terminam, o Kubernetes limpa os ResourceClaims correspondentes.

Como funciona a DRA

A utilização da DRA nos seus clusters e cargas de trabalho é uma experiência semelhante à utilização de StorageClasses, PersistentVolumeClaims e PersistentVolumes para aprovisionar dinamicamente volumes para pods.

O diagrama seguinte mostra os passos que os administradores de clusters e os operadores de apps seguem para atribuir dispositivos através da DRA:

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

  1. Os administradores do cluster instalam controladores de dispositivos que suportam a DRA nos nós.
  2. Os administradores de clusters criam DeviceClasses que filtram o hardware que cumpre requisitos específicos, como todas as GPUs com mais de 40 GB de memória. Alguns dispositivos também podem incluir DeviceClasses incorporadas.
  3. Os operadores de aplicações criam ResourceClaimTemplates ou ResourceClaims que pedem configurações de dispositivos. O exemplo de utilização principal para cada tipo de reivindicação é o seguinte:
    • Um ResourceClaim permite que vários pods partilhem o acesso ao mesmo dispositivo.
    • Um ResourceClaimTemplate permite que vários pods acedam a dispositivos separados e semelhantes, gerando automaticamente ResourceClaims por pod.
  4. Os operadores de aplicações adicionam os ResourceClaimTemplates ou os ResourceClaims aos respetivos manifestos de carga de trabalho.
  5. Os operadores de aplicações implementam a carga de trabalho.

Quando implementa uma carga de trabalho que faz referência a um ResourceClaimTemplate ou a um ResourceClaim, o Kubernetes executa os seguintes passos de agendamento:

  1. Se a carga de trabalho fizer referência a um ResourceClaimTemplate, o Kubernetes cria um novo objeto ResourceClaim para cada instância da carga de trabalho (por exemplo, cada réplica numa implementação).
  2. O programador do Kubernetes usa as ResourceSlices no cluster para atribuir dispositivos disponíveis e elegíveis à ResourceClaim de cada Pod.
  3. O programador coloca cada Pod num nó que tem acesso aos dispositivos que foram atribuídos ao ResourceClaim do Pod.
  4. O kubelet no nó de destino chama o controlador DRA no nó para anexar o hardware atribuído ao pod de modo a satisfazer o respetivo pedido de recursos.

Quando usar ResourceClaims e ResourceClaimTemplates

Os ResourceClaims e os ResourceClaimTemplates permitem-lhe indicar ao Kubernetes que quer dispositivos que cumpram requisitos específicos. Quando um ResourceClaim é referenciado num pod, o Kubernetes atribui dispositivos ao recurso da API ResourceClaim correspondente no servidor da API Kubernetes. Esta atribuição ocorre independentemente de ter criado o ResourceClaim ou de o Kubernetes ter criado o ResourceClaim a partir de um ResourceClaimTemplate.

Se criar um ResourceClaim e, em seguida, fizer referência ao mesmo em vários pods, todos esses pods podem aceder aos dispositivos que o Kubernetes atribui a esse ResourceClaim. Por exemplo, este acesso partilhado pode ocorrer se fizer referência a um ResourceClaim específico num manifesto de implementação que tenha várias réplicas. No entanto, se os dispositivos atribuídos não estiverem configurados para serem partilhados por vários processos, este acesso a dispositivos partilhados em vários pods pode resultar num comportamento não intencional.

Um ResourceClaimTemplate permite-lhe definir modelos que o Kubernetes usa para criar automaticamente ResourceClaims individuais para Pods. Por exemplo, se fizer referência a um ResourceClaimTemplate numa implementação que tenha várias réplicas, o Kubernetes cria um ResourceClaim separado para cada Pod replicado. Como resultado, cada Pod recebe o seu próprio dispositivo atribuído em vez de partilhar o acesso ao dispositivo com outros Pods. Estas ResourceClaims geradas automaticamente estão associadas à duração do Pod correspondente e são eliminadas quando o Pod termina. Se tiver Pods independentes que precisam de acesso a configurações de dispositivos semelhantes, use um ResourceClaimTemplate para atribuir dispositivos a cada Pod separadamente.

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

ResourceClaims criados manualmente ResourceClaims criados automaticamente
Gerido por si Gerido pelo Kubernetes
Oferece acesso aos mesmos dispositivos a partir de vários Pods Oferece acesso a dispositivos a partir de um único Pod
Existe no cluster independentemente dos pods Associado ao ciclo de vida do Pod correspondente
Ideal para várias cargas de trabalho que precisam de partilhar um dispositivo específico Ideal para várias cargas de trabalho que precisam de acesso independente ao dispositivo

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

A DRA torna a atribuição de dispositivos anexados uma experiência semelhante ao aprovisionamento dinâmico de PersistentVolumes. O Kubernetes também suporta a atribuição de dispositivos através de plug-ins de dispositivos. Este método envolve os seguintes passos:

  1. Um administrador do cluster cria nós com dispositivos anexados, como GPUs.
  2. O administrador do cluster comunica informações sobre nós específicos e os respetivos dispositivos anexos aos operadores de cargas de trabalho.
  3. Um operador de carga de trabalho pede dispositivos no manifesto da carga de trabalho da seguinte forma:
    • Selecione um nó que tenha a configuração do 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 contentores devem consumir usando o campo resources na especificação do pod.

Este método de atribuição manual requer que os operadores da aplicação e os administradores do cluster comuniquem sobre que nós ou conjuntos de nós específicos têm determinadas configurações de dispositivos. Têm de coordenar os pedidos de carga de trabalho para corresponderem aos dispositivos nos nós, caso contrário, a implementação falha. Em comparação, a DRA permite-lhe usar expressões para filtrar dispositivos de forma flexível com base em atributos e não requer que os operadores de carga de trabalho conheçam a configuração exata dos nós no cluster.

A tabela seguinte compara a DRA com os plug-ins de dispositivos:

DRA Atribuição manual
Seleção flexível de dispositivos através de expressões do IEC Seleção de nós específicos através de seletores e pedidos de recursos
Decisões de agendamento tomadas pelo Kubernetes Decisões de agendamento tomadas pelo operador através de seletores de nós
A filtragem de dispositivos é independente da criação de cargas de trabalho A filtragem de dispositivos tem de ser feita no manifesto da carga de trabalho
Filtragem de dispositivos centralizada e turmas baseadas em necessidades, geridas pelos administradores da plataforma Filtragem de dispositivos isolados por operadores de aplicações
Os operadores de apps não precisam de saber a capacidade dos nós, as informações das etiquetas dos nós nem os modelos de dispositivos anexados a cada nó Os operadores de apps têm de saber que nós têm modelos e quantidades específicos de determinados dispositivos anexados.

Dispositivos GKE suportados para DRA

Pode usar a DRA para atribuir GPUs ou TPUs a cargas de trabalho do GKE. Pode atribuir qualquer um dos modelos de GPU e TPU suportados pelo GKE. Para ver detalhes sobre as GPUs e as TPUs suportadas pelo GKE, consulte os seguintes recursos:

Limitações da DRA no GKE

O DRA tem as seguintes limitações nos clusters do GKE:

  • Não pode usar o DRA com o aprovisionamento automático de nós.
  • Não pode usar a DRA com as seguintes funcionalidades de partilha de GPU:
    • GPUs de tempo partilhado.
    • GPUs de várias instâncias.
    • Serviço de multiprocessos (MPS).
  • Não pode usar a DRA em clusters do Autopilot.
  • Tem de usar a versão 1.32.1-gke.1489001 ou posterior do GKE.

Esta secção fornece recomendações para administradores de plataformas ou operadores de apps que querem usar o DRA para atribuir dispositivos a cargas de trabalho. O DRA altera significativamente o método através do qual pede dispositivos anexados, tanto no GKE como no Kubernetes. Para tirar partido de exemplos de utilização mais avançados, como o fallback multidispositivo ou a filtragem e a seleção detalhadas de dispositivos, considere as seguintes orientações:

Melhore a disponibilidade dos nós durante o dimensionamento

As ComputeClasses no GKE permitem-lhe definir um comportamento de alternativa baseado na prioridade que o GKE segue quando cria novos nós em clusters. Pode usar ComputeClasses para configurar uma série prioritária de configurações de nós e dispositivos que o GKE usa quando cria nós para executar cargas de trabalho. Em seguida, pode usar o DRA para garantir que a sua carga de trabalho pode ser executada em qualquer nó na ComputeClass sem ter de selecionar manualmente os nós por etiqueta.

Por exemplo, uma carga de trabalho pode precisar de duas GPUs NVIDIA L4 ou uma GPU NVIDIA A100 (40 GB) para ser executada de forma ideal. Pode criar uma ComputeClass que priorize a criação de nós com uma GPU A100 (40 GB), mas que possa recorrer à criação de nós com duas GPUs L4 por nó. Em seguida, pode usar a DRA para pedir qualquer GPU disponível para a sua carga de trabalho. Quando implementa 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 de GPU, da etiqueta do nó ou da quantidade de GPUs.

Para saber mais, consulte as seguintes páginas:

O que se segue?