Acerca das ComputeClasses personalizadas

Pode criar as suas próprias ComputeClasses para controlar as propriedades dos nós que o Google Kubernetes Engine (GKE) aprovisiona quando dimensiona automaticamente o cluster. Esta página destina-se a administradores de plataformas que querem definir declarativamente perfis de escalabilidade automática para nós, para que cargas de trabalho específicas sejam executadas em hardware que satisfaça os respetivos requisitos. Para mais informações sobre o que são as ComputeClasses, consulte Acerca das ComputeClasses do GKE.

Vista geral das ComputeClasses

No GKE, uma ComputeClass é um perfil que consiste num conjunto de atributos de nós que o GKE usa para aprovisionar os nós que executam as suas cargas de trabalho durante eventos de escala automática. As ComputeClasses podem segmentar otimizações específicas, como o aprovisionamento de nós de alto desempenho ou a priorização de configurações otimizadas em função do custo para custos de execução mais baratos. As classes de computação personalizadas permitem-lhe definir perfis que o GKE usa para criar uma escala automática de nós de forma a cumprir rigorosamente os requisitos de cargas de trabalho específicas.

As ComputeClasses personalizadas estão disponíveis para utilização no modo Autopilot do GKE e no modo Standard do GKE na versão 1.30.3-gke.1451000 e posterior, e oferecem uma abordagem declarativa para definir atributos de nós e prioridades de escalamento automático. As ComputeClasses personalizadas estão disponíveis para configuração e utilização em todos os clusters do GKE elegíveis por predefinição.

Vantagens das ComputeClasses personalizadas

As ComputeClasses personalizadas oferecem as seguintes vantagens:

  • Prioridades de computação alternativas: defina uma hierarquia de configurações de nós em cada ComputeClass para o GKE priorizar. Se a configuração mais preferida não estiver disponível, o GKE escolhe automaticamente a configuração seguinte na hierarquia. Este modelo alternativo garante que, mesmo quando os recursos de computação não estão disponíveis, as suas cargas de trabalho continuam a ser executadas em hardware otimizado com atrasos mínimos de agendamento.
  • Controlo detalhado do dimensionamento automático: defina configurações de nós mais adequadas para cargas de trabalho específicas. O GKE dá prioridade a essas configurações quando cria nós durante o dimensionamento.
  • Configuração declarativa da infraestrutura: adote uma abordagem declarativa à gestão da infraestrutura para que o GKE crie automaticamente nós para si que correspondam aos requisitos específicos da sua carga de trabalho.
  • Migração ativa: se os recursos de computação para uma configuração de máquina mais preferencial ficarem disponíveis na sua localização, o GKE migra automaticamente as suas cargas de trabalho para novos nós que usam a configuração preferencial.
  • Otimização de custos: dê prioridade a tipos de nós rentáveis, como VMs Spot, para reduzir as despesas do cluster.
  • ComputeClasses personalizados predefinidos: defina um ComputeClass personalizado como o predefinido para um cluster inteiro ou para espaços de nomes específicos do Kubernetes, para que as cargas de trabalho sejam executadas em hardware otimizado, mesmo que não peçam um ComputeClass específico.
  • Limites de consolidação de nós personalizados: defina limites de utilização de recursos personalizados para nós. Se a utilização de recursos de um nó específico ficar abaixo do seu limite, o GKE tenta consolidar as cargas de trabalho num nó semelhante disponível e reduz o nó com utilização inferior.

Exemplos de utilização de ComputeClasses personalizadas

Pondere usar ComputeClasses personalizadas em cenários como os seguintes:

  • Quer executar as suas cargas de trabalho de IA/ML em configurações específicas de GPU ou TPU.
  • Quer definir configurações de hardware predefinidas para as cargas de trabalho que equipas específicas executam, retirando a sobrecarga dos operadores de aplicações.
  • Executa cargas de trabalho com um desempenho ideal em séries de máquinas ou configurações de hardware específicas do Compute Engine.
  • Quer declarar configurações de hardware que cumprem requisitos empresariais específicos, como alto desempenho, otimização de custos ou alta disponibilidade.
  • Quer que o GKE recorra hierarquicamente à utilização de configurações de hardware específicas durante a indisponibilidade de recursos de computação, para que as suas cargas de trabalho sejam sempre executadas em máquinas adequadas aos respetivos requisitos.
  • Quer decidir centralmente as configurações ideais em toda a frota da sua empresa, para que os custos sejam mais previsíveis e as cargas de trabalho sejam executadas de forma mais fiável.
  • Quer especificar centralmente quais das suas reservas de capacidade do Compute Engine o GKE deve usar para aprovisionar novos nós para cargas de trabalho específicas.
  • Quer especificar uma política de posicionamento compacta para usar com o GKE Autopilot. Para obter detalhes, consulte: posicionamento compacto.

