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 baratos. 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 do GKE na versão 1.30.3-gke.1451000 e mais recentes e oferecem uma abordagem declarativa para definir atributos de nó e prioridades de escalonamento automático. Há 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 ajuda a garantir 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 doCloud de Confiance by S3NS . Você define um objeto ComputeClass no cluster e solicita essa ComputeClass em cargas de trabalho ou define essa ComputeClass 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 desempenho pode ter uma estratégia alternativa que usa apenas tipos de máquina com grande quantidade de CPUs.
  • 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.

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

  • Propriedades do nó: definem as propriedades dos nós em que você quer que os pods sejam executados, como famílias de máquinas a serem usadas. Quando um pod aciona uma operação de escalonamento horizontal, o GKE tenta criar um nó com 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 pool 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. Na versão 1.35.2-gke.1842000 e mais recentes do GKE, 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 as 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 das 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 suas regras de prioridade com base na pontuação, e valores maiores têm uma prioridade mais alta do que valores menores.

O campo priorityScore tem as seguintes propriedades:

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

  • É possível definir a mesma pontuação de prioridade para até três regras separadas. Durante o escalonamento, o GKE processa regras com a mesma pontuação juntas. O GKE escolhe uma regra específica com base nos critérios operacionais do autoescalador 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 mais chances 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 encontre 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 este exemplo de ComputeClass, 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, selecione um tipo de hardware de nível superior que você quer para os nós. As outras propriedades que você pode especificar para uma regra dependem da propriedade de nível superior dela.

É possível 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 uma configuração de driver.
  • tpu: uma configuração do Cloud TPU que pode incluir uma versão, uma topologia e um número de chips de TPU.

As configurações 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.

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 oferece suporte a tipos de disco do Hyperdisk ML, mas a série 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 dinâmico de volume: na versão 1.35.3-gke.1290000 e mais recentes do GKE, use uma StorageClass que configure a seleção automatizada de tipo de disco. O GKE cria um tipo de disco compatível com o tipo de máquina do nó que executa sua 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 disco dos seus 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 uma da série de máquinas do Compute Engine, 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 de escalonamento automático determina o tamanho mais adequado com base nas solicitações de recursos agregados de todos os pods pendentes. Para ter mais controle sobre o tamanho exato da máquina, use o campo machineType.

É possível usar outros campos spec.priorities com o campo machineFamily para definir de forma declarativa seus 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 muito pequenos 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 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 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:

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 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: 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 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 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 de TPU

Requer o 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.
  • location:
    • zones: uma lista de Cloud de Confiance zonas em que o GKE pode provisionar nós. Se não for especificado, o GKE vai 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 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 otimizados para cargas de trabalho de IA/ML em Cloud de Confiance by S3NS regiões.

    • zoneTypes: uma lista de tipos de zona que especifica um conjunto de zonas Cloud de Confiance em que o GKE pode provisionar nós. Os valores aceitos 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 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:

Segmentar zonas de IA

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 regiões do Cloud de Confiance by S3NS otimizadas para cargas de trabalho de IA/ML. A classe de computação a seguir define uma lista priorizada de zonas 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 em 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.

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 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 escalonados 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. 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 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 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 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 que substitui automaticamente os nós atuais por novos nós. Os seguintes tipos de migração ativa são aceitos:

  • optimizeRulePriority: o GKE substitui 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 nós com 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 limita 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ó é esgotado:

    Os controladores do Kubernetes, como implantações ou jobs, criam pods para substituir os pods despejados. 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 desaloca pods com a anotação cluster-autoscaler.kubernetes.io/safe-to-evict: "false".
  • A migração ativa não desaloca pods se isso violar um PodDisruptionBudget.
  • 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.

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

  • 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.
  • Nos 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.
  • 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 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 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 delimita e drena o nó C4 atual. Seus pods são removidos, respeitando as configurações de PodDisruptionBudgets e 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.

Por exemplo, a especificação ComputeClass a seguir 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ê vai criar 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 restringe 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 exclui o nó.

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 emCloud de Confiance zonas específicas, configure 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 pool 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 pool de nós e ComputeClasses.
  • Pools de nós criados manualmente: em clusters do modo Standard, é possível direcionar cargas de trabalho para pools de nós criados manualmente especificando o campo spec.priorities.nodepools na ComputeClass.

Consumir reservas em pools de nós criados manualmente

Para consumir reservas em pools de nós criados manualmente em clusters padrão 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 pool de nós.
  • 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 propriedade da 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 indisponí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 vai 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 dentro de 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:

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 itens:

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

Para mais informações, consulte ComputeClass CustomResourceDefinition.

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 TPUs com vários hosts

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 TPU de vários hosts 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 Cloud de Confiance by S3NS 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.s3ns.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 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: 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 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
  • node.kubernetes.io/instance-type

Na versão 1.32.3-gke.1499000 e mais recentes do GKE, é 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 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:

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 sua ComputeClass não pode começar com gke ou autopilot.

A seguir