Sobre as ComputeClasses personalizadas

É possível criar suas próprias ComputeClasses para controlar as propriedades dos nós provisionados pelo Google Kubernetes Engine (GKE) ao fazer o escalonamento 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. Para mais informações sobre o que são ComputeClasses, consulte Sobre as ComputeClasses do GKE.

Visão geral do ComputeClasses

No GKE, uma ComputeClass é um perfil que consiste em um conjunto de atributos de nó que o GKE usa para provisionar os nós que executam suas cargas de trabalho durante eventos de escalonamento automático. As ComputeClasses podem ter otimizações específicas, como provisionar nós de alto desempenho ou priorizar configurações otimizadas para custos mais baixos. Com as ComputeClasses personalizadas, é possível definir perfis que o GKE usa para escalonar automaticamente nós e atender aos requisitos de cargas de trabalho específicas.

As ComputeClasses personalizadas estão disponíveis para uso no modo Autopilot e GKE Standard 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á ComputeClasses personalizadas disponíveis para configurar e usar em todos os clusters do GKE qualificados por padrão.

Benefícios das ComputeClasses personalizadas

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

  • Prioridades de computação substitutas: defina uma hierarquia de configurações de nós em cada ComputeClass 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.
  • ComputeClasses personalizados padrão: defina um ComputeClass personalizado como o padrão para um cluster inteiro ou para namespaces específicos do Kubernetes, para que as cargas de trabalho sejam executadas em hardware otimizado, mesmo que não solicitem um ComputeClass específico.
  • 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 ComputeClasses personalizadas

Considere usar 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 ou TPU.
  • 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.
  • Você quer especificar centralmente quais das suas reservas de capacidade do Compute Engine o GKE deve usar para provisionar novos nós para cargas de trabalho específicas.
  • Você quer especificar uma política de posicionamento compacto para usar com o Autopilot do GKE. Para mais detalhes, consulte posicionamento compacto.

Como as classes de computação personalizadas funcionam

As ComputeClasses personalizadas são recursos personalizados do Kubernetes que provisionam infraestrutura doGoogle Cloud . Você define um objeto ComputeClass no cluster e solicita essa ComputeClass em cargas de trabalho ou a define como padrão para um namespace do Kubernetes. Quando uma carga de trabalho correspondente exige uma nova infraestrutura, o GKE provisiona novos nós de acordo com as prioridades definidas na definição de ComputeClass.

Os atributos definidos nas ComputeClasses definem como o GKE configura novos nós para executar cargas de trabalho. Quando você modifica uma ComputeClass, todos os nós futuros que o GKE criar para essa ComputeClass usam a configuração modificada. O GKE não muda retroativamente a configuração dos nós atuais para corresponder às suas modificações.

As ComputeClasses personalizadas influenciam as decisões de escalonamento automático, mas não são consideradas pelo kube-scheduler. Durante o agendamento de pods, o programador pode não priorizar nós com prioridades mais altas de ComputeClass personalizadas, mesmo quando nós atuais estão disponíveis em várias prioridades.

Para garantir que suas ComputeClasses 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 ComputeClass. Por exemplo, uma ComputeClass 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 em cada ComputeClass para que as cargas de trabalho sempre sejam 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 C3.

Confira a definição completa do recurso personalizado

Para conferir a definição de recurso personalizado (CRD) mais recente do recurso personalizado ComputeClass, incluindo todos os campos e as relações deles, consulte a documentação de referência do ComputeClass.

Também é possível conferir o CRD no cluster executando o seguinte comando:

kubectl describe crd computeclasses.cloud.google.com

Planejar uma ComputeClass personalizada

Para planejar, implantar e usar uma ComputeClass personalizada no cluster, siga estas etapas:

  1. Escolha suas prioridades de computação substitutas: defina uma série de regras que controlam as propriedades dos nós que o GKE cria para a ComputeClass.
  2. Configure pools de nós do GKE Standard e ComputeClasses: para clusters no modo padrão, realize as etapas de configuração necessárias para usar a ComputeClass 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.
  6. Consumir reservas do Compute Engine: opcionalmente, diga ao GKE para consumir as reservas zonais do Compute Engine ao criar novos nós.

Escolher as prioridades de computação substitutas

A principal vantagem de usar uma ComputeClass 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 ComputeClass 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.