Como funcionam as ComputeClasses personalizadas

As ComputeClasses personalizadas são recursos personalizados do Kubernetes que aprovisionam aGoogle Cloud infraestrutura. Define um objeto ComputeClass no cluster e, em seguida, pede essa ComputeClass em cargas de trabalho ou define essa classe de computação como predefinição para um espaço de nomes do Kubernetes. Quando uma carga de trabalho correspondente exige uma nova infraestrutura, o GKE aprovisiona novos nós de acordo com as prioridades que define na definição de ComputeClass.

Os atributos que define nas ComputeClasses definem como o GKE configura novos nós para executar cargas de trabalho. Quando modifica uma classe de computação existente, todos os nós futuros que o GKE cria para essa classe de computação usam a configuração modificada. O GKE não altera retroativamente a configuração dos nós existentes para corresponder às suas modificações.

As ComputeClasses personalizadas influenciam as decisões de dimensionamento automático, mas não são consideradas pelo kube-scheduler. Durante a programação de pods, o programador pode não dar prioridade a nós com prioridades ComputeClass personalizadas mais elevadas, mesmo quando existem nós disponíveis em várias prioridades.

Para garantir que as suas ComputeClasses personalizadas estão otimizadas para a sua frota, considere as seguintes diretrizes:

  • Compreenda os requisitos de computação da sua frota, incluindo quaisquer requisitos de hardware específicos da aplicação.
  • Decida um tema que oriente o design de cada ComputeClass. Por exemplo, uma ComputeClass otimizada para desempenho pode ter uma estratégia alternativa que use apenas tipos de máquinas com alta utilização de CPU.
  • Decida qual é a família de máquinas e a série de máquinas do Compute Engine que melhor se adequam às suas cargas de trabalho. Para ver detalhes, consulte o Recurso de famílias de máquinas e guia de comparação.
  • Planeie uma estratégia alternativa em cada ComputeClass para que as cargas de trabalho sejam sempre executadas em nós que usam configurações de máquinas semelhantes. Por exemplo, se a série de máquinas N4 não estiver disponível, pode usar as máquinas C3.

Veja a definição de recurso personalizado completa

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

Também pode ver o CRD no cluster executando o seguinte comando:

kubectl describe crd computeclasses.cloud.google.com

Planeie uma ComputeClass personalizada

Para planear, implementar e usar eficazmente uma ComputeClass personalizada no seu cluster, siga estes passos:

  1. Escolha as prioridades de computação alternativas: defina uma série de regras que regem as propriedades dos nós que o GKE cria para a ComputeClass.
  2. Configure os conjuntos de nós padrão do GKE e as ComputeClasses: Para clusters no modo padrão, execute os passos de configuração necessários para usar a ComputeClass com os seus conjuntos de nós.
  3. Defina o comportamento de escalonamento quando não se aplicam regras de prioridade: opcionalmente, diga ao GKE o que fazer se não for possível aprovisionar nós que cumpram as suas regras de prioridade.
  4. Defina parâmetros de escala automática para a consolidação de nós: indique ao GKE quando consolidar cargas de trabalho e remover nós subutilizados.
  5. Configure a migração ativa para nós de prioridade mais elevada: opcionalmente, diga ao GKE para mover cargas de trabalho para nós mais preferidos à medida que o hardware fica disponível.
  6. Consumir reservas do Compute Engine: opcionalmente, indique ao GKE para consumir reservas zonais existentes do Compute Engine quando criar novos nós.

Escolha as suas prioridades de cálculo alternativas

A principal vantagem de usar uma ComputeClass personalizada é ter controlo sobre a estratégia alternativa quando os seus nós preferenciais não estão disponíveis devido a fatores como o esgotamento de recursos e as limitações de quota.

Cria uma estratégia alternativa definindo uma lista de regras de prioridade na sua ComputeClass personalizada. Quando um cluster precisa de ser expandido, o GKE dá prioridade à criação de nós que correspondam à regra de prioridade mais alta. Se o GKE não conseguir criar esses nós, recorre à regra de prioridade seguinte, repetindo este processo até o GKE aumentar a escala do cluster com êxito ou esgotar todas as regras. Se todas as regras forem esgotadas, o GKE cria nós com base no comportamento predefinido ou especificado descrito em Defina o comportamento de escalabilidade quando não se aplicam regras de prioridade.

