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 das 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 de custo otimizado para reduzir custos operacionais. Com as ComputeClasses personalizadas, é possível definir perfis que o GKE usa para escalonar automaticamente nós que atendem 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. As ComputeClasses personalizadas estão disponíveis para configurar e usar em todos os clusters do GKE qualificados por padrão.

Benefícios das ComputeClasses personalizadas

As ComputeClasses personalizadas oferecem os seguintes benefícios:

  • Prioridades de computação substitutas: definir 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 ajuda a garantir que, mesmo quando os recursos de computação estiverem indisponíveis, as cargas de trabalho ainda sejam 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 spot, para reduzir as despesas do cluster.
  • ComputeClasses personalizadas padrão: defina uma ComputeClass personalizada como 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 uma ComputeClass específica.
  • Limites personalizados de consolidação de nós: defina limites personalizados de uso de recursos 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 escala vertical o nó subutilizado.
  • Capacidade mínima declarativa: mantenha um número mínimo de nós dessa ComputeClass no cluster de forma proativa, o que ajuda a garantir que a capacidade esteja disponível para cargas de trabalho críticas.

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 determinadas séries de máquinas do Compute Engine 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 ComputeClasses 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 altera 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 a programação de pods, o programador pode não priorizar nós com prioridades de ComputeClass personalizadas mais altas, mesmo quando os nós existentes 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 desempenho pode ter uma estratégia alternativa que usa apenas tipos de máquina com grande quantidade de CPUs.
  • Escolha a família de máquinas 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 substituição dentro de 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 suas relações, consulte a documentação de referência do ComputeClass.

Você também pode visualizar 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 que o GKE cria para a ComputeClass.
  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 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: se quiser, instrua o GKE a consumir as reservas zonais do Compute Engine ao criar novos nós.
  7. Provisione um número mínimo de nós: opcionalmente, diga ao GKE para manter uma contagem mínima de nós no cluster.

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 no campo priorities na especificação ComputeClass. Cada regra de prioridade pode solicitar nós de uma das seguintes maneiras:

  • Propriedades do nó: defina as propriedades dos nós em que você quer que os pods sejam executados, como as famílias de máquinas a serem usadas. Quando um pod aciona uma operação de escalonamento vertical, o GKE tenta criar um nó que tenha essas propriedades. Cada regra de prioridade precisa especificar um tipo de hardware a ser provisionado, conforme descrito na seção Propriedades de nó de nível superior para regras de prioridade.

  • Seleção de pools de nós: em clusters do GKE Standard, especifique os nomes dos pools de nós atuais para associar à ComputeClass. Quando um pod aciona uma operação de escalonamento vertical, o GKE tenta colocar o pod nesses pools de nós. As regras de prioridade que selecionam pools de nós não aceitam outros campos. Para mais informações, consulte a seção Pools de nós do GKE Standard e ComputeClasses.

Por padrão, quando um novo nó é necessário para um pod de entrada que seleciona uma ComputeClass, o GKE tenta criar nós na ordem em que as regras de prioridade aparecem no manifesto da ComputeClass. No GKE versão 1.35.2-gke.1842000 e mais recentes, também é possível definir explicitamente uma pontuação para cada regra de prioridade em uma ComputeClass usando o campo priorityScore. Nesse caso, o GKE processa regras em ordem da pontuação mais alta para a mais baixa. Se todas as regras de prioridade em uma ComputeClass forem esgotadas, o GKE vai criar nós com base no comportamento descrito em Definir o comportamento de escalonamento quando nenhuma regra de prioridade for aplicada.

Pontuações de regras de prioridade

Requer o GKE versão 1.35.2-gke.1842000 ou posterior.

Para ter controle granular sobre a ordem em que o GKE processa regras de prioridade para uma ComputeClass, use o campo priorityScore nas regras. Durante o escalonamento, o GKE processa as regras de prioridade com base na pontuação, com valores de pontuação maiores tendo uma prioridade maior do que valores menores.

O campo priorityScore tem as seguintes propriedades:

  • O campo aceita um valor inteiro com um valor mínimo de 1 e um valor máximo de 1000.
  • Você precisa usar o campo priorityScore em todas as suas regras de prioridade ou em nenhuma delas.

  • É possível definir a mesma pontuação de prioridade para até três regras diferentes. Durante o escalonamento, o GKE processa as regras que têm a mesma pontuação juntas. O GKE escolhe uma regra específica para usar com base nos critérios operacionais do escalonador automático de cluster.

    As regras agrupadas podem aumentar a latência do escalonamento automático, porque o GKE precisa executar mais simulações para determinar a configuração ideal do nó. A probabilidade de você notar um aumento na latência depende da abrangência da seleção de hardware na regra, da seguinte forma:

    • Regras com um escopo amplo, como a propriedade machineFamily, têm maior probabilidade de contribuir para um pequeno aumento na latência do escalonamento automático. No entanto, é mais provável que o GKE encontre hardware disponível que atenda aos requisitos dessas regras.
    • Regras com um escopo restrito, como a propriedade machineType, têm menos probabilidade de contribuir para um aumento na latência. No entanto, é mais provável que o GKE não consiga encontrar hardware disponível que atenda aos requisitos dessas regras.