Diferentes séries de máquinas do Compute Engine oferecem suporte a tecnologias e recursos diferentes. As gerações anteriores de uma série de máquinas podem não ser compatíveis com os mesmos tipos de armazenamento que as gerações mais recentes. Se você executar cargas de trabalho com estado que dependem de dados permanentes, evite usar uma ComputeClass que abranja várias gerações de uma série de máquinas. As cargas de trabalho talvez não consigam acessar os dados permanentes se o GKE as colocar em um tipo de máquina que não seja compatível com esse tipo de armazenamento. Para mais detalhes, filtre a tabela de comparação de séries de máquinas para tipos de armazenamento específicos.

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.

Há dois tipos de regras de prioridade:

  • Tipos de regras declarativas: use características de nós para descrever os nós que você quer provisionar.

  • Tipo de regra do pool de nós: nos clusters do GKE Standard, fornece uma lista de pools de nós criados manualmente que estão associados à ComputeClass em que o GKE precisa provisionar nós.

Regras de prioridade declarativas

Com regras de prioridade declarativas, é possível especificar propriedades da máquina, como família ou tipo de máquina, VMs spot, opções de acelerador, opções de armazenamento, reservas e requisitos mínimos de recursos, para que o GKE use ao provisionar nós. Para conferir o conjunto completo de campos aceitos, consulte a referência do CRD ComputeClass.

Configurações de machineFamily

O campo machineFamily aceita uma da série de máquinas do Compute Engine, como n4 ou c4. Se não for especificado, o padrão será e2.

É possível usar outros campos de spec.priorities junto com o campo machineFamily para definir de forma declarativa os requisitos de computação. Por exemplo:

  • 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.
  • storage.secondaryBootDisks: discos permanentes usados para pré-carregar nós do GKE com dados, como um modelo de aprendizado de máquina (ML) ou uma imagem de contêiner. Requer a versão 1.31.2-gke.1105000 ou mais recente do GKE. Para configurar um disco de inicialização secundário para o cluster usar, consulte Configurar discos de inicialização secundários.
    • storage.secondaryBootDisks.diskImageName: o nome da imagem de disco a ser pré-carregada.
    • storage.secondaryBootDisks.project: o nome do projeto que contém a imagem do disco. Se esse valor não for especificado, o padrão será o projeto do cluster.
    • storage.secondaryBootDisks.mode: o modo em que o disco de inicialização secundário será usado. Se esse valor for definido como CONTAINER_IMAGE_CACHE, o disco de inicialização secundário será usado como um cache de imagem de contêiner. O valor precisa ser igual a CONTAINER_IMAGE_CACHE ou MODE_UNSPECIFIED. Se esse valor não for especificado, o padrão será MODE_UNSPECIFIED.
  • placement: os detalhes do posicionamento da máquina:

O exemplo a seguir mostra uma regra de prioridade que usa machineFamily:

priorities:
- machineFamily: n4
  spot: true
  minCores: 16
  minMemoryGb: 64
  storage:
    bootDiskKMSKey: projects/example/locations/us-central1/keyRings/example/cryptoKeys/key-1
    secondaryBootDisks:
    - diskImageName: pytorch-mnist
      project: k8s-staging-jobset
Configurações de machineType

O campo machineType aceita um tipo de máquina predefinido do Compute Engine, como n4-standard-32, ou uma string de tipo de máquina personalizada, como n4-custom-8-20480. O uso de tipos de máquina personalizados requer o GKE versão 1.33.2-gke.1111000 ou mais recente.

É possível especificar outros campos spec.priorities junto com o campo machineType para definir de forma declarativa os requisitos de computação. Por exemplo:

  • spot: usar VMs do Spot O padrão é false.
  • storage: configurar o armazenamento do nó.
    • storage.bootDiskType: tipo de disco de inicialização. No Autopilot, apenas o tipo pd-balanced de bootDiskType é compatível.
    • 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.

O exemplo a seguir mostra uma regra de prioridade que usa machineType para provisionar tipos de máquina n4-standard-32:

priorities:
- machineType: n4-standard-32
  spot: true
  storage:
    bootDiskType: pd-balanced
    bootDiskSize: 250
    localSSDCount: 2
    bootDiskKMSKey: projects/example/locations/us-central1/keyRings/example/cryptoKeys/key-1
Configuração da GPU

Para selecionar GPUs nas suas regras de prioridade, especifique o tipo, a contagem e driverVersion (opcional) da GPU no campo gpu de uma regra de prioridade. Os seguintes campos são compatíveis:

