Sobre as classes de computação personalizadas

Esta página descreve como usar classes de computação personalizadas para controlar as propriedades dos nós provisionados pelo Google Kubernetes Engine (GKE) ao fazer o dimensionamento automático do cluster. Este documento é destinado a administradores de plataforma que querem definir de forma declarativa perfis de escalonamento automático para nós, para que cargas de trabalho específicas sejam executadas em hardware que atenda aos requisitos.

Visão geral das classes de computação

No GKE, uma classe de computação é um perfil que consiste em um conjunto de atributos de nó que o GKE usa para provisionar os nós que são executados das cargas de trabalho. As classes de computação podem ter otimizações específicas, como provisionar nós de alto desempenho ou priorizar custos otimizados configurações para reduzir custos operacionais. Com as classes de computação personalizadas, definem perfis que o GKE usa para provisionar nós atendem aos requisitos de cargas de trabalho específicas.

As classes de computação personalizadas estão disponíveis para uso no modo Autopilot e Standard do GKE na versão 1.30.3-gke.1451000 e mais recentes e oferecem uma abordagem declarativa para definir atributos de nó e prioridades de escalonamento automático. Há classes de computação personalizadas disponíveis para configurar e usar em todos os clusters do GKE qualificados por padrão.

Benefícios das classes de computação personalizadas

As classes de computação personalizadas oferecem os seguintes benefícios:

  • Prioridades de computação substitutas: definir uma hierarquia de configurações de nós em cada classe de computação para o GKE priorizar. Se a maior não estiver disponível, o GKE automaticamente escolhe a próxima configuração na hierarquia. Esse modelo substituto garante que, mesmo quando os recursos de computação estiverem indisponíveis, as cargas de trabalho ainda serão executadas em hardware otimizado com atrasos mínimos na programação.
  • Controle granular de escalonamento automático: defina as configurações de nó mais adequadas para cargas de trabalho específicas. O GKE prioriza esses durante a criação de nós durante o escalonamento.
  • Configuração declarativa de infraestrutura: adote uma abordagem declarativa para o gerenciamento de infraestrutura para que o GKE crie automaticamente nós que correspondam aos requisitos específicos da carga de trabalho.
  • Migração ativa: se recursos de computação para uma máquina de sua preferência disponível no seu local, o GKE migra automaticamente as cargas de trabalho para novos nós que usam a configuração do Terraform.
  • Otimização de custos: priorize tipos de nós econômicos, como VMs do Spot, para reduzir as despesas do cluster.
  • Classes de computação padrão para namespaces: defina uma classe de computação padrão em cada namespace do Kubernetes, para que as cargas de trabalho nele sejam executadas otimizado ao hardware, mesmo que não solicitem uma classe de computação específica.
  • Limites personalizados de consolidação de nós: definir o uso de recursos personalizados limites mínimos para nós. Se o uso de recursos de um nó específico ficar abaixo do limite, o GKE vai tentar consolidar as cargas de trabalho em um nó semelhante e disponível e reduzir o nó subutilizado.

Casos de uso de classes de computação personalizadas

Considere o uso de classes de computação personalizadas em cenários como os seguintes:

  • Você quer executar cargas de trabalho de IA/ML em configurações específicas de GPU.
  • Você quer definir configurações de hardware padrão para as cargas de trabalho por equipes específicas, eliminando a sobrecarga dos operadores de aplicativos.
  • Você executa cargas de trabalho que têm um desempenho ideal em determinados ou configurações de hardware.
  • Você quer declarar configurações de hardware que atendem a requisitos específicos como alto desempenho, custo otimizado ou alta disponibilidade.
  • Você quer que o GKE use hierarquicamente configurações de hardware específicas durante a indisponibilidade de recursos de computação, para que as cargas de trabalho sejam executadas sempre em máquinas que atendam aos requisitos.
  • Você quer decidir centralmente as configurações ideais em toda a frota da empresa para que seus custos sejam mais previsíveis e as cargas de trabalho sejam executadas com mais confiabilidade.