O exemplo a seguir mostra uma ComputeClass que define pontuações de regras de prioridade:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: priority-rule-score-class
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  # Highest priority score in the ComputeClass
  - machineFamily: e2
    spot: true
    priorityScore: 30
  # Grouped priority rules that have the same score.
  - machineFamily: n2
    spot: true
    priorityScore: 20
  - machineFamily: t2d
    spot: true
    priorityScore: 20
  # Lowest priority score in the ComputeClass.
  - machineFamily: n1
    spot: true
    priorityScore: 10
  whenUnsatisfiable: ScaleUpAnyway

Durante um evento de escalonamento vertical para essa ComputeClass de exemplo, o GKE faz o seguinte:

  1. O GKE tenta criar instâncias E2.
  2. Se as instâncias E2 não estiverem disponíveis, o GKE vai criar instâncias N2 ou T2D, dependendo do resultado do escalonador automático de cluster.
  3. Se as instâncias N2 e T2D não estiverem disponíveis, o GKE tentará criar instâncias N1.
  4. Se as instâncias N1 não estiverem disponíveis, o GKE vai usar a série de máquinas padrão do cluster.

Propriedades de nó de nível superior para regras de prioridade

Ao especificar regras de prioridade que definem propriedades de nós, é necessário selecionar um tipo de hardware de nível superior que você quer para os nós. As outras propriedades que podem ser especificadas para uma regra dependem da propriedade de nível superior dela.

Você pode usar qualquer uma das seguintes propriedades de nível superior para uma regra:

  • machineFamily: uma série de máquinas do Compute Engine, como n4.
  • machineType: um tipo de máquina específico do Compute Engine, como n4-standard-32.
  • gpu: uma configuração de GPU, que pode incluir um tipo de GPU, um número específico de GPUs e configuração de driver.
  • tpu: uma configuração do Cloud TPU, que pode incluir uma versão, topologia e número de chips de TPU.

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

Cada geração de série de máquinas do Compute Engine é compatível com tipos de disco específicos. Por exemplo, a série de máquinas N4 é compatível com os tipos de disco do Hyperdisk ML, mas a série de máquinas N2 não. Em ComputeClasses que abrangem várias gerações, as cargas de trabalho com estado que solicitam um tipo de disco específico podem não conseguir acessar dados permanentes se o tipo de máquina não for compatível com esse tipo de disco. Dependendo de como você cria e usa discos nas suas cargas de trabalho, use um dos seguintes métodos para reduzir o risco de dados permanentes inacessíveis:

  • Provisionamento de volume dinâmico: no GKE versão 1.35.3-gke.1290000 e mais recentes, use um StorageClass que configure a seleção automática de tipo de disco. O GKE cria um tipo de disco compatível com o tipo de máquina do nó que executa a carga de trabalho. Em versões anteriores do GKE, verifique se todas as séries de máquinas na ComputeClass são compatíveis com o tipo de disco provisionado pelas StorageClasses.

  • Discos permanentes preexistentes: verifique se todas as séries de máquinas na ComputeClass são compatíveis com os tipos de discos permanentes preexistentes.

Para mais informações sobre os tipos de disco compatíveis com cada série de máquinas, consulte a tabela de comparação de séries de máquinas.

Configurações de machineFamily

O campo machineFamily aceita qualquer série de máquinas do Compute Engine compatível com o GKE, como n2 ou c3. Se não for especificado, o padrão será e2. Quando você usa o campo machineFamily, o GKE provisiona nós dessa série com um tipo de máquina grande o suficiente para executar seus pods. O algoritmo do escalonador automático determina o tamanho mais apropriado com base nas solicitações de recursos agregadas de todos os pods pendentes. Para ter mais controle sobre o tamanho exato da máquina, use o campo machineType.

Solicitar uma família de máquinas mais ampla não provisiona tipos de máquinas bare metal. Por exemplo, solicitar c3 ou c4a não provisiona tipos de máquina como c3-standard-192-metal ou c4a-standard-72-metal, respectivamente. Como os tipos de nós bare metal exigem a solicitação de um tipo de máquina exato, não é possível usar a ComputeClass Performance predefinida do Autopilot. Em vez disso, crie uma ComputeClass personalizada e especifique o tipo de máquina exato no campo machineType. O uso de tipos de máquina bare metal c3 ou c4a com ComputeClasses, criação automática pool de nós ou modo Autopilot requer o GKE versão 1.35.3-gke.1389000 ou posterior.

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

  • spot: VMs spot. O valor padrão é false.
  • minCores: mínimo de vCPUs por nó. O valor padrão é 0. Esse campo é útil para evitar a criação de nós pequenos demais para suas necessidades.
  • minMemoryGb: memória mínima por nó. O valor padrão é 0.
  • storage.bootDiskType: tipo de disco de inicialização. Em clusters do Autopilot, apenas o tipo pd-balanced de bootDiskType é compatível. Requer o GKE versão 1.34.1-gke.1431000 ou posterior.
  • storage.bootDiskSize: tamanho do disco de inicialização de nós em GB. Requer o GKE versão 1.34.1-gke.1431000 ou posterior.
  • 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 o GKE versão 1.31.2-gke.1105000 ou posterior. 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 do 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 do 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:
  • enableNestedVirtualization: se a virtualização aninhada deve ser ativada nos nós. O valor padrão é false.

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

priorities:
- machineFamily: n4
  spot: true
  minCores: 16
  minMemoryGb: 64
  storage:
    bootDiskType: hyperdisk-balanced
    bootDiskSize: 100
    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 posterior. É possível especificar tipos de máquinas de qualquer série de máquinas compatível com o GKE.