Também é possível especificar outros spec.priorities campos, como VMs spot, opções de armazenamento e reservas em combinação com os campos gpu.

O exemplo a seguir mostra uma regra para GPUs:

priorities:
- gpu:
    type: nvidia-l4
    count: 1
  storage:
    secondaryBootDisks:
    - diskImageName: big-llm
      project: k8s-llm
  spot: true
Configuração de TPU

Requer GKE versão 1.31.2-gke.1518000 ou mais recente

Para selecionar TPUs nas regras de prioridade, especifique o tipo, a contagem e a topologia da TPU no campo tpu de uma regra de prioridade. Os seguintes campos são obrigatórios:

Você também pode especificar outros campos spec.priorities junto com o campo tpu na sua regra de prioridade, por exemplo:

  • 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 a criptografia do disco de inicialização.
    • storage.bootDiskSize: tamanho do disco de inicialização de nós em GB.
  • reservations: use uma reserva do Compute Engine. Para mais detalhes, consulte a seção Consumir reservas do Compute Engine.

O exemplo a seguir mostra uma regra para TPUs:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: tpu-class
spec:
  priorities:
  - tpu:
      type: tpu-v5p-slice
      count: 4
      topology: 4x4x4
    reservations:
      specific:
      - name: tpu-reservation
        project: reservation-project
      affinity: Specific
  - spot: true
    tpu:
      type: tpu-v5p-slice
      count: 4
      topology: 4x4x4
  nodePoolAutoCreation:
    enabled: true

Este exemplo define o seguinte comportamento de substituição:

  1. O GKE tenta provisionar uma fatia de TPU v5p de vários hosts de 16 nós consumindo uma reserva compartilhada do Compute Engine chamada tpu-reservation do projeto reservation-project.
  2. Se a reserva não tiver TPUs disponíveis, o GKE tentará provisionar uma fração de TPU v5p de vários hosts com 16 nós executada em VMs do Spot.
  3. 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.

Depois de implantar uma ComputeClass personalizada de TPU no cluster, selecione essa ComputeClass personalizada na carga de trabalho:

Além disso, para cargas de trabalho de TPU, é possível fazer o seguinte:

Especificações de aceleradores e formatos de máquina

As configurações declarativas de acelerador não exigem que o campo machineType ou machineFamily seja especificado explicitamente, a menos que você os use em combinação com reservas.

Regras de prioridade do pool de nós

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 usar outros campos de spec.priorities com o campo nodepools no mesmo item de regra de prioridade porque as regras com o campo nodepools não são declarativas. Esse campo é compatível apenas com o modo GKE Standard. Para detalhes de uso, consulte Segmentar pools de nós específicos em uma definição de ComputeClass.

Como o GKE cria nós usando regras de prioridade

Quando você implanta uma carga de trabalho que solicita uma ComputeClass 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: n4
    spot: true
    minCores: 64
  - machineFamily: n4
    spot: true
  - machineFamily: n4
    spot: false

Quando você implanta uma carga de trabalho que solicita uma ComputeClass 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 ComputeClass.
  2. Se os nós atuais não puderem acomodar os pods, o GKE provisiona que usam a série de máquinas N4, são VMs spot e pelo menos 64 vCPUs.
  3. Se as VMs spot N4 com pelo menos 64 vCPUs não estiverem disponíveis região, o GKE provisiona novos nós que usam N4 VMs spot que podem se encaixar nos pods, independente do número de núcleos
  4. Se não houver VMs N4 do Spot disponíveis na região, o GKE provisionará novas VMs N4 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.

Valores padrão para regras de prioridade

É possível definir valores padrão para alguns dos campos nas regras de prioridade da especificação ComputeClass. Esses valores padrão são aplicados se os campos correspondentes em uma regra específica forem omitidos. É possível definir esses valores padrão usando o campo priorityDefaults na especificação ComputeClass.

O campo priorityDefaults tem as seguintes limitações:

  • exige a versão 1.32.1-gke.1729000 ou mais recente do GKE;
  • Não é compatível com a regra de prioridade nodepools, que não contém campos.

Para detalhes sobre os tipos de valores padrão que podem ser definidos, consulte a seção priorityDefaults na CustomResourceDefinition ComputeClass.

Pools de nós do GKE Standard e ComputeClasses

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