Limitações

Não é possível usar classes de computação personalizadas com a capacidade do Compute Engine reservas no modo Autopilot ou em provisionamento automático pools de nós do modo padrão. Modo padrão criado manualmente os pools de nós aceitam reservas de capacidade.

Como as classes de computação personalizadas funcionam

As classes de computação personalizadas são recursos personalizados do Kubernetes que provisionam infraestrutura do Google Cloud. Você define um objeto ComputeClass no cluster e solicita essa classe de computação em cargas de trabalho ou define essa classe como padrão para um namespace do Kubernetes. Quando você implanta uma carga de trabalho que solicita a classe de computação, o GKE tenta colocar os pods nós que atendem aos requisitos da classe de computação.

Para garantir que suas classes de computação personalizadas sejam otimizadas para a frota, considere estas diretrizes:

  • Entenda os requisitos de computação da sua frota, incluindo requisitos de hardware específicos do aplicativo.
  • Escolha um tema que oriente o design de cada classe de computação. Por exemplo, uma classe de computação otimizada para performance pode ter uma estratégia alternativa que usa apenas tipos de máquina de alta CPU.
  • Escolha a família e a série de máquinas do Compute Engine que se adequam mais às suas cargas de trabalho. Para mais detalhes, consulte Guia de comparação e recursos de famílias de máquinas.
  • Planeje uma estratégia de fallback dentro de cada classe de computação para que as cargas de trabalho sempre executadas em nós que usam configurações de máquina semelhantes. Por exemplo, se a série de máquinas N4 não estiver disponível, você poderá usar máquinas N2.

Confira a definição completa do recurso personalizado

Para conferir a definição de recurso personalizada (CRD, na sigla em inglês) completa do ComputeClass recurso personalizado, execute o seguinte comando:

kubectl describe crd computeclasses.cloud.google.com

A saída mostra todo o CRD, incluindo todos os campos compatíveis e relações entre campos. Para entender melhor as classes de computação personalizadas, consulte esta definição enquanto lê este documento.

Planejar uma classe de computação personalizada

Para planejar, implantar e usar uma classe de computação personalizada no cluster, siga estas etapas:

  1. Escolha suas prioridades de computação substitutas: defina um série de regras que controlam as propriedades dos nós que que o GKE cria para a classe de computação.
  2. Configure classes de computação e pools de nós do GKE Standard: para clusters no modo padrão, realize as etapas de configuração necessárias para usar a classe de computação com seus pools de nós.
  3. Definir o comportamento de escalonamento quando nenhuma regra de prioridade for aplicada: Como opção, informe ao GKE o que fazer se os nós atenderem às suas regras de prioridade não podem ser provisionados.
  4. Definir parâmetros de escalonamento automático para consolidação de nós: informar ao GKE quando consolidar as cargas de trabalho e remover nós.
  5. Configure a migração ativa para nós de prioridade mais alta: como opção, diga ao GKE para mover cargas de trabalho quando o hardware fica disponível.

Escolher as prioridades de computação substitutas

A principal vantagem de usar uma classe de computação personalizada é ter controle sobre a estratégia de substituto quando os nós preferidos estiverem indisponíveis devido a fatores como esgotamento de recursos e limitações de cota.

Para criar uma estratégia substituta, defina uma lista de regras de prioridade na sua uma classe de computação personalizada. Quando é preciso escalonar verticalmente um cluster, o GKE prioriza a criação de nós que correspondam à primeira regra de prioridade. Se o GKE não conseguir criar esses nós, ele vai usar a próxima regra de prioridade, repetindo esse processo até que o GKE dimensione o cluster ou esgote todas as regras. Se todas as regras forem esgotadas, o GKE vai criar nós com base no comportamento padrão ou especificado descrito em Definir o comportamento de escalonamento quando nenhuma regra de prioridade for aplicada.

Regras de prioridade