As diferentes séries de máquinas do Compute Engine são compatíveis com diferentes tecnologias e funcionalidades. As gerações anteriores de uma série de máquinas podem não suportar os mesmos tipos de armazenamento que as gerações mais recentes. Se executar cargas de trabalho com estado que dependam de dados persistentes, evite usar uma ComputeClass que abranja várias gerações de uma série de máquinas. As cargas de trabalho podem não conseguir aceder aos dados persistentes se o GKE as colocar num tipo de máquina que não suporte esse tipo de armazenamento. Para ver detalhes, filtre a tabela de comparação de séries de máquinas para tipos de armazenamento específicos.

Regras de prioridade

Define regras de prioridade no campo spec.priorities do recurso personalizado ComputeClass. Cada regra no campo priorities descreve as propriedades dos nós a aprovisionar. O GKE processa o campo priorities por ordem, o que significa que o primeiro item no campo tem a prioridade mais elevada para o aprovisionamento de nós.

Existem dois tipos de regras de prioridade:

  • Tipos de regras declarativas: use caraterísticas dos nós para descrever os nós que quer aprovisionar

  • Tipo de regra do conjunto de nós: nos clusters padrão do GKE, fornece uma lista de conjuntos de nós criados manualmente que estão associados à ComputeClass na qual o GKE deve aprovisionar nós.

Regras de prioridade declarativas

Com as regras de prioridade declarativas, pode especificar propriedades da máquina, como a família ou o tipo de máquina, VMs Spot, opções de acelerador, opções de armazenamento, reservas e requisitos mínimos de recursos, para o GKE usar quando aprovisiona nós. Para ver o conjunto completo de campos suportados, consulte a referência CRD ComputeClass.

Configurações machineFamily

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

Pode usar outros spec.priorities campos juntamente com o campo machineFamily para definir declarativamente os seus requisitos de computação, por exemplo:

  • spot: VMs do Spot. O valor predefinido é false.
  • minCores: vCPUs mínimas por nó. O valor predefinido é 0.
  • minMemoryGb: memória mínima por nó. O valor predefinido é 0.
  • storage.bootDiskKMSKey: caminho para a chave do Cloud Key Management Service a usar para a encriptação do disco de arranque.
  • storage.secondaryBootDisks: discos persistentes usados para pré-carregar nós do GKE com dados, como um modelo de aprendizagem automática (ML) ou uma imagem de contentor. Requer a versão 1.31.2-gke.1105000 ou posterior do GKE. Para configurar um disco de arranque secundário para o cluster usar, consulte o artigo Configure discos de arranque secundários.
    • storage.secondaryBootDisks.diskImageName: o nome da imagem do disco a pré-carregar.
    • storage.secondaryBootDisks.project: o nome do projeto ao qual a imagem de disco pertence. Se este valor não for especificado, a predefinição é o projeto do cluster.
    • storage.secondaryBootDisks.mode: o modo em que o disco de arranque secundário deve ser usado. Se este valor estiver definido como CONTAINER_IMAGE_CACHE, o disco de arranque secundário é usado como uma cache de imagens de contentores. O valor tem de ser igual a CONTAINER_IMAGE_CACHE ou MODE_UNSPECIFIED. Se este valor não for especificado, o valor predefinido é MODE_UNSPECIFIED.
  • placement: Os detalhes do posicionamento da máquina:

O exemplo seguinte mostra uma regra de prioridade que usa machineFamily:

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

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 personalizado, como n4-custom-8-20480. A utilização de tipos de máquinas personalizados requer a versão 1.33.2-gke.1111000 ou posterior do GKE.

Pode especificar outros campos spec.priorities juntamente com o campo machineType para definir declarativamente os seus requisitos de computação, por exemplo:

  • spot: use VMs do Spot. A predefinição é false.
  • storage: configure o armazenamento de nós.
    • storage.bootDiskType: tipo de disco de arranque. No Autopilot, apenas é suportado o tipo pd-balanced de bootDiskType.
    • storage.bootDiskKMSKey: Caminho para a chave do Cloud KMS a usar para a encriptação do disco de arranque.
    • storage.bootDiskSize: tamanho em GB do disco de arranque do nó.
    • storage.localSSDCount: número de SSDs locais a associar ao nó. Se especificado, tem de ter, pelo menos, 1.

O exemplo seguinte mostra uma regra de prioridade que usa machineType para aprovisionar n4-standard-32 tipos de máquinas:

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

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

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

O exemplo seguinte 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 a versão 1.31.2-gke.1518000 ou posterior do GKE

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

Também pode especificar outros spec.priorities campos juntamente com o campo tpu na regra de prioridade, por exemplo:

  • spot: use VMs do Spot. A predefinição é false.
  • storage: configure o armazenamento de nós.
    • storage.bootDiskType: tipo de disco de arranque.
    • storage.bootDiskKMSKey: caminho para a chave do Cloud KMS a usar para a encriptação do disco de arranque.
    • storage.bootDiskSize: tamanho em GB do disco de arranque do nó.
  • reservations: use uma reserva do Compute Engine. Para ver detalhes, consulte a secção Use reservas do Compute Engine.