Configurar pools de nós criados manualmente para uso da ComputeClass

Se os clusters do GKE Standard tiverem pools de nós que você criados manualmente, eles precisam ser configurados para associá-los a ComputeClasses específicos. O GKE só programa pods que solicitam uma ComputeClass específica em nós em pools de nós que você associa a essa ComputeClass. Esse requisito não se aplica a uma ComputeClass que você configura como o padrão no nível do cluster.

O modo Autopilot do GKE e os pools de nós criados automaticamente no modo GKE Standard fazem essa configuração para você.

Para associar um pool de nós criado manualmente a uma ComputeClass, 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 da sua ComputeClass personalizada.

Por exemplo, os comandos a seguir atualizam um pool de nós e o associam à ComputeClass dev-class:

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

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

É possível associar cada pool de nós no cluster a uma ComputeClass 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.

Criação automática de pool de nós e ComputeClasses

É possível usar a criação automática de pool de nós com uma ComputeClass personalizada para permitir que o GKE crie e exclua pools de nós automaticamente com base nas regras de prioridade.

Para permitir que o GKE crie automaticamente pools de nós para uma ComputeClass, faça o seguinte:

  1. Adicione o campo nodePoolAutoCreation com o valor enabled: true à sua especificação ComputeClass.
  2. A menos que seu cluster esteja inscrito no canal Rápido e executando a versão 1.33.3-gke.1136000 ou mais recente do GKE, você também precisa ativar o provisionamento automático de nós no nível do cluster.

O GKE pode criar pools de nós para pods que usam sua ComputeClass. 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 ComputeClasses que não configuram a criação automática de pool de nós continuam a escalonar verticalmente apenas os pools de nós existentes.

É possível usar ComputeClasses que ativam a criação automática de pool de nós com ComputeClasses que interagem com pools de nós criados manualmente no mesmo cluster.

Considere as seguintes interações com a criação automática de pool 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 ComputeClass. O GKE rejeita pods que solicitam uma ComputeClass e também VMs do Spot ou séries de máquinas específicas.

  • Se você definir uma ComputeClass padrão para seu cluster, os pods que usam um seletor de nós de família de máquinas só vão acionar a criação de nós para essa classe padrão em uma das seguintes situações:

    • Os pods selecionam uma família de máquinas que corresponde a uma das regras de prioridade na classe padrão no nível do cluster. Por exemplo, um pod que seleciona instâncias N4 aciona a criação de nós se a classe padrão no nível do cluster tiver uma regra de prioridade para instâncias N4.
    • A ComputeClass padrão no nível do cluster tem o valor ScaleUpAnyway no campo spec.whenUnsatisfiable. Mesmo que os pods selecionem uma família de máquinas que não esteja nas prioridades da ComputeClass, o GKE criará novos nós com essa família.

    Os pods que selecionam uma família de máquinas que não está nas prioridades de classe padrão no nível do cluster não acionam a criação de nós se o ComputeClass tiver um valor de DoNotScaleUp no campo whenUnsatisfiable.

  • É possível configurar a criação automática de pool de nós para ComputeClasses que usam o campo nodepools para fazer referência a pools de nós atuais. O GKE 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 criação automática de pool de nós:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - nodepools: [manually-created-pool]
  - machineFamily: n4
  - machineFamily: c4
  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 N4, seja em pools de nós N4 existentes ou criando um novo no pool de nós.
  3. Se o GKE não puder criar nós N4, ele tentará escalonar verticalmente pools de nós C4 existentes ou criar novos pools de nós C4.

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

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 ComputeClass com pools de nós nomeados, o GKE tenta programar os pods pendentes nesses pools de nós. 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 associados a essa ComputeClass usando rótulos e taints de nó, conforme descritas na Seção Configurar pools de nós criados manualmente para ComputeClasses.

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 ComputeClass em nós existentes em pools de nós rotulados com a ComputeClass. 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. Nas versões do GKE anteriores à 1.33, esse é o comportamento padrão se você omitir esse campo.

    O GKE realiza uma das seguintes ações:

    • 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 a criação automática de pools 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 ComputeClass.
    • Nos clusters padrão que usam a criação automática de pools 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 atenda aos requisitos da ComputeClass esteja disponível. No GKE versão 1.33 e mais recentes, esse é o comportamento padrão se você omitir esse campo.

Solicitar uma política de posicionamento