É possível especificar outros campos spec.priorities ao lado do campo machineType para definir de maneira declarativa os requisitos de computação, por exemplo:

  • spot: use VMs 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.
  • enableNestedVirtualization: se a virtualização aninhada será ativada nos nós. O valor padrão é false.

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: hyperdisk-balanced
    bootDiskSize: 250
    localSSDCount: 2
    bootDiskKMSKey: projects/example/locations/us-central1/keyRings/example/cryptoKeys/key-1

Configuração da GPU

Para selecionar GPUs nas 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 aceitos:

  • gpu.type: um tipo de GPU, como nvidia-l4. Para mais detalhes, consulte Escolher o suporte a GPUs usando o Autopilot ou Standard.
  • gpu.count: o número de GPUs a serem anexadas. Para quantidades suportadas por Tipo de GPU, consulte Quantidades de GPU compatíveis.
  • gpu.driverVersion: a versão do driver NVIDIA a ser instalado. Precisa ser default ou latest. Requer o GKE versão 1.31.1-gke.1858000 ou posterior.
  • acceleratorNetworkProfile: o perfil de rede do acelerador para a GPU, como auto. Requer o GKE versão 1.35.2-gke.1842000 ou posterior.

Também é possível especificar outros campos de spec.priorities, 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 da TPU

Requer o GKE versão 1.31.2-gke.1518000 ou posterior

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:

Também é possível especificar outros campos spec.priorities ao lado do campo tpu na regra de prioridade, por exemplo:

  • spot: use VMs 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 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.
  • location:
    • zones: uma lista de Google Cloud zonas em que o GKE pode provisionar nós. Se não for especificado, o GKE provisionará nós nas zonas configuradas nas configurações de provisionamento automático de nós do cluster. Se nenhuma zona estiver configurada para o provisionamento automático de nós, o GKE vai provisionar nós em qualquer uma das zonas padrão usadas pelo plano de controle.

      Opcional: use uma zona de IA, como us-central1-ai1a. As zonas de IA são locais especializados e otimizados para cargas de trabalho de IA/ML em regiões do Google Cloud .

    • zoneTypes: uma lista de tipos de zona que especifica um conjunto de zonas Google Cloud em que o GKE pode provisionar nós. Os valores compatíveis são CLUSTER_DEFAULT (padrão), STANDARD e AI. Para mais informações, consulte Como usar a prioridade de zoneTypes de local.

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 com 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 vai tentar provisionar uma fração de TPU v5p de vários hosts com 16 nós em execução em VMs 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 da TPU no cluster, selecione essa ComputeClass personalizada na carga de trabalho:

Além disso, para cargas de trabalho de TPU, você pode fazer o seguinte:

Zonas de IA de destino

Também é possível usar uma classe de computação para especificar zonas de IA para seus pods. As zonas de IA são locais especializados em Google Cloud regiões otimizadas para cargas de trabalho de IA/ML. A classe de computação a seguir define uma lista de zonas priorizadas que inclui zonas de IA:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: accelerator-ai-preferred
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
    # --- Priority 1: TPU in a specific AI zone (On-Demand) ---
    - tpu:
        type: tpu-v5p-slice
        count: 4
        topology: 4x4x4
      location:
        zones:
          - "us-central1-ai1a" # Specify your target AI zone
      # machineFamily: a3 # Optional

    # --- Priority 2: TPU in any AI zone (On-Demand)  ---
    - tpu:
        type: tpu-v5p-slice
        count: 4
        topology: 4x4x4
      location:
        zoneTypes:
          - "AI" # All AI zones in the cluster's region

    # --- Priority 3: GPU in a specific Standard zone (On-Demand) ---
    - gpu:
        type: nvidia-tesla-a100
        count: 1
      location:
        zones:
          - "us-central1-a" # Fallback to a standard zone
          - "us-central1-b"
  whenUnsatisfiable: DoNotScaleUp

Essa ComputeClass configura o GKE para provisionar nós com TPUs v5p ou GPUs A100 para a carga de trabalho. Os nós têm as seguintes preferências:

  • Prioridade 1:tente provisionar a TPU na zona de IA us-central1-ai1a.
  • Prioridade 2:se a TPU não estiver disponível na zona de IA específica, tente provisioná-la em qualquer zona de IA da região do cluster.
  • Prioridade 3:se a TPU não estiver disponível nas zonas de IA, tente provisionar a GPU nas zonas padrão us-central1-a ou us-central1-b.
  • Se as GPUs A100 não estiverem disponíveis em nenhuma das zonas especificadas, o GKE não vai escalonar verticalmente o pool de nós.

Configuração de rede DRANET

Requer o GKE versão 1.35.2-gke.1842000 ou posterior

Para usar a DRANET gerenciada pelo GKE para solicitar e alocar interfaces de rede para pods, ative o recurso no ComputeClass. Você precisa:

  • Ative o driver de rede DRANET definindo nodePoolConfig.dra.networking.enabled como true.
  • Defina acceleratorNetworkProfile como auto na lista priorities.

Para mais informações sobre como usar o DRANET, consulte Alocar recursos de rede usando o DRANET gerenciado pelo GKE.

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 na ordem de aparência ou, se o campo priorityScore estiver definido, da pontuação mais alta para a mais baixa.

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 na região, o GKE provisionará novos nós que usam VMs spot N4 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 do ComputeClass. Esses valores padrão serã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 da ComputeClass.