Você define regras de prioridade no campo spec.priorities da ComputeClass recurso personalizado. Cada regra no campo priorities descreve as propriedades dos nós a provisionar. O GKE processa o campo priorities na ordem, o que significa que o primeiro item no campo é a prioridade mais alta para o provisionamento de nós.

Dependendo do tipo de regra de prioridade, é possível especificar como VMs spot ou capacidade mínima de CPU, GKE a ser usado ao provisionar nós. O campo priorities oferece suporte aos seguintes tipos de regra de prioridade:

  • machineFamily: define nós usando uma máquina do Compute Engine como n2 ou c3.
  • machineType: define nós usando um tipo de máquina predefinido do Compute Engine, como n2-standard-4.
  • nodepools: nos clusters do GKE Standard, fornece uma lista de pools de nós criados manualmente que são associados à classe de computação em que o GKE precisa provisionar nós.

Tipo de regra machineFamily

O campo machineFamily aceita uma da série de máquinas do Compute Engine, como n2 ou c3. Se não for especificado, o padrão será e2. Você pode usar as seguintes opções: campos ao lado do tipo de regra machineFamily:

  • spot: VMs spot. O valor padrão é false.
  • minCores: mínimo de vCPUs por nó. O valor padrão é 0.
  • minMemoryGb: memória mínima por nó. O valor padrão é 0.
  • storage.bootDiskKMSKey: caminho para a chave do Cloud Key Management Service a ser usada no disco de inicialização criptografia.

O exemplo a seguir mostra a regra de prioridade machineFamily:

priorities:
- machineFamily: n2
  spot: true
  minCores: 16
  minMemoryGb: 64
  storage:
    bootDiskKMSKey: projects/example/locations/us-central1/keyRings/example/cryptoKeys/key-1

Tipo de regra machineType

O campo machineType aceita uma máquina predefinida do Compute Engine tipo, como n2-standard-32. O tipo de máquina precisa ser compatível com todas as GPUs especificadas.

Você pode usar os seguintes campos junto com o tipo de regra machineType:

  • spot: usar VMs do Spot O padrão é false.
  • storage: configurar o armazenamento do nó.
    • storage.bootDiskType: tipo de disco de inicialização.
    • storage.bootDiskKMSKey: caminho para a chave do Cloud KMS a ser usada para o disco de inicialização criptografia.
    • storage.bootDiskSize: tamanho do disco de inicialização de nós em GB.
    • storage.localSSDCount: número de SSDs locais a serem anexados ao nó. Se especificado, precisa ser pelo menos 1.
  • gpu: configura GPUs.

O exemplo a seguir mostra uma regra machineType para tipos de máquina n2-standard-32:

priorities:
- machineType: n2-standard-32
  spot: true
  storage:
    bootDiskType: pd-balanced
    bootDiskSize: 250
    localSSDCount: 2
    bootDiskKMSKey: projects/example/locations/us-central1/keyRings/example/cryptoKeys/key-1

O exemplo a seguir mostra uma regra machineType para GPUs:

priorities:
- machineType: g2-standard-16
  spot: false
  gpu:
    type: nvidia-l4
    count: 1

Tipo de regra nodepools

O campo nodepools usa uma lista de pools de nós atuais em que O GKE tenta criar pods pendentes. O GKE não processa os valores neste campo em ordem. Não é possível especificar outras propriedades de máquina ao lado desse campo no mesmo item de regra de prioridade. Esse campo é compatível apenas com o modo padrão do GKE. Para detalhes de uso, consulte Segmentar pools de nós específicos em uma definição de classe de computação.

Como o GKE cria nós usando regras de prioridade

Quando você implanta uma carga de trabalho que solicita uma classe de computação e um novo nó é necessário, o GKE processa a lista de regras no campo priorities da especificação ComputeClass em ordem.

Por exemplo, considere a seguinte especificação:

spec:
  ...
  priorities:
  - machineFamily: n2
    spot: true
    minCores: 64
  - machineFamily: n2
    spot: true
  - machineFamily: n2
    spot: false