A partir da versão 1.33.2-gke.1335000 do GKE, em clusters do GKE Autopilot, é possível usar o posicionamento compacto com uma política de posicionamento ou de carga de trabalho personalizada. Para mais informações, consulte Comparação entre a política de posicionamento compacto e a política de carga de trabalho.

As políticas de posicionamento e de carga de trabalho colocam os nós fisicamente próximos uns dos outros para reduzir a latência da rede. Para usar uma política específica, informe o nome dela em um campo policyName. A política precisa ser uma política de recursos do Compute Engine que já existe no projeto do GKE.

Veja o exemplo a seguir.

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - machineFamily: n4
    placement:
      policyName: my-placement-policy
  nodePoolAutoCreation:
    enabled: true

Nessa configuração, o GKE aplica a política de posicionamento compacto a todas as cargas de trabalho que usam essa ComputeClass e provisiona os nós de acordo com a política de recursos atual chamada my-placement-policy.

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 ComputeClasses, esse é o comportamento padrão, porque todos os clusters que usam ComputeClasses precisam usar o escalonador automático de clusters ou são clusters do Autopilot. 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 a remoção de nós e a consolidação de cargas de trabalho usando a seção autoscalingPolicy na definição personalizada de ComputeClass. É 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: n4
  - machineFamily: c4
  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%.

Migração ativa

A migração ativa é um recurso opcional de escalonamento automático em ComputeClasses personalizadas que substitui automaticamente os nós atuais por novos nós. Os nós são substituídos com base em determinados critérios, dependendo do tipo de migração.

Quando uma migração ativa ocorre, o GKE cria novos nós e, em seguida, drena e exclui os nós 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 não migra dados armazenados em armazenamento permanente, como discos permanentes do Compute Engine. Para minimizar o risco de perda de dados, não ative a migração ativa em ComputeClasses usadas por cargas de trabalho com estado.
  • 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 definidos na classe de computação personalizada.
  • A migração ativa não substitui nós que não podem ser removidos. Por exemplo, a migração ativa não substitui um nó se isso violar a configuração --min-nodes do pool de nós.
  • 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".
  • As cargas de trabalho que usam volumes permanentes com recursos zonais, como o Hyperdisk, talvez não funcionem bem com a migração ativa. Restrições zonais e de tipo de máquina de alguns produtos do Hyperdisk podem reduzir a eficácia da migração ativa. Além disso, algumas cargas de trabalho com estado podem não tolerar a interrupção causada pela migração ativa.
  • Se você atualizar uma ComputeClass para ativar a migração ativa, o GKE vai migrar os pods atuais para novos nós ao longo do tempo.

Os seguintes tipos de migração ativa são compatíveis:

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

É possível configurar a migração ativa para substituir os nós atuais que estão mais abaixo em uma lista de prioridade de fallback de ComputeClass por novos nós que estão mais acima nessa lista. Essa configuração ajuda a garantir que todos os pods em execução sejam executados nos nós mais preferidos para essa ComputeClass, mesmo que o GKE tenha que executar esses pods em nós menos preferidos.

Considere o seguinte exemplo de especificação de ComputeClass, que prioriza nós N4 em nós C4:

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

Se os nós N4 estivessem indisponíveis quando você implantou um pod com essa ComputeClass, o GKE teria usado os nós C4 como uma opção alternativa. Se nós N4 ficarem disponíveis para provisionamento posterior, por exemplo, se a cota aumentar ou se as VMs N4 ficarem disponíveis no seu local, o GKE vai criar um nó N4 e migrar gradualmente o pod do nó C4 atual para o novo nó N4. O GKE exclui o nó C4 obsoleto.

Configurar a migração ativa para executar pods DaemonSet não programáveis

É possível configurar a migração ativa para substituir automaticamente os nós atuais que têm pods do DaemonSet não programáveis por nós maiores capazes de executar todos os pods do DaemonSet necessários.

Considere o seguinte exemplo de especificação ComputeClass:

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

Por exemplo, se a implantação de um pod com essa ComputeClass causou o escalonar verticalmente de uma máquina n1-standard-2, e você implantou um DaemonSet que solicita duas CPUs, a migração ativa vai substituir o nó n1-standard-2 por um maior da mesma família de máquinas n1, como um n1-standard-4, para criar espaço suficiente para todos os pods.

Consumir reservas do Compute Engine

Disponível no GKE versão 1.31.1-gke.2105000 e mais recentes