O campo priorityDefaults tem as seguintes limitações:

  • Requer o GKE versão 1.32.1-gke.1729000 ou posterior.
  • 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 do 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 escalonados como 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 realizam 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 pools 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. Se o cluster estiver executando uma versão anterior à 1.33.3-gke.1136000, também será necessário ativar o provisionamento automático de nós no nível do cluster.

O GKE pode criar novos 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. Os 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 spot ou séries de máquinas específicas.

  • Se você definir uma ComputeClass padrão para o 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 um valor de 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 a 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 de nós 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 descrito 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 pool de nós, o GKE pode criar um novo pool de nós que use a série de máquinas E2 padrão 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, nos 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 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 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 a remoção de nós e a consolidação da carga de trabalho usando a seção autoscalingPolicy na definição personalizada da 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 que substitui automaticamente os nós atuais por novos. Os seguintes tipos de migração ativa são compatíveis:

  • optimizeRulePriority: o GKE substitui os nós que usam uma configuração de prioridade mais baixa por nós que usam uma configuração de prioridade mais alta. Essa opção ajuda a garantir que os pods sejam executados na configuração de nó mais preferida, mesmo que o GKE tenha que executar esses pods em uma configuração de nó menos preferida.
  • ensureAllDaemonSetPodsRunning: o GKE substitui os nós que têm pods do DaemonSet não programáveis por nós maiores que podem executar todos os pods do DaemonSet necessários. Essa opção ajuda a garantir que todos os DaemonSets sejam executados nos nós.

Durante uma migração ativa, o GKE faz o seguinte:

  1. O GKE cria um novo nó com uma configuração que atende aos requisitos do tipo de migração ativa.
  2. O GKE isola o nó atual para que novos pods não sejam executados nele.

  3. O GKE drena o nó atual, o que remove os pods dele. Os fatores a seguir afetam a rapidez com que o nó é drenado:

    Os controladores do Kubernetes, como implantações ou jobs, criam pods para substituir os pods removidos. O GKE programa esses novos pods no novo nó.

  4. Depois que o nó atual é drenado, o GKE o exclui.

A migração ativa não afeta pods e nós nos seguintes cenários:

  • A migração ativa não remove pods que têm a anotação cluster-autoscaler.kubernetes.io/safe-to-evict: "false".
  • A migração ativa não desaloca pods se a desalocação violar um PodDisruptionBudget.
  • A migração ativa não substitui os 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 do pool de nós --min-nodes.

Antes de ativar a migração ativa para uma ComputeClass, considere os seguintes efeitos possíveis:

  • 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.
  • Em clusters padrão, se você usar a criação automática de pool de nós, a migração ativa poderá acionar a criação de novos pools se os atuais não atenderem aos critérios definidos na ComputeClass.
  • As cargas de trabalho que usam volumes permanentes com recursos zonais, como o Hyperdisk, podem não funcionar bem com a migração ativa. As 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 quando os recursos de computação ficarem disponíveis.

Migração ativa para nós de prioridade mais alta

O tipo de migração ativa optimizeRulePriority permite que o GKE substitua os nós atuais que usam uma configuração de prioridade mais baixa por nós que usam uma configuração de prioridade mais alta.

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 os 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, as seguintes etapas vão acontecer:

  1. O GKE cria um novo nó N4.
  2. O GKE isola e drena o nó C4 atual. Os pods são removidos, respeitando os PodDisruptionBudgets e as configurações de encerramento normal.
  3. Os controladores do Kubernetes criam pods para substituir os pods removidos. Esses novos pods são executados no nó N4.
  4. Depois que o nó C4 é esvaziado, o GKE o exclui.

Da mesma forma, se você usar o campo priorityScore para definir pontuações explícitas para suas regras de prioridade, o GKE vai substituir os nós com uma pontuação menor por nós com uma pontuação maior.

Migração ativa para executar pods DaemonSet não programáveis

O tipo de migração ativa ensureAllDaemonSetPodsRunning permite que o GKE substitua automaticamente os nós atuais que têm pods do DaemonSet não programáveis por nós maiores que podem executar esses pods do DaemonSet.

Por exemplo, a seguinte especificação de ComputeClass configura a família de máquinas N4:

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

Considere um cenário em que você criou uma implantação de pod único que usou essa ComputeClass e solicitou duas vCPUs. Para executar esse pod, o GKE criou um nó n4-standard-2. Depois, você cria um DaemonSet que também solicita duas vCPUs. O pod do DaemonSet não pode ser executado no nó n4-standard-2. Nesse cenário, o GKE faz o seguinte:

  1. O GKE cria um nó que usa um tipo de máquina N4 maior, como n4-standard-4, que pode executar seu pod e o pod do DaemonSet. O pod do DaemonSet pendente é programado nesse novo nó.
  2. O GKE delimita e drena o nó n4-standard-2.
  3. Quando o pod é removido, a implantação cria um pod de substituição. O GKE programa esse pod no nó n4-standard-4, junto com o pod do DaemonSet.
  4. Depois que o nó n4-standard-2 é drenado, o GKE o exclui.

Consumir reservas do Compute Engine

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

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

Para consumir reservas do Compute Engine usando uma ComputeClass personalizada, use os seguintes métodos:

  • Criação automática de pools de nós: o GKE cria automaticamente novos pools de nós para consumir as reservas especificadas. Para mais informações, consulte Criação automática de pools de nós e ComputeClasses.
  • Pools de nós criados manualmente: em clusters do modo padrão, é possível rotear cargas de trabalho para pools de nós criados manualmente especificando o campo spec.priorities.nodepools na ComputeClass.