O exemplo seguinte 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 alternativa:

  1. O GKE tenta aprovisionar uma fatia de TPU v5p de vários anfitriões com 16 nós consumindo uma reserva partilhada do Compute Engine denominada tpu-reservation do projeto reservation-project.
  2. Se a reserva não tiver TPUs disponíveis, o GKE tenta aprovisionar uma fatia de TPU v5p multi-host de 16 nós em VMs Spot.
  3. Se nenhuma das regras anteriores puder ser satisfeita, o GKE segue a lógica na secção Defina o comportamento de escalabilidade quando não se aplicam regras de prioridade.

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

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

Especificações de aceleradores e formas de máquinas

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

Regras de prioridade dos conjuntos de nós

O campo nodepools recebe uma lista de pools de nós existentes nos quais o GKE tenta criar pods pendentes. O GKE não processa os valores neste campo por ordem. Não pode usar outros campos spec.priorities juntamente com o campo nodepools no mesmo item de regra de prioridade porque as regras com o campo nodepools não são declarativas por natureza. Este campo só é suportado no modo padrão do GKE. Para ver detalhes de utilização, consulte o artigo Segmente node pools específicos numa definição de ComputeClass.

Como o GKE cria nós através de regras de prioridade

Quando implementa uma carga de trabalho que pede uma ComputeClass e é necessário um novo nó, o GKE processa a lista de regras no campo priorities da especificação ComputeClass por ordem.

Por exemplo, considere a seguinte especificação:

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

Quando implementa uma carga de trabalho que pede uma ComputeClass com estas regras de prioridade, o GKE faz a correspondência dos nós da seguinte forma:

  1. O GKE coloca os pods em quaisquer nós existentes associados a esta ComputeClass.
  2. Se os nós existentes não conseguirem alojar os pods, o GKE aprovisiona novos nós que usam a série de máquinas N4, são VMs Spot e têm, 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 aprovisiona novos nós que usam VMs Spot N4 que podem ajustar-se aos pods, independentemente do número de núcleos.
  4. Se não estiverem disponíveis VMs N4 Spot na região, o GKE aprovisiona novas VMs N4 a pedido.
  5. Se nenhuma das regras anteriores puder ser satisfeita, o GKE segue a lógica na secção Defina o comportamento de escalabilidade quando não se aplicam regras de prioridade.

Valores predefinidos para regras de prioridade

Pode definir valores predefinidos para alguns dos campos nas regras de prioridade da especificação ComputeClass. Estes valores predefinidos aplicam-se se os campos correspondentes numa regra específica forem omitidos. Pode definir estes valores predefinidos usando o campo priorityDefaults na especificação ComputeClass.

O campo priorityDefaults tem as seguintes limitações:

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

Para ver detalhes sobre os tipos de valores predefinidos que pode definir, consulte a secção priorityDefaults na ComputeClass CustomResourceDefinition.

Pools de nós padrão do GKE e ComputeClasses

Se usar o modo padrão do GKE, pode ter de fazer uma configuração manual para garantir que os pods ComputeClass são agendados conforme esperado.

  • Node pools geridos pela administração de contas automática de nós: não é necessária configuração manual. A administração de contas automática de nós executa automaticamente os passos de configuração da ComputeClass. Para mais detalhes, consulte o artigo Aprovisionamento automático de nós e ComputeClasses.
  • Node pools criados manualmente: é necessária uma configuração manual. Tem de adicionar etiquetas de nós e taints de nós aos conjuntos de nós criados manualmente para associar os nós a uma ComputeClass específica. Para obter detalhes, consulte o artigo Configure manualmente pools de nós para utilização da ComputeClass.

Configure node pools criados manualmente para utilização da ComputeClass

Se os seus clusters padrão do GKE tiverem pools de nós que criou manualmente sem o aprovisionamento automático de nós, tem de configurar esses pools de nós para os associar a ComputeClasses específicas. O GKE apenas agenda pods que pedem uma ComputeClass específica em nós em pools de nós que associa a essa ComputeClass. Este requisito não se aplica a uma ComputeClass que configure como a predefinição ao nível do cluster.

Os conjuntos de nós do modo GKE Autopilot e do modo GKE Standard que foram criados pelo aprovisionamento automático de nós fazem esta configuração automaticamente.

Para associar um node pool criado manualmente a uma ComputeClass, adicione etiquetas de nós e restrições de nós ao node pool durante a criação ou durante uma atualização especificando a flag --node-labels e a flag --node-taints, da seguinte forma:

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