Se você usa reservas de capacidade do Compute Engine para ter um nível mais alto de garantia de disponibilidade de hardware emGoogle Cloud zonas específicas, configure cada prioridade de substituição na sua ComputeClass personalizada para que o GKE consuma reservas ao criar novos nós.

O consumo de reservas em ComputeClasses personalizadas tem os seguintes requisitos:

  • É necessário usar a criação automática de pool de nós para que o GKE use reservas para criar novos nós. Para mais informações, consulte a seção Criação automática de pools de nós e ComputeClasses. Você também pode continuar consumindo reservas ao criar manualmente pools de nós no cluster.
  • Reservas que não são de TPU só podem ser usadas quando machineType ou machineFamily estão definidos.
  • As ComputeClasses que configuram SSDs locais precisam usar a regra de prioridade machineType, não machineFamily. Para mais detalhes, consulte a seção tipo de regra machineType.
  • As ComputeClasses que especificam reservas para um machineType com SSDs locais anexados precisam incluir um campo localSSDCount: explicitamente.

Considere o exemplo a seguir de especificação de ComputeClass, que prioriza uma reserva compartilhada específica para uso ao provisionar instâncias do a3-highgpu-1g. Se os tipos de instância priorizados não estiverem disponíveis, o GKE vai usar qualquer reserva correspondente na especificação:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: accelerator-reservations
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - machineType: a3-highgpu-1g
    storage:
      localSSDCount: 2
    gpu:
      type: nvidia-h100-80gb
      count: 1
    reservations:
      specific:
      - name: a3-shared-reservation
        project: reservation-project
      affinity: Specific
  - machineType: a3-highgpu-1g
    storage:
      localSSDCount: 2
    gpu:
      type: nvidia-h100-80gb
      count: 1
    reservations:
      affinity: AnyBestEffort
  whenUnsatisfiable: DoNotScaleUp

Se você implantar um pod que usa a ComputeClass accelerator-reservations, o GKE primeiro tenta usar a reserva a3-shared-reservation ao criar novas instâncias a3-highgpu-1g para executar o pod. Se essa reserva específica não tiver capacidade disponível, o GKE tentará escalonar as instâncias a3-highgpu-1g usando qualquer reserva correspondente. Se nenhuma reserva estiver acessível, o GKE vai usar as VMs do Spot a3-highgpu-1g. Por fim, se nenhuma VM spot estiver disponível, a operação de escalonamento vai falhar.

Neste exemplo, as duas regras de prioridade com referências de reserva exigem explicitamente o campo localSSDCount: porque o formato de máquina a3-highgpu-1g inclui SSDs locais.

O exemplo a seguir mostra uma reserva específica compartilhada, que volta para VMs Spot e, finalmente, para VMs sob demanda:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: shared-specific-reservations
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - machineFamily: n4
    reservations:
      specific:
      - name: n4-shared-reservation
        project: reservation-project
      affinity: Specific
  - machineFamily: n4
    spot: true
  - machineFamily: n4
  whenUnsatisfiable: DoNotScaleUp

É possível consumir os seguintes tipos de reservas:

  • Reservas específicas de projeto único: configure os seguintes campos:

    • reservations.specific.name: o nome da reserva.
    • reservations.affinity: precisa ser Specific.

  • Reservas compartilhadas específicas: configure os seguintes campos:

    • reservations.specific.name: o nome da reserva.
    • reservations.specific.project: o ID do projeto que tem a reserva.
    • reservations.affinity: precisa ser Specific.

  • Todas as reservas correspondentes: configure os seguintes campos:

    • reservations.affinity: precisa ser AnyBestEffort.
    • Não defina um nome de reserva ou projeto.

As reservas de TPU exigem afinidade específica. reservations.affinity: AnyBestEffort não é compatível.

Se o GKE não encontrar capacidade disponível em uma reserva, o comportamento resultante vai depender do tipo de reserva selecionado na regra de prioridade da ComputeClass, da seguinte forma:

  • Reservas específicas: o GKE tenta a próxima regra de prioridade na ComputeClass.
  • Reservas correspondentes: o GKE tenta provisionar um nó sob demanda que atenda aos requisitos dessa regra de prioridade. Se o GKE não conseguir provisionar um nó sob demanda, ele tentará a próxima regra de prioridade na ComputeClass.