Quando você implanta uma carga de trabalho que solicita uma classe de computação com essas regras de prioridade, o GKE faz a correspondência de nós da seguinte maneira:

  1. O GKE coloca os pods nos nós atuais associados com essa classe de computação.
  2. Se os nós atuais não puderem acomodar os pods, o GKE provisiona que usam a série de máquinas N2, são VMs spot e pelo menos 64 vCPUs.
  3. Se as VMs spot N2 com pelo menos 64 vCPUs não estiverem disponíveis região, o GKE provisiona novos nós que usam N2 VMs spot que podem se encaixar nos pods, independente do número de núcleos
  4. Se não houver VMs N2 do Spot disponíveis na região, o GKE provisionará novas VMs N2 sob demanda.
  5. Se nenhuma das regras anteriores puder ser atendida, o GKE vai seguir a lógica na seção Definir o comportamento de escalonamento quando nenhuma regra de prioridade se aplicar.

Pools de nós do GKE Standard e classes de computação

Se você usa o modo GKE Standard, talvez tenha que realizar configuração manual para garantir que seus pods de classe de computação sejam programados o esperado.

Configurar pools de nós criados manualmente para uso da classe de computação

Se os clusters do GKE Standard tiverem pools de nós que você criados manualmente sem o provisionamento automático de nós, eles precisam ser configurados para associá-los a classes de computação específicas. O GKE só programa pods que solicitam uma classe de computação específica em nós em pools de nós que você associa a essa classe de computação. Autopilot do GKE e os pools de nós do modo GKE Standard que foram criados pelo provisionamento automático de nós.

Para associar um pool de nós criado manualmente a uma classe de computação, adicione rótulos de nó e taints de nó ao pool de nós durante a criação ou uma atualização, especificando as flags --node-labels e --node-taints, conforme mostrado abaixo:

  • Rótulo do nó: cloud.google.com/compute-class=COMPUTE_CLASS
  • Taint: cloud.google.com/compute-class=COMPUTE_CLASS:NoSchedule

Nesses atributos, COMPUTE_CLASS é o nome do uma classe de computação personalizada.

Por exemplo, o comando a seguir atualiza um pool de nós e o associa à classe de computação dev-class:

gcloud container node-pools update dev-pool \
    --cluster=example-cluster \
    --node-labels="cloud.google.com/compute-class=dev-class" \
    --node-taints="cloud.google.com/compute-class=dev-class:NoSchedule"

É possível associar cada pool de nós no cluster a uma classe de computação personalizada. Pods que o GKE programa apenas nesses pools de nós criados manualmente acionar a criação de nós dentro desses pools de nós durante eventos de escalonamento automático.

Provisionamento automático de nós e classes de computação

É possível usar o provisionamento automático de nós com uma classe de computação personalizada para permitir que o GKE crie e exclua pools de nós automaticamente com base nas regras de prioridade.

Para usar o provisionamento automático de nós com uma classe de computação, faça o seguinte:

  1. Verifique se o provisionamento automático de nós está ativado no cluster.
  2. Adicione o campo nodePoolAutoCreation com o valor enabled: true à sua especificação ComputeClass.

O GKE pode então posicionar pods que usam classes de computação que configuram com o provisionamento automático de nós em novos pools de nós. O GKE decide escalonar verticalmente um pool de nós atual ou criar um novo com base em fatores como o tamanho dos clusters e requisitos dos pods. Pods com classes de computação que não configuram o provisionamento automático de nós continuam a aumentar apenas os pools de nós existentes.

É possível usar classes de computação que interagem com o provisionamento automático de nós com classes de computação que interagem com pools de nós criados manualmente no mesmo cluster.

Considere as seguintes interações com o provisionamento automático de nós:

  • Não é possível usar os seletores de nó da família de máquinas ou das VMs spot, porque eles entram em conflito com o comportamento da classe de computação. O GKE rejeita pods que solicitam uma classe de computação e também VMs do Spot ou séries de máquinas específicas.
  • É possível configurar o provisionamento automático de nós para classes de computação que usam o campo nodepools para fazer referência a pools de nós atuais. O provisionamento automático de nós processa as prioridades em ordem e tenta escalonar os pools de nós existentes para colocar seus pods.