Nestes atributos, COMPUTE_CLASS é o nome da sua ComputeClass personalizada.

Por exemplo, os seguintes comandos atualizam em conjunto um node pool existente e associam o node pool à dev-class ComputeClass:

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"

Pode associar cada pool de nós no seu cluster a uma ComputeClass personalizada. Os pods que o GKE agenda nestes conjuntos de nós criados manualmente apenas acionam a criação de nós nesses conjuntos de nós durante eventos de escala automática.

Aprovisionamento automático de nós e ComputeClasses

Pode usar o aprovisionamento automático de nós com uma ComputeClass personalizada para permitir que o GKE crie e elimine automaticamente pools de nós com base nas suas regras de prioridade.

Para usar o aprovisionamento automático dos nós com uma ComputeClass, tem de fazer o seguinte:

  1. Certifique-se de que o aprovisionamento automático de nós está ativado no seu cluster.
  2. Adicione o campo nodePoolAutoCreation com o valor enabled: true à especificação de ComputeClass.

Em seguida, o GKE pode colocar pods que usam ComputeClasses que configuram o aprovisionamento automático de nós em novos conjuntos de nós. O GKE decide se deve aumentar a escala de um node pool existente ou criar um novo node pool com base em fatores como o tamanho dos clusters e os requisitos dos pods. Os pods com ComputeClasses que não configuram o aprovisionamento automático de nós continuam a dimensionar apenas os conjuntos de nós existentes.

Pode usar ComputeClasses que interagem com o aprovisionamento automático de nós juntamente com ComputeClasses que interagem com pools de nós criados manualmente no mesmo cluster.

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

  • Não pode usar a família de máquinas nem os seletores de nós VMs Spot porque estes seletores entram em conflito com o comportamento da ComputeClass. O GKE rejeita todos os pods que pedem uma ComputeClass e também pedem VMs Spot ou séries de máquinas específicas.

  • Se definir uma ComputeClass predefinida para o seu cluster, os pods que usam um seletor de nós da família de máquinas só acionam a criação de nós para essa classe predefinida numa das seguintes situações:

    • Os pods selecionam uma família de máquinas que corresponde a uma das regras de prioridade na classe predefinida ao nível do cluster. Por exemplo, um agrupamento que seleciona N4 instâncias aciona a criação de nós se a classe predefinida ao nível do cluster tiver uma regra de prioridade para instâncias N4.
    • A ComputeClass predefinida ao 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 cria novos nós com essa família de máquinas.

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

  • Pode configurar a Administração de contas automática de nós para ComputeClasses que usam o campo nodepools para referenciar pools de nós existentes. O aprovisionamento automático de nós processa as prioridades por ordem e tenta dimensionar os conjuntos de nós existentes para colocar os seus pods.

Considere o seguinte exemplo para um cluster que tem pools de nós criados manualmente e aprovisionamento automático 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. Criar novos nós no manually-created-pool node pool.
  2. Aprovisione nós N4 em node pools N4 existentes ou criando um novo node pool.
  3. Se o GKE não conseguir criar nós N4, tenta aumentar a escala dos conjuntos de nós C4 existentes ou criar novos conjuntos de nós C4.

Segmente node pools específicos numa definição de ComputeClass

O campo priorities.nodepools permite-lhe especificar uma lista de pools de nós criados manualmente nos quais o GKE tenta agendar pods sem uma ordem específica em clusters padrão do GKE que usam o dimensionamento automático de clusters. Este campo só suporta uma lista de pools de nós. Não pode especificar propriedades adicionais da máquina, como a série de máquinas, na mesma regra de prioridade. Quando implementa uma carga de trabalho que pede uma ComputeClass com pools de nós com nome, o GKE tenta agendar os pods pendentes nesses pools de nós. O GKE pode criar novos nós nesses conjuntos de nós para colocar os pods.

Os conjuntos de nós que especificar no campo priorities.nodepools têm de estar associados a essa ComputeClass através de etiquetas de nós e restrições de nós, conforme descrito na secção Configure conjuntos de nós criados manualmente para ComputeClasses.

A lista de conjuntos de nós que especifica no campo nodepools não tem prioridade. Para configurar uma ordem alternativa para pools de nós com nome, tem de especificar vários itens priorities.nodepools separados. Por exemplo, considere a especificação seguinte:

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

Neste exemplo, o GKE tenta primeiro colocar os pods pendentes que pedem esta ComputeClass em nós existentes em pools de nós etiquetados com a ComputeClass. Se os nós existentes não estiverem disponíveis, o GKE tenta aprovisionar novos nós em pool1 ou pool2. Se o GKE não conseguir aprovisionar novos nós nestes conjuntos de nós, o GKE tenta aprovisionar novos pods em pool3.