Se o GKE não atender aos requisitos de nenhuma das regras de prioridade para a ComputeClass, o comportamento quando nenhuma regra se aplica vai ocorrer.

Consumir blocos de reserva específicos

A partir da versão 1.31.4-gke.1072000 do GKE, é possível segmentar um bloco de reserva específico em uma reserva com suporte de hardware. Esse recurso está disponível para os tipos de máquina A3 Ultra e A4.

Para consumir um bloco de reserva específico, configure o recurso ComputeClass conforme mostrado neste exemplo:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: specific-reservations
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - machineFamily: a3
    gpu:
      type: nvidia-h200-141gb
      count: 8
    reservations:
      specific:
      - name: a3ultra-specific-reservation
        reservationBlock:
          name: RESERVATION_BLOCK_NAME
      affinity: Specific

Substitua RESERVATION_BLOCK_NAME pelo nome do bloco de reserva de destino.

A partir da versão 1.33.1-gke.1788000 do GKE, é possível segmentar um subbloco específico em um bloco de reserva. Esse recurso está disponível para o tipo de máquina A4X.

Para consumir um sub-bloco de reserva específico, configure o recurso ComputeClass conforme mostrado no exemplo em Consumir sub-blocos de reserva específicos.

Ao usar esse recurso, considere o seguinte:

  • Esses recursos se aplicam apenas a reservas específicas em um projeto único ou compartilhado.

Personalizar a configuração do sistema de nós

É possível personalizar determinados parâmetros no kubelet e no kernel do Linux usando o campo nodeSystemConfig na especificação da ComputeClass. É possível especificar esse campo em qualquer regra de prioridade que defina uma série ou um tipo de máquina do Compute Engine. Também é possível definir valores globais padrão para qualquer campo de configuração do sistema de nós omitido nas regras de prioridade adicionando o campo nodeSystemConfig ao campo priorityDefaults na sua ComputeClass.

Esse recurso está disponível na versão 1.32.1-gke.1729000 e mais recentes do GKE.

Para mais informações, consulte as seguintes páginas:

ComputeClasses padrão para clusters e namespaces

É possível configurar o GKE para aplicar uma ComputeClass por padrão a pods que não selecionam uma ComputeClass específica. É possível definir uma ComputeClass padrão para namespaces específicos ou para um cluster inteiro. Para mais informações sobre como configurar clusters ou namespaces com uma classe padrão, consulte Aplicar ComputeClasses a pods por padrão.

Agrupar pools de nós

A partir da versão 1.32.2-gke.1359000 do GKE, é possível agrupar vários pools de nós em uma única unidade lógica chamada coleção usando o campo nodePoolGroup na especificação ComputeClass. Com esse agrupamento, é possível aplicar configurações compartilhadas a vários pools de nós.

Coleção de vários hosts de TPU

É possível agrupar sua implantação de vários hosts de TPU para definir um objetivo de nível de serviço (SLO) em todos os pools de nós da coleção. Para agrupar pools de nós, especifique o nome do grupo no campo nodePoolGroup. Todos os pools de nós provisionados usando essa ComputeClass pertencem ao mesmo grupo.

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: tpu-multi-host-collection
spec:
  nodePoolGroup:
    name: my-tpu-collection
  ...

Para ver mais informações, consulte os seguintes tópicos:

Configuração do pool de nós

O campo nodePoolConfig na especificação ComputeClass permite aplicar configurações que são refletidas em todos os nós nos pools de nós criados usando essa classe.

Especificar o tipo de imagem

É possível especificar o sistema operacional de base para os nós no pool de nós usando o campo imageType. Com esse campo, é possível escolher um tipo de imagem para os pools de nós que serão executados nos nós. Se você omitir esse campo, o valor padrão será cos_containerd. O exemplo a seguir mostra como especificar o imageType na sua ComputeClass:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-node-pool-config
spec:
  nodePoolConfig:
    imageType: cos_containerd

Para mais informações, consulte Imagens de nó.

Conta de serviço

O campo serviceAccount especifica a conta de serviço Google Cloud usada pelos nós nos pools de nós gerenciados pela ComputeClass. O exemplo a seguir mostra como especificar o serviceAccount na sua ComputeClass:

spec:
  nodePoolConfig:
    serviceAccount: my-service-account@my-project.iam.gserviceaccount.com

Para mais informações, consulte Sobre as contas de serviço no GKE.

Definir o tipo de carga de trabalho para o SLO da TPU