A partir da versão 1.36.0-gke.3204000 do GKE, é possível configurar as cargas de trabalho para consumir qualquer reserva correspondente sem reverter para a capacidade sob demanda usando a configuração de afinidade AnyThenFail.

Consumir reservas em pools de nós criados manualmente

Para consumir reservas em pools de nós criados manualmente em clusters Standard usando ComputeClasses, siga estas etapas:

  1. Vincule as reservas aos pools de nós seguindo as etapas em Como consumir instâncias reservadas no GKE Standard.

  2. Crie uma ComputeClass que use a regra de prioridade nodepools para selecionar seus pools de nós criados manualmente.

Por exemplo, considere um cenário em que você tem dois pools de nós, cada um vinculado a uma reserva de capacidade separada. Você prefere que os pods usem a capacidade reservada no pool de nós reservation-pool-1 em vez do pool de nós reservation-pool-2. A ComputeClass que implementa essas preferências é semelhante ao exemplo a seguir:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: manual-pool-reservations
spec:
  priorities:
  - nodepools: ['reservation-pool-1']
  - nodepools: ['reservation-pool-2']

Neste exemplo, o GKE tenta colocar pods no reservation-pool-1 primeiro, porque essa regra de prioridade aparece primeiro no campo priorities.

Criar automaticamente pools de nós para consumir reservas

Se você usar a criação automática de pool de nós, poderá solicitar que o GKE use reservas de capacidade para criar pools de nós para regras de prioridade específicas. Para consumir reservas em pools de nós criados automaticamente, é preciso atender aos seguintes requisitos:

  • A ComputeClass precisa ativar a criação automática de pools de nós.
  • As reservas que não são de TPU só podem ser usadas quando machineType ou machineFamily é definido.
  • 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 explicitamente um campo localSSDCount:.

Considere o exemplo a seguir de especificação de ComputeClass, que prioriza uma reserva compartilhada específica para uso ao provisionar instâncias a3-highgpu-1g. Se os tipos de instância priorizados não estiverem disponíveis, o GKE vai usar as reservas correspondentes 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 verticalmente as instâncias a3-highgpu-1g usando qualquer reserva correspondente. Se nenhuma reserva estiver acessível, o GKE vai usar as VMs 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, por fim, 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:

    • Especifique o nome da reserva no campo reservations.specific.name.
    • Verifique se o valor do campo reservations.affinity é Specific.

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

    • Especifique o nome da reserva no campo reservations.specific.name.
    • Especifique o ID do projeto que é proprietário da reserva no campo reservations.specific.project.
    • Verifique se o valor do campo reservations.affinity é Specific.

  • Qualquer reserva correspondente com substituição: configure os seguintes campos:

    • Confira se o valor do campo reservations.affinity é AnyBestEffort.
    • Não defina um nome ou projeto de reserva.

  • Qualquer reserva correspondente sem substituto: configure os seguintes campos:

    • Verifique se o valor do campo reservations.affinity é AnyThenFail.
    • Não defina um nome de reserva ou projeto.
    • Opcional. Para aplicar estritamente a falha se as reservas correspondentes forem esgotadas, defina a configuração whenUnsatisfiable: DoNotScaleUp no nível spec da ComputeClass.

As reservas de TPU exigem afinidade específica. As configurações reservations.affinity: AnyBestEffort e reservations.affinity: AnyThenFail não são compatíveis.

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.
  • Qualquer reserva correspondente com substituição (AnyBestEffort): 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 vai tentar a próxima regra de prioridade na ComputeClass.
  • Qualquer reserva correspondente sem substituição (AnyThenFail): o GKE pula o provisionamento de um nó sob demanda e tenta a próxima regra de prioridade na ComputeClass. Se nenhuma outra regra for aplicada, a operação de escalonamento falhará dependendo do valor da configuração whenUnsatisfiable.

Se o GKE não puder atender aos requisitos de nenhuma das regras de prioridade da 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.

Contagens mínimas de nós

Disponível no GKE versão 1.36.3-gke.1253000 e mais recentes.

É possível especificar um número mínimo de nós para o GKE manter em uma ComputeClass inteira ou em regras de prioridade específicas usando o campo minimumCapacity.targetNodeCount. O GKE mantém pelo menos o número especificado de nós, mesmo que essa capacidade esteja inativa. Especificar uma capacidade mínima funciona bem para cargas de trabalho que precisam de uma quantidade básica de capacidade de computação, como treinamento de IA/ML grande ou cargas de trabalho de exibição de baixa latência. O GKE continua a escalonar automaticamente os nós acima do mínimo quando as cargas de trabalho precisam de mais capacidade.