Defina o comportamento de escalabilidade quando não se aplicam regras de prioridade

O recurso personalizado ComputeClass permite-lhe especificar o que o GKE deve fazer se não existirem nós que possam cumprir nenhuma das regras de prioridade. O campo whenUnsatisfiable na especificação suporta os seguintes valores.

  • ScaleUpAnyway: crie um novo nó que use a configuração da máquina predefinida do cluster. Nas versões do GKE anteriores à 1.33, este é o comportamento predefinido se omitir este campo.

    O GKE realiza uma das seguintes ações:

    • Nos clusters do Autopilot, o GKE coloca o pod num nó novo ou existente, independentemente da configuração da máquina do nó.
    • Em clusters padrão que não usam o aprovisionamento automático de nós, o GKE tenta dimensionar verticalmente qualquer conjunto de nós criado manualmente que defina uma etiqueta e uma mancha correspondentes a uma determinada ComputeClass.
    • Em clusters padrão que usam o aprovisionamento automático de nós, o GKE pode criar um novo conjunto de nós que usa a série de máquinas E2 predefinida para colocar o pod.

  • DoNotScaleUp: deixe o Pod no estado Pending até que esteja disponível um nó que cumpra os requisitos da ComputeClass. Na versão 1.33 e posteriores do GKE, este é o comportamento predefinido se omitir este campo.

Peça uma política de posicionamento

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

A política de posicionamento e a política 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, indica o respetivo nome num campo policyName. A política tem de ser uma política de recursos do Compute Engine que já exista no projeto do GKE.

Considere o seguinte exemplo:

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

Nesta configuração, o GKE aplica a política de posicionamento compacto a todas as cargas de trabalho que usam esta ComputeClass e aprovisiona os respetivos nós de acordo com a política de recursos existente denominada my-placement-policy.

Defina parâmetros de escalamento automático para a consolidação de nós

Por predefinição, o GKE remove os nós que são subutilizados pelas cargas de trabalho em execução, consolidando essas cargas de trabalho noutros nós que têm capacidade. Para todas as ComputeClasses, este é o comportamento predefinido, uma vez que todos os clusters que usam ComputeClasses têm de usar o redimensionador automático de clusters ou são clusters do Autopilot. Durante uma consolidação de nós, o GKE esgota um nó subutilizado, recria as cargas de trabalho noutro nó e, em seguida, elimina o nó esgotado.

O momento e os critérios para a remoção de nós dependem do perfil de escalabilidade automática. Pode ajustar os limites de subutilização de recursos que acionam a remoção de nós e a consolidação de cargas de trabalho através da secção autoscalingPolicy na definição da ComputeClass personalizada. Pode ajustar os seguintes parâmetros:

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

Considere o seguinte exemplo:

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

Nesta configuração, o GKE remove os nós não utilizados após cinco minutos e os nós só se tornam candidatos à consolidação se a utilização da CPU e da memória for inferior a 70%.

Configure a migração ativa para nós de prioridade mais elevada

A migração ativa é uma funcionalidade de escalamento automático opcional nas ComputeClasses personalizadas que substitui automaticamente os nós existentes que estão mais abaixo numa lista de prioridade de alternativa da ComputeClass por novos nós que estão mais acima nessa lista de prioridade. Isto garante que todos os seus pods em execução acabam por ser executados nos nós mais preferidos para essa ComputeClass, mesmo que o GKE tenha tido originalmente de executar esses pods em nós menos preferidos.

Quando ocorre uma migração ativa, o GKE cria novos nós com base nas regras de prioridade da ComputeClass e, em seguida, esgota e elimina os nós obsoletos de prioridade inferior. A migração ocorre gradualmente para minimizar a interrupção da carga de trabalho. A migração ativa tem as seguintes considerações:

  • A migração ativa não migra dados armazenados no armazenamento persistente, como os Persistent Disks do Compute Engine. Para minimizar o risco de perda de dados, não ative a migração ativa em ComputeClasses que as cargas de trabalho com estado usam.
  • Se ativou o aprovisionamento automático de nós nos seus clusters padrão, a migração ativa pode acionar a criação de novos conjuntos de nós se os conjuntos de nós existentes não cumprirem os critérios de prioridade mais elevada definidos na sua classe de computação personalizada.
  • A migração ativa não substitui nós que não podem ser removidos. Por exemplo, a migração ativa não substitui um nó se isso violar a --min-nodes definição do conjunto de nós.
  • Para evitar interrupções críticas da carga de trabalho, a migração ativa não move os seguintes pods:
    • Pods que definem um PodDisruptionBudget, se a mudança exceder o PodDisruptionBudget.
    • Pods que têm a anotação cluster-autoscaler.kubernetes.io/safe-to-evict: "false".
  • As cargas de trabalho que usam volumes persistentes com recursos zonais, como o Hyperdisk, podem não funcionar bem com a migração ativa. As restrições zonais e as restrições 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 atualizar uma ComputeClass existente para ativar a migração ativa, o GKE migra os pods existentes para nós de prioridade mais elevada ao longo do tempo.