A partir da versão 1.32.2-gke.1359000 do GKE, é possível definir o objetivo de nível de serviço (SLO) para suas cargas de trabalho de TPU usando o campo workloadType em nodePoolConfig. O valor nesse campo informa ao GKE o uso pretendido dos recursos de TPU. O campo workloadType aceita os seguintes valores:

  • HIGH_AVAILABILITY: use esse valor para cargas de trabalho focadas na disponibilidade, como veiculação de inferência, para limitar e simplificar as interrupções.
  • HIGH_THROUGHPUT: use esse valor para jobs de treinamento ou em lote que exigem que toda a infraestrutura subjacente seja executada na maior parte do tempo para progredir. Esse valor só pode ser usado quando nodePoolGroup também é especificado.

O exemplo a seguir define uma ComputeClass para uma coleção de TPUs de vários hosts otimizada para cargas de trabalho de inferência de alta disponibilidade.

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: multi-host-inference
spec:
  nodePoolGroup:
    name: my-inference-collection
  nodePoolConfig:
    workloadType: HIGH_AVAILABILITY
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - tpu:
      type: tpu-v6e-slice
      topology: 2x4

Para mais informações, consulte as seguintes páginas:

Solicitar ComputeClasses em cargas de trabalho

Para usar uma ComputeClass personalizada, seu pod precisa solicitar explicitamente essa ComputeClass usando um nodeSelector na especificação do pod. Você pode definir uma ComputeClass como padrão para um namespace específico do Kubernetes. Os pods nesse namespace usam essa ComputeClass, a menos que solicitem uma ComputeClass diferente.

Por exemplo, o manifesto a seguir solicita a ComputeClass cost-optimized:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: custom-workload
spec:
  replicas: 2
  selector:
    matchLabels:
      app: custom-workload
  template:
    metadata:
      labels:
        app: custom-workload
    spec:
      nodeSelector:
        cloud.google.com/compute-class: cost-optimized
      containers:
      - name: test
        image: gcr.io/google_containers/pause
        resources:
          requests:
            cpu: 1.5
            memory: "4Gi"

Seletores de nós para rótulos de nós do sistema

O GKE adiciona rótulos do sistema aos nós para identificá-los por critérios como o tipo de máquina, aceleradores de hardware conectados ou o tipo de disco de inicialização. Esses rótulos do sistema têm um dos seguintes prefixos na chave do rótulo:

  • k8s.io
  • cloud.google.com
  • gke.io

No GKE versão 1.32.3-gke.1499000 e mais recentes, é possível implantar cargas de trabalho que usam um seletor de nós para selecionar rótulos do sistema e uma ComputeClass ao mesmo tempo. Se você selecionar rótulos do sistema em pods que selecionam ComputeClasses, verifique se esses pods são programados conforme esperado. Um conflito entre a configuração de uma ComputeClass e os seletores de nós em um pod pode resultar em problemas como os seguintes:

  • O GKE não pode criar nós que usam a configuração de maior prioridade para a ComputeClass.
  • O pod permanece no status Pending.

O GKE também rejeita pods que selecionam rótulos do sistema com um campo correspondente na especificação ComputeClass. Ao usar ComputeClasses, atualize as cargas de trabalho para remover os seguintes rótulos dos seletores de nós e configure o campo correspondente nas ComputeClasses que você criar:

Marcador do nó Campo ComputeClass
cloud.google.com/machine-family priorities.machineFamily
cloud.google.com/machine-type priorities.machineType
cloud.google.com/gke-spot priorities.spot
cloud.google.com/gke-accelerator priorities.gpu.type
cloud.google.com/gke-gpu-driver-version priorities.gpu.driverVersion
cloud.google.com/reservation-name priorities.reservations.specific.name
cloud.google.com/reservation-project priorities.reservations.specific.project
cloud.google.com/reservation-affinity priorities.reservations.affinity
cloud.google.com/gke-ephemeral-storage-local-ssd priorities.storage.localSSDCount
cloud.google.com/gke-boot-disk priorities.storage.bootDiskType
cloud.google.com/gke-boot-disk-size priorities.storage.bootDiskSize
cloud.google.com/gke-node-pool-group-name nodePoolGroup.name
cloud.google.com/gke-workload-type nodePoolConfig.workloadType

Limitações

O nome da sua ComputeClass não pode começar com gke ou autopilot.

A seguir