Ao especificar uma capacidade mínima para uma ComputeClass ou regra de prioridade, considere o seguinte comportamento:

  • Se a capacidade for para toda a ComputeClass, o GKE vai manter pelo menos esse número de nós em todas as regras de prioridade na ComputeClass. Se a capacidade for para uma regra de prioridade específica, o GKE vai manter pelo menos esse número de nós para essa regra.
  • Se o número de nós for menor que o mínimo especificado, o GKE vai criar automaticamente novos nós para manter a capacidade mínima, mesmo que esses nós adicionais não executem nenhum dos seus pods.
  • O GKE não reduzir escala vertical dos nós que compõem a capacidade mínima, mesmo que eles estejam vazios.
  • A capacidade especificada é um valor mínimo. Durante eventos de escalonamento vertical, o GKE pode exceder o número mínimo de nós para executar pods pendentes.
  • Se você ativar a migração ativa para nós de prioridade mais alta, o GKE poderá substituir os nós da capacidade mínima por nós de uma regra de prioridade mais alta. No entanto, o GKE não substitui um nó se a substituição colocar uma regra de prioridade abaixo da capacidade mínima.
  • A disponibilidade de recursos ou as cotas podem impedir que o GKE crie nós para o requisito de capacidade mínima.
  • Se o GKE não puder criar nós suficientes para a capacidade mínima de uma regra de prioridade, ele não vai usar outras regras de prioridade. Em vez disso, o GKE cria os nós ausentes para essa regra de prioridade quando a capacidade fica disponível.
  • Os nós ainda podem ser excluídos e substituídos para manter a integridade do cluster (por exemplo, para corrigir um nó não íntegro ou para preempção de uma VM spot). O GKE cria automaticamente novos nós para manter a capacidade mínima.

Dependendo se você configura uma capacidade mínima para uma ComputeClass inteira ou para regras de prioridade específicas, os seguintes requisitos se aplicam:

  • Capacidade mínima para a ComputeClass: se você especificar o campo minimumCapacity.targetNodeCount para toda a ComputeClass, todas as regras de prioridade precisarão solicitar direta ou indiretamente um tipo de máquina específico. Cada regra de prioridade precisa usar pelo menos uma das seguintes configurações:

    • machineType
    • gpu
    • tpu
    • Uma reserva de capacidade específica

    O GKE rejeita ComputeClasses que usam configurações flexíveis em uma regra de prioridade, como o campo machineFamily, e que também especificam uma capacidade mínima para toda a ComputeClass.

  • Capacidade mínima para uma regra de prioridade: se você especificar o campo minimumCapacity.targetNodeCount para uma regra de prioridade específica, essa regra precisará solicitar direta ou indiretamente um tipo de máquina específico usando pelo menos uma das seguintes configurações:

    • machineType
    • gpu
    • tpu
    • Uma reserva de capacidade específica

Os exemplos a seguir mostram a configuração de capacidade mínima para uma ComputeClass e para uma regra de prioridade:

  • ComputeClass:

    apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: gpu-class-min-nodes
spec:
  nodePoolAutoCreation:
    enabled: true
  # Define a global minimum capacity of 5 nodes for this ComputeClass
  minimumCapacity:
    targetNodeCount: 5
  priorities:
  - gpu:
      type: "nvidia-tesla-a100"
      count: 1
    machineType: "a2-highgpu-1g"
  - gpu:
      type: "nvidia-l4"
      count: 1
    machineType: "g2-standard-8"

  • Regra de prioridade:

    apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: tiered-compute-class
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - machineType: "n2-standard-16"
    # Maintain at least three nodes of this specific configuration
    minimumCapacity:
      targetNodeCount: 3
  - machineType: "e2-standard-4"

Capacidade mínima para uma ComputeClass e as regras de prioridade dela

Se você especificar uma capacidade mínima para uma ComputeClass e para algumas das regras de prioridade, os mínimos da regra de prioridade serão contabilizados no mínimo da ComputeClass. O comportamento a seguir se aplica:

  • Se os mínimos das regras de prioridade somarem pelo menos o mínimo da ComputeClass, os nós das regras de prioridade também atenderão ao mínimo da ComputeClass. O GKE não cria nós adicionais para o mínimo da ComputeClass, mesmo em regras de prioridade mais alta que não especificam uma capacidade mínima.
  • O mínimo de ComputeClass não limita os mínimos da regra de prioridade. O GKE cria todos os nós para cada mínimo de regra de prioridade, mesmo que o total exceda o mínimo da ComputeClass.
  • Se os mínimos da regra de prioridade somarem menos que o mínimo da ComputeClass, o GKE vai criar os nós restantes usando as regras de prioridade em ordem. Se necessário, o GKE vai usar regras de prioridade mais baixa para esses nós restantes.

Por exemplo, considere a seguinte ComputeClass, que especifica uma capacidade mínima para a ComputeClass e para a segunda regra de prioridade:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: combined-min-nodes
spec:
  nodePoolAutoCreation:
    enabled: true
  minimumCapacity:
    targetNodeCount: 5
  priorities:
  - machineType: "n2-standard-16"
  - machineType: "e2-standard-16"
    minimumCapacity:
      targetNodeCount: 3

Para essa ComputeClass, o GKE cria três nós e2-standard-16 para a segunda regra de prioridade. Esses nós contam para o mínimo de cinco nós da ComputeClass. Para os dois nós restantes, o GKE tenta criar nós n2-standard-16 primeiro. Se os nós n2-standard-16 não estiverem disponíveis, o GKE vai usar os nós e2-standard-16.

Se você ativar a migração ativa para nós de prioridade mais alta, o GKE poderá substituir até dois nós e2-standard-16 por nós n2-standard-16. No entanto, o GKE mantém pelo menos três nós e2-standard-16 para a capacidade mínima da segunda regra de prioridade.

Se você definir o campo targetNodeCount na segunda regra de prioridade como 6, o GKE vai criar seis nós e2-standard-16. Esses seis nós atendem ao mínimo de cinco nós da ComputeClass, então o GKE não cria nós n2-standard-16 para a capacidade mínima.

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 do ComputeClass. É possível especificar esse campo em qualquer regra de prioridade que defina uma série de máquinas ou um tipo de máquina do Compute Engine. Também é possível definir valores globais padrão para todos os campos de configuração do sistema de nós que forem omitidos nas regras de prioridade. Para isso, adicione o campo nodeSystemConfig ao campo priorityDefaults na ComputeClass.

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

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