Considere o exemplo a seguir de um cluster com pools de nós criados manualmente e provisionamento automático de nós:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - nodepools: [manually-created-pool]
  - machineFamily: n2
  - machineFamily: n2d
  nodePoolAutoCreation:
    enabled: true

Neste exemplo, o GKE tenta fazer o seguinte:

  1. Crie novos nós no pool de nós manually-created-pool.
  2. Provisionar nós N2, seja em pools de nós N2 existentes ou criando um novo no pool de nós.
  3. Se o GKE não puder criar nós N2, ele tentará escalonar verticalmente pools de nós N2D existentes ou criar novos pools de nós N2D.

Segmentar pools de nós específicos em uma definição de classe de computação

O campo priorities.nodepools permite especificar uma lista de objetos pools de nós em que o GKE tenta programar pods em clusters do GKE Standard que usam clusters escalonamento automático. Este campo só aceita uma lista de pools de nós. não é possível especificar propriedades de máquina adicionais, como a série de máquinas, na mesma regra de prioridade. Quando você implanta uma carga de trabalho que solicita uma classe de computação com um nome de nó pools, o GKE tenta programar os pods pendentes nesses nós piscinas O GKE pode criar novos nós nesses pools para colocar os pods.

Os pools de nós especificados no campo priorities.nodepools precisam ser associadas a essa classe de computação usando rótulos e taints de nó, conforme descritas nos Seção Configurar pools de nós criados manualmente para classes de computação.

A lista de pools de nós especificada no campo nodepools não tem prioridade. Para configurar uma ordem de fallback para pools de nós nomeados, especifique vários itens priorities.nodepools separados. Por exemplo, considere o seguinte especificação:

spec:
  ...
  priorities:
  - nodepools: [pool1, pool2]
  - nodepools: [pool3]

Neste exemplo, o GKE primeiro tenta colocar pods pendentes que solicitam essa classe de computação em nós existentes em pools de nós rotulados com a classe de computação. Se os nós atuais não estiverem disponíveis, o GKE tentará provisionar novos nós em pool1 ou pool2. Se o GKE não conseguir provisionar novos nós nesses pools, ele tentará provisionar novos pods em pool3.

Definir o comportamento de escalonamento quando nenhuma regra de prioridade se aplica

O recurso personalizado ComputeClass permite especificar o que o GKE deve fazer se não houver nós que possam atender a qualquer uma das regras de prioridade. O campo whenUnsatisfiable na especificação aceita os seguintes valores:

  • ScaleUpAnyway: cria um novo nó que usa a configuração de máquina padrão do cluster. Esse é o comportamento padrão.
    • Nos clusters do Autopilot, o GKE coloca o pod em um nó novo ou atual, independentemente da configuração da máquina do nó.
    • Nos clusters padrão que não usam o provisionamento automático de nós, O GKE tenta escalonar verticalmente qualquer pool de nós criado manualmente que define um rótulo e um taint correspondentes a uma determinada classe de computação.
    • Nos clusters padrão que usam o provisionamento automático de nós, O GKE pode criar um novo pool de nós que use o padrão E2 série de máquinas para colocar o pod.
  • DoNotScaleUp: deixa o pod no status Pending até que um nó que atende aos requisitos da classe de computação.

Definir parâmetros de escalonamento automático para consolidação de nós

Por padrão, o GKE remove nós subutilizados executando cargas de trabalho, consolidando essas cargas em outros nós que têm capacidade. Para todas as classes de computação, esse é o comportamento padrão, porque todos os clusters que usam as classes de computação precisam usar o escalonador automático de clusters ou são Autopilot clusters. Durante uma consolidação de nós, o GKE esvazia um nó subutilizado, recria as cargas de trabalho em outro nó e exclui o nó esvaziado.