Considere o seguinte exemplo de especificação ComputeClass, que dá prioridade aos nós N4 em detrimento dos nós C4:

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

Se os nós N4 não estivessem disponíveis quando implementou um pod com esta ComputeClass, o GKE teria usado nós C4 como opção alternativa. Se os nós N4 ficarem disponíveis para aprovisionamento mais tarde, por exemplo, se a sua quota aumentar ou se as VMs N4 ficarem disponíveis na sua localização, o GKE cria um novo nó N4 e migra gradualmente o pod do nó C4 existente para o novo nó N4. Em seguida, o GKE elimina o nó C4 obsoleto.

Consuma reservas do Compute Engine

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

Se usar reservas de capacidade do Compute Engine para ter um nível de garantia mais elevado da disponibilidade de hardware emGoogle Cloud zonas específicas, pode configurar cada prioridade de alternativa na sua ComputeClass personalizada para que o GKE consuma reservas quando criar novos nós.

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

  • Os clusters do modo padrão têm de usar o aprovisionamento automático de nós para que o GKE use reservas para criar novos nós. Para obter detalhes, consulte a secção Aprovisionamento automático de nós e ComputeClasses. Também pode continuar a consumir reservas quando cria manualmente pools de nós no seu cluster.
  • As reservas não baseadas em TPU só podem ser usadas quando machineType ou machineFamily estiver definido.
  • As ComputeClasses que configuram SSDs locais têm de usar a regra de prioridade machineType e não machineFamily. Para obter detalhes, consulte a secção tipo de regra machineType.
  • As ComputeClasses que especificam reservas para um machineType que tenha SSDs locais anexados têm de incluir um campo localSSDCount: explicitamente.

Considere o seguinte exemplo de especificação ComputeClass, que dá prioridade a uma reserva partilhada específica para utilização no aprovisionamento de instâncias a3-highgpu-1g. Se os tipos de instâncias prioritários não estiverem disponíveis, o GKE recorre a quaisquer 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 implementar um pod que use a accelerator-reservations ComputeClass, o GKE tenta primeiro usar a a3-shared-reservation reserva ao criar novas a3-highgpu-1g instâncias para executar o pod. Se esta reserva específica não tiver capacidade disponível, o GKE tenta aumentar as instâncias a3-highgpu-1g usando qualquer reserva correspondente. Se não estiverem acessíveis reservas, o GKE recorre a VMs Spot.a3-highgpu-1g Por último, se não estiverem disponíveis VMs de Spot, a operação de escalamento falha.

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

O exemplo seguinte mostra uma reserva específica partilhada, que recorre a VMs de capacidade instantânea e, finalmente, a VMs a pedido:

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

Pode consumir os seguintes tipos de reservas:

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

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

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

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

  • Quaisquer reservas correspondentes: configure os seguintes campos:

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

As reservas de TPUs requerem afinidade específica. reservations.affinity: AnyBestEffort não é suportado.

Se o GKE não conseguir encontrar capacidade disponível numa reserva, o comportamento resultante depende do tipo de reserva selecionado na regra de prioridade ComputeClass, da seguinte forma:

  • Reservas específicas: o GKE tenta a regra de prioridade seguinte na ComputeClass.
  • Quaisquer reservas correspondentes: o GKE tenta aprovisionar um nó a pedido que cumpra os requisitos dessa regra de prioridade. Se o GKE não conseguir aprovisionar um nó a pedido, o GKE tenta a regra de prioridade seguinte na ComputeClass.

Se o GKE não conseguir cumprir os requisitos de nenhuma das regras de prioridade para a ComputeClass, ocorre o comportamento quando não se aplicam regras.

Consuma blocos de reservas específicos

A partir da versão 1.31.4-gke.1072000 do GKE, pode segmentar um bloco de reserva específico numa reserva suportada por hardware. Esta funcionalidade está disponível para os tipos de máquinas 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, pode segmentar um sub-bloco de reserva específico num bloco de reserva. Esta funcionalidade 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 Consuma sub-blocos de reserva específicos.

Quando usar esta funcionalidade, tenha em atenção as seguintes considerações:

  • Estas funcionalidades aplicam-se apenas a reservas específicas num único projeto ou num projeto partilhado.

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