Especificar rótulos e taints de nós

Na especificação ComputeClass, os campos nodeLabels e taints permitem definir configurações que correspondem aos pools de nós atuais e regem a criação de novos. Essas configurações podem ser aplicadas globalmente no campo nodePoolConfig para toda a ComputeClass ou no escopo de uma prioridade específica usando o campo priority. No entanto, é necessário garantir que os rótulos e as restrições definidos no nível de prioridade não se sobreponham aos definidos globalmente.

Esses recursos estão disponíveis nos seguintes locais:

  • Rótulos de nós de prioridade na versão 1.33.2-gke.1111000 e mais recentes do GKE.
  • Taints de prioridade no GKE versão 1.33.4-gke.1350000 e posterior.
  • Rótulos e taints de nós globais na versão 1.34.1-gke.3084002 e mais recentes do GKE.

Além dos rótulos personalizados, o GKE atribui automaticamente o rótulo de sistema cloud.google.com/compute-class a todos os nós provisionados para uma ComputeClass ou associados a ela. É possível filtrar e listar nós por ComputeClass:

kubectl get nodes -l cloud.google.com/compute-class=COMPUTECLASS_NAME

Para mais informações, consulte ComputeClass CustomResourceDefinition.

Configurar o taint padrão da arquitetura Arm

Por padrão, o GKE adiciona o taint kubernetes.io/arch=arm64:NoSchedule a todos os nós do Arm, incluindo os criados para ComputeClasses personalizadas. O GKE programa apenas cargas de trabalho que têm uma tolerância para esse taint nos nós do Arm, o que ajuda a evitar que as cargas de trabalho x86 sejam executadas em arquiteturas incompatíveis. Se as cargas de trabalho forem compatíveis com x86 e Arm, será possível desativar esse taint padrão. Qualquer carga de trabalho que selecione a ComputeClass pode ser executada nos nós do Arm, mesmo que não tenha a tolerância para a arquitetura do Arm.

É possível atualizar o comportamento de taint padrão em pools de nós padrão e com nós criados para ComputeClasses personalizadas. Para mais informações sobre como configurar o comportamento dos pools de nós padrão, consulte Configurar o taint padrão da arquitetura Arm.

Para mudar o comportamento padrão e permitir que o GKE programe cargas de trabalho que não têm uma tolerância correspondente para nós do Arm criados para uma ComputeClass personalizada, configure sua ComputeClass conforme mostrado neste exemplo:

taintConfig:
  architectureTaintBehavior: NONE

Esse campo requer um cluster que execute o GKE versão 1.36.2-gke.1498000 ou posterior.

ComputeClasses padrão para clusters e namespaces

É possível configurar o GKE para aplicar uma ComputeClass por padrão aos 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. Esse agrupamento permite aplicar configurações compartilhadas em vários pools de nós.

Coleção de vários hosts de TPU

Requer o GKE versão 1.31.2-gke.1518000 ou posterior. Disponível apenas na TPU Trillium (v6e)

É possível agrupar sua implantação de vários hosts da 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ção que é refletida 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, você escolhe 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 ComputeClass:

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

Para mais informações, consulte Sobre 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 para os 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 em lote ou de treinamento 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 ver mais informações, consulte os seguintes tópicos:

Configuração do sandbox

Requer o GKE versão 1.36.2-gke.1368000 ou posterior

É possível isolar cargas de trabalho do kernel do host dos nós executando os pods em sandboxes usando o GKE Sandbox. Em ComputeClasses, é possível ativar o GKE Sandbox e selecionar um tipo de sandbox para os nós usando o campo nodePoolConfig.sandbox. Os seguintes tipos de sandbox são compatíveis:

  • gvisor: requer a versão 1.36.2-gke.1368000 ou mais recente do GKE.
  • microvm: requer a versão 1.37.0-gke.4713000 ou mais recente do GKE e nós que usam virtualização aninhada.

Para mais informações sobre os recursos, as limitações e os requisitos desses tipos de sandbox, consulte Sobre o GKE Sandbox.

Para usar uma ComputeClass e ativar e solicitar sandboxes, consulte Isolar cargas de trabalho usando o GKE Sandbox.

Configuração de metadados de instância

Requer o GKE versão 1.36.2-gke.1498000 ou posterior.

O campo instanceMetadata em uma especificação do ComputeClass permite adicionar pares de chave-valor de metadados personalizados diretamente às instâncias de VM do Compute Engine provisionadas para os pools de nós pelo escalonador automático de cluster ou pelo provisionamento automático de nós. Isso é semelhante a especificar a flag --metadata ao criar pools de nós manualmente com a Google Cloud CLI.

A configuração de metadados de instância personalizada usando ComputeClasses é compatível apenas com clusters do modo GKE Standard (spec.autopilot.enabled: false).

É possível especificar instanceMetadata em dois lugares em uma ComputeClass:

  • Configuração global (spec.nodePoolConfig.instanceMetadata): aplica pares de chave-valor de metadados personalizados globalmente a todos os novos pools de nós e VMs criados pela ComputeClass.
  • Substituições específicas de prioridade (spec.priorities[].instanceMetadata): aplica pares de chave-valor de metadados personalizados somente quando o GKE provisiona nós usando essa prioridade específica na hierarquia.