O tempo e os critérios para a remoção do nó dependem do perfil de escalonamento automático. É possível ajustar os limites de subutilização de recursos que acionam os nós remoção e consolidação da carga de trabalho usando a seção autoscalingPolicy na a definição da classe do Compute personalizada. É possível ajustar os seguintes parâmetros:

  • consolidationDelayMinutes: o número de minutos após os quais O GKE remove nós subutilizados
  • consolidationThreshold: o limite de utilização da CPU e da memória como uma porcentagem dos recursos disponíveis do nó. O GKE só considera a remoção de nós se a utilização de recursos for menor que esse limite.
  • gpuConsolidationThreshold: o limite de utilização da GPU como uma porcentagem dos recursos disponíveis do nó. O GKE só considera a remoção de nós se a utilização de recursos for menor que esse limite. Defina esse valor como 100 ou 0 para que o GKE consolide todos os nós que não tenham 100% de utilização de GPUs anexadas.

Veja o exemplo a seguir.

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - machineFamily: n2
  - machineFamily: n2d
  autoscalingPolicy:
    consolidationDelayMinutes: 5
    consolidationThreshold: 70

Nessa configuração, o GKE remove nós não usados após cinco minutos, e eles só se tornam candidatos à consolidação se a CPU e a utilização da memória forem menores que 70%.

Configurar a migração ativa para nós de prioridade mais alta

A migração ativa é um recurso opcional de escalonamento automático em classes de computação personalizadas que substitui automaticamente os nós existentes que estão mais baixos na lista de prioridade de fallback de uma classe de computação por novos nós que estão mais altos nessa lista de prioridade. Isso garante que todos os pods em execução sejam executados nos nós mais preferidos para essa classe de computação, mesmo que o GKE tenha que executar esses pods em nós menos preferidos.

Quando ocorre uma migração ativa, o GKE cria novos nós com base nas regras de prioridade da classe de computação e, em seguida, drena e exclui os nós de prioridade mais baixa obsoletos. A migração acontece gradualmente para minimizar a interrupção da carga de trabalho. A migração ativa tem as seguintes considerações:

  • A migração ativa só está disponível nas classes de computação que usam o Tipo de regra de prioridade machineFamily. Se a classe de computação tiver o nodepools ou as machineType regras de prioridade, a migração ativa não está suporte.
  • Se você tiver ativado o provisionamento automático de nós nos clusters padrão, a migração ativa poderá acionar a criação de novos pools de nós se os pools de nós atuais não atenderem aos critérios de maior prioridade definidos na classe de computação personalizada.
  • Para evitar interrupções críticas na carga de trabalho, a migração ativa não move os pods a seguir:
    • Pods que definem um PodDisruptionBudget, se a mudança exceder o PodDisruptionBudget.
    • Pods com a anotação cluster-autoscaler.kubernetes.io/safe-to-evict: "false".

Considere o seguinte exemplo de especificação de classe de computação, que prioriza Nós N2 em nós E2:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - machineFamily: n2
  - machineFamily: n2d
  activeMigration:
    optimizeRulePriority: true

Se os nós N2 estivessem indisponíveis quando você implantou um pod com essa classe de computação, o GKE teria usado os nós N2D como uma opção alternativa. Se nós N2 fiquem disponíveis para provisionamento posterior, por exemplo, se a cota aumentar ou se as VMs N2 ficam disponíveis no seu local, o GKE cria um nó N2 e migra gradualmente o pod do nó N2D existente para o novo nó N2. O GKE exclui o nó N2D obsoleto.

Solicitar classes de computação em cargas de trabalho

Para usar uma classe de computação personalizada depois de projetá-la, seu pod precisa solicitar explicitamente essa classe de computação na especificação do pod. Você pode definir uma classe de computação como padrão em um namespace específico do Kubernetes. Nesse caso, os pods nesse namespace vão usar essa classe de computação, a menos que solicitem uma classe de computação diferente.

Para ver instruções sobre como solicitar e usar classes de computação no GKE, consulte Controlar atributos de nó com escalonamento automático usando classes de computação personalizadas.

A seguir