Pode personalizar determinados parâmetros no kubelet e no kernel do Linux usando o campo nodeSystemConfig na especificação ComputeClass. Pode especificar este 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 pode definir valores globais predefinidos para quaisquer campos de configuração do sistema de nós que sejam omitidos nas regras de prioridade adicionando o campo nodeSystemConfig ao campo priorityDefaults na sua classe de computação.

Esta funcionalidade está disponível na versão 1.32.1-gke.1729000 e posteriores do GKE.

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

ComputeClasses predefinidas para clusters e espaços de nomes

Pode configurar o GKE para aplicar uma ComputeClass por predefinição aos pods que não selecionam uma ComputeClass específica. Pode definir uma ComputeClass predefinida para namespaces específicos ou para um cluster inteiro. Para mais informações sobre como configurar os seus clusters ou espaços de nomes com uma classe predefinida, consulte o artigo Aplique ComputeClasses aos pods por predefinição.

Agrupe node pools

A partir da versão 1.32.2-gke.1359000 do GKE, pode agrupar vários conjuntos de nós numa única unidade lógica denominada coleção através do campo nodePoolGroup na especificação ComputeClass. Este agrupamento permite-lhe aplicar configurações partilhadas em vários conjuntos de nós.

Recolha de vários anfitriões de TPUs

Pode agrupar a implementação de vários anfitriões de TPUs para definir um objetivo de nível de serviço (SLO) em todos os conjuntos de nós na coleção. Para agrupar pools de nós, especifique o nome do grupo no campo nodePoolGroup. Todos os conjuntos de nós aprovisionados com esta 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 mais informações, consulte o seguinte:

Configuração do node pool

O campo nodePoolConfig na especificação ComputeClass permite-lhe aplicar uma configuração que se reflete em todos os nós nos conjuntos de nós criados com essa classe.

Especificar tipo de imagem

Pode especificar o sistema operativo base para os nós no conjunto de nós através do campo imageType. Este campo permite-lhe escolher um tipo de imagem para os conjuntos de nós que vão ser executados nos nós. Se omitir este campo, o valor predefinido é cos_containerd. O exemplo seguinte mostra como especificar o elemento 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 o artigo Imagens de nós.

Conta de serviço

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

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

Para mais informações, consulte o artigo Acerca das contas de serviço no GKE.

Defina o tipo de carga de trabalho para o SLO de TPU

A partir da versão 1.32.2-gke.1359000 do GKE, pode definir o objetivo de nível de serviço (SLO) para as suas cargas de trabalho de TPU através do campo workloadType em nodePoolConfig. O valor neste campo indica ao GKE a utilização pretendida para os recursos de TPU. O campo workloadType suporta os seguintes valores:

  • HIGH_AVAILABILITY: use este valor para cargas de trabalho focadas na disponibilidade, como a publicação de inferências, para limitar e simplificar as interrupções.
  • HIGH_THROUGHPUT: use este valor para tarefas de processamento em lote ou de preparação que exigem que toda a infraestrutura subjacente seja executada na maior parte do tempo para progredir. Este valor só pode ser usado quando nodePoolGroup também estiver especificado.

O exemplo seguinte define uma ComputeClass para uma coleção de TPUs com vários anfitriões 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:

Peça ComputeClasses em cargas de trabalho

Para usar uma ComputeClass personalizada, o seu pod tem de pedir explicitamente essa ComputeClass através de um nodeSelector na especificação do pod. Opcionalmente, pode definir uma ComputeClass como predefinição para um espaço de nomes específico do Kubernetes. Os pods nesse espaço de nomes usam essa ComputeClass, a menos que os pods solicitem uma ComputeClass diferente.

Por exemplo, o seguinte manifesto pede a ComputeClass cost-optimized:

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

Seletores de nós para etiquetas de nós do sistema

O GKE adiciona etiquetas do sistema aos nós para identificar os nós por critérios, como o tipo de máquina, os aceleradores de hardware anexados ou o tipo de disco de arranque. Estas etiquetas do sistema têm um dos seguintes prefixos na chave da etiqueta:

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

Na versão 1.32.3-gke.1499000 e posteriores do GKE, pode implementar cargas de trabalho que usam um seletor de nós para selecionar etiquetas do sistema e uma ComputeClass ao mesmo tempo. Se selecionar etiquetas do sistema em pods que selecionam classes de computação, verifique se esses pods são agendados conforme esperado. Um conflito entre a configuração de uma ComputeClass e os seletores de nós num pod pode resultar em problemas como os seguintes:

  • O GKE não pode criar nós que usem a configuração de prioridade mais alta para a ComputeClass.
  • O Pod permanece no estado Pending.

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

Etiqueta do nó ComputeClass campo
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

O que se segue?