Se a mesma chave de metadados for definida em nodePoolConfig.instanceMetadata e priorities[].instanceMetadata, o valor especificado em priorities[].instanceMetadata vai substituir o valor global.

Esquema e regras de validação

Ao definir instanceMetadata, siga as seguintes restrições de validação:

  • Tipo: pares de chave-valor estruturados como um map (map[string]string).
  • Limites de tamanho:
    • O tamanho máximo de um valor de metadados individual é de 32 KB (32.768 bytes).
    • O tamanho máximo combinado de todos os pares de chave-valor de metadados em todo o recurso ComputeClass não pode exceder 512 KB (524.288 bytes).
  • Limites e formatação de chaves:
    • É possível definir no máximo 32 pares de chave-valor de metadados personalizados por ComputeClass.
    • As chaves precisam ter menos de 128 caracteres e podem conter apenas caracteres alfanuméricos, hifens (-) e sublinhados (_).
  • Chaves reservadas: o GKE e o Compute Engine reservam chaves de metadados específicos do sistema necessárias para gerenciar operações de cluster, como kube-env, user-data, startup-script e cluster-name. Não é possível substituir ou especificar chaves de metadados reservadas do sistema.
  • Imutabilidade em pools de nós atuais: a modificação de instanceMetadata em um ComputeClass atual só se aplica quando o GKE provisiona novos pools de nós (quando nodePoolAutoCreation está ativado). Os pools de nós e as VMs atuais não são modificados retroativamente.

O exemplo a seguir mostra como configurar metadados globais da instância em todos os pools de nós e uma substituição de metadados específica da prioridade:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: metadata-example-class
spec:
  nodePoolAutoCreation:
    enabled: true
  nodePoolConfig:
    instanceMetadata:
      environment: "production"
      team: "backend-platform"
  priorities:
  - machineFamily: n4
    instanceMetadata:
      workload-tier: "high-performance"
  - machineFamily: e2
    instanceMetadata:
      workload-tier: "fallback-general"
      team: "shared-infra"

Configurar limites de escalonamento automático

Disponível no GKE versão 1.36.2-gke.2064000 e mais recentes.

Por padrão, o GKE provisiona novos nós para uma ComputeClass até os limites de escalonamento automático gerais do cluster. Para aplicar limites de recursos mais rígidos a uma ComputeClass específica, como limitar o número máximo de GPUs, CPUs ou nós totais que podem ser provisionados para a ComputeClass, aplique um recurso personalizado CapacityQuota.

Para mais informações, consulte Configurar limites de recursos granulares.

Configuração de nós protegidos do GKE

Requer o GKE versão 1.36.3-gke.1244000 ou posterior

Para configurar os recursos dos Nós protegidos do GKE, como Inicialização segura e Monitoramento de integridade, para pools de nós criados automaticamente e gerenciados por uma ComputeClass, especifique o campo shieldedInstanceConfig no bloco nodePoolAutoCreation (spec.nodePoolAutoCreation.shieldedInstanceConfig).

Os valores padrão de shieldedInstanceConfig dependem do modo do cluster e da configuração de ComputeClass:

  • Em clusters no modo Standard: quando shieldedInstanceConfig é inicializado durante o ajuste de contas nodePoolAutoCreation, o campo enableIntegrityMonitoring é definido como true e o campo enableSecureBoot é definido como false, a menos que você os configure explicitamente.
  • Em clusters do Autopilot (ou quando spec.autopilot.enabled é true em uma ComputeClass): os campos enableSecureBoot e enableIntegrityMonitoring têm como padrão true e não podem ser desativados.

O exemplo a seguir demonstra como configurar o campo shieldedInstanceConfig no bloco nodePoolAutoCreation para ativar os recursos de nós protegidos do GKE em pools de nós criados automaticamente:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: shielded-ccc
spec:
  nodePoolAutoCreation:
    enabled: true
    shieldedInstanceConfig:
      enableSecureBoot: true
      enableIntegrityMonitoring: true

Solicitar ComputeClasses em cargas de trabalho

Para usar uma ComputeClass personalizada, o pod precisa solicitar explicitamente essa ComputeClass usando um nodeSelector na especificação do pod. Também é possível 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: registry.k8s.io/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, os aceleradores de hardware anexados 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
  • node.kubernetes.io/instance-type

No GKE versão 1.32.3-gke.1499000 e posterior, é 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 o 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 que têm um campo correspondente na especificação ComputeClass. Ao usar ComputeClasses, atualize suas cargas de trabalho para remover os seguintes rótulos dos seletores de nós e configure o campo correspondente nas ComputeClasses que você criar:

Rótulo 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
node.kubernetes.io/instance-type priorities.machineType

Limitações

  • O nome da ComputeClass não pode começar com gke ou autopilot (reservado para ComputeClasses do sistema).
  • Alguns clusters têm altas taxas de criação e exclusão de pods, o que aumenta o tempo de avaliação do escalonador automático de clusters. Durante uma operação de escalonamento, o escalonador automático de cluster pode não ter tempo para avaliar as regras de prioridade subsequentes em uma ComputeClass antes que o período de espera das regras de prioridade anteriores expire. Como resultado, os pods podem permanecer no estado pendente. Para minimizar esse problema, reduza a taxa de criação e exclusão de pods. Por exemplo, desative a migração ativa para a ComputeClass.

A seguir