Acerca da escala automática do cluster do GKE

Esta página explica como o Google Kubernetes Engine (GKE) redimensiona automaticamente os node pools do seu cluster Standard com base nas exigências das suas cargas de trabalho. Quando a procura é elevada, o escalador automático de clusters adiciona nós ao node pool. Para saber como configurar o redimensionador automático de clusters, consulte o artigo Redimensionar automaticamente um cluster.

Esta página destina-se a administradores, arquitetos e operadores que planeiam as necessidades de capacidade e infraestrutura, e otimizam a arquitetura dos sistemas e os recursos para alcançar o custo total de propriedade mais baixo para a respetiva empresa ou unidade de negócio. Para saber mais sobre as funções comuns e as tarefas de exemplo que referimos no Google Cloud conteúdo, consulte Funções e tarefas comuns do utilizador do GKE.

Com os clusters do Autopilot, não tem de se preocupar com o aprovisionamento de nós nem com a gestão de conjuntos de nós, porque os conjuntos de nós são aprovisionados automaticamente através do aprovisionamento automático de nós e são dimensionados automaticamente para satisfazer os requisitos das suas cargas de trabalho.

Antes de ler esta página, certifique-se de que está familiarizado com os conceitos básicos do Kubernetes e como funcionam os pedidos e os limites de recursos.

Prática recomendada:

Planeie e crie a configuração do cluster com os administradores e os arquitetos, os programadores ou outra equipa da sua organização responsável pela implementação e manutenção da sua aplicação.

Por que motivo deve usar o redimensionador automático de clusters

O redimensionador automático de clusters do GKE redimensiona automaticamente o número de nós num determinado node pool com base nas exigências das suas cargas de trabalho. Quando a procura é baixa, o dimensionamento automático do cluster reduz a escala até um tamanho mínimo que designa. Isto pode aumentar a disponibilidade das suas cargas de trabalho quando precisar, ao mesmo tempo que controla os custos. Não precisa de adicionar nem remover nós manualmente, nem de aprovisionar em excesso os seus conjuntos de nós. Em vez disso, especifica um tamanho mínimo e máximo para o conjunto de nós, e o resto é automático.

Se os recursos forem eliminados ou movidos quando dimensionar automaticamente o cluster, as cargas de trabalho podem sofrer interrupções temporárias. Por exemplo, se a sua carga de trabalho consistir num controlador com uma única réplica, o pod dessa réplica pode ser reagendado para um nó diferente se o nó atual for eliminado. Antes de ativar o escalador automático de clusters, crie as suas cargas de trabalho para tolerar uma potencial interrupção ou certifique-se de que os pods críticos não são interrompidos.

Prática recomendada:

Para aumentar a tolerância da sua carga de trabalho a interrupções, implemente-a usando um controlador com várias réplicas, como uma implementação.

Pode aumentar o desempenho do dimensionamento automático de clusters com o streaming de imagens, que transmite remotamente os dados de imagens necessários a partir de imagens de contentores elegíveis, enquanto armazena em cache simultaneamente a imagem localmente para permitir que as cargas de trabalho em novos nós sejam iniciadas mais rapidamente.

Como funciona o redimensionador automático de clusters

O redimensionador automático de clusters funciona por node pool. Quando configura um node pool com o escalador automático de clusters, especifica um tamanho mínimo e máximo para o node pool.

O Cluster Autoscaler aumenta ou diminui automaticamente o tamanho do node pool adicionando ou removendo instâncias de máquinas virtuais (VMs) no grupo de instâncias geridas (GIG) do Compute Engine subjacente para o node pool. O redimensionador automático de cluster toma estas decisões de escalabilidade com base nos pedidos de recursos (em vez da utilização real de recursos) dos pods em execução nos nós desse conjunto de nós. Verifica periodicamente o estado dos pods e dos nós, e toma medidas:

  • Se não for possível agendar pods em nenhum dos nós atuais, o redimensionador automático de clusters adiciona nós até ao tamanho máximo do conjunto de nós. Para mais informações sobre quando o redimensionador automático de clusters altera o tamanho de um cluster, consulte o artigo Quando é que o redimensionador automático de clusters altera o tamanho de um cluster?
  • Se o GKE decidir adicionar novos nós ao node pool, o escalador automático do cluster adiciona tantos nós quanto necessário, até aos limites por node pool ou por cluster.
  • O redimensionador automático de clusters não espera que um nó seja iniciado antes de criar o seguinte. Depois de o GKE decidir quantos nós criar, a criação de nós ocorre em paralelo. O objetivo é minimizar o tempo necessário para que os pods não agendáveis se tornem Active.
  • Se alguns nós não forem criados devido ao esgotamento da quota, o redimensionador automático de clusters aguarda até que seja possível agendar recursos com êxito.
  • Se os nós estiverem subutilizados e todos os pods puderem ser agendados mesmo com menos nós no conjunto de nós, o escalador automático de clusters remove nós até ao tamanho mínimo do conjunto de nós. Se existirem pods num nó que não possam ser movidos para outros nós no cluster, o redimensionador automático de clusters não tenta reduzir a escala desse nó. Se for possível mover os pods para outros nós, mas não for possível esvaziar o nó de forma graciosa após um período de tempo limite (atualmente, 10 minutos), o nó é terminado à força. O período de tolerância não é configurável para clusters do GKE. Para mais informações sobre o funcionamento da redução, consulte a documentação do escalador automático de clusters.

A frequência com que o redimensionador automático de clusters inspeciona um cluster para verificar se existem pods não agendáveis depende em grande medida do tamanho do cluster. Em pequenos clusters, a inspeção pode ocorrer a cada poucos segundos. Não é possível definir um período exato necessário para esta inspeção.

Se os seus nós estiverem a sofrer escassez porque os seus pods pediram ou usaram por predefinição recursos insuficientes, o escalador automático do cluster não corrige a situação. Pode ajudar a garantir que o escalador automático do cluster funciona com a maior precisão possível fazendo pedidos de recursos explícitos para todas as suas cargas de trabalho.

Não ative a escala automática do Compute Engine para grupos de instâncias geridos para os nós do cluster. O redimensionador automático de clusters do GKE é separado da escala automática do Compute Engine. Isto pode fazer com que os node pools não consigam aumentar ou diminuir a escala, porque o escalador automático do Compute Engine vai estar em conflito com o escalador automático do cluster do GKE.

Critérios de funcionamento

Quando redimensiona um node pool, o escalador automático do cluster faz as seguintes suposições:

  • Todos os pods replicados podem ser reiniciados noutro nó, o que pode causar uma breve interrupção.
  • Os utilizadores ou os administradores não estão a gerir manualmente os nós. O redimensionador automático de clusters pode substituir quaisquer operações de gestão de nós manuais que realizar.
  • Todos os nós num único conjunto de nós têm o mesmo conjunto de etiquetas.
  • O redimensionador automático de clusters considera o custo relativo dos tipos de instâncias nos vários pools e tenta expandir o node pool possível mais barato. No entanto, aplicam-se as seguintes condições a este comportamento do escalador automático de clusters:
    • O redimensionador automático de cluster tem em conta o custo reduzido dos node pools que contêm VMs Spot, que são preemptíveis. No entanto, o escalador automático de clusters também considera a disponibilidade de recursos em cada zona e pode escolher o recurso mais caro, mas disponível.
    • Quando vários conjuntos de nós usam VMs Spot, o escalador automático do cluster não seleciona automaticamente a opção de custo mais baixo. Para otimizar a utilização de VMs do Spot económicas e evitar este cenário, recomendamos que use classes de computação personalizadas.
  • O redimensionador automático de clusters considera os pedidos de contentores de inicialização antes de agendar os pods. Os pedidos de contentores de inicialização podem usar quaisquer recursos não atribuídos disponíveis nos nós, o que pode impedir o agendamento de pods. O redimensionador automático de clusters segue as mesmas regras de cálculo de pedidos que o Kubernetes usa. Para saber mais, consulte a documentação do Kubernetes sobre a utilização de contentores init.
  • As etiquetas adicionadas manualmente após a criação inicial do cluster ou do conjunto de nós não são monitorizadas. Os nós criados pelo escalador automático de clusters são atribuídos a etiquetas especificadas com --node-labels no momento da criação do node pool.
  • Na versão 1.21 ou anterior do GKE, o escalador automático de clusters considera as informações de contaminação dos nós existentes de um conjunto de nós para representar todo o conjunto de nós. A partir da versão 1.22 do GKE, o escalador automático de clusters combina informações dos nós existentes no cluster e no node pool. O Cluster autoscaler também deteta as alterações manuais que faz ao nó e ao node pool.
Prática recomendada:

Não ative o redimensionador automático de clusters se as suas aplicações não forem tolerantes a interrupções.

Equilibrar entre zonas

Se o seu conjunto de nós contiver vários grupos de instâncias geridos com o mesmo tipo de instância, o escalador automático do cluster tenta manter estes tamanhos dos grupos de instâncias geridos equilibrados ao aumentar a escala. Isto ajuda a evitar uma distribuição desigual de nós entre grupos de instâncias geridos em várias zonas de um conjunto de nós. O GKE não considera a política de escala automática quando reduz a escala.

O redimensionador automático de clusters só equilibra as zonas durante um evento de expansão. O redimensionador automático de clusters reduz a escala dos nós subusados, independentemente dos tamanhos relativos dos grupos de instâncias geridos subjacentes num conjunto de nós, o que pode fazer com que os nós sejam distribuídos de forma desigual entre as zonas.

Política de localização

A partir da versão 1.24.1-gke.800 do GKE, pode alterar a política de localização do escalador automático de clusters. Pode controlar a política de distribuição do escalador automático de clusters especificando a flag location_policy com qualquer um dos seguintes valores:

  • BALANCED: esta política indica ao redimensionador automático de cluster que distribua os recursos do node pool pelas zonas selecionadas da forma mais equitativa possível, da melhor forma possível, ao mesmo tempo que considera os requisitos dos pods (como a afinidade) e a disponibilidade de recursos. Esta política é a política de localização predefinida para pools de nós que usam reservas ou nós a pedido, mas também pode usá-la para VMs Spot. O BALANCED não é suportado para pools de nós no modo de aprovisionamento de início flexível.
  • ANY: esta política indica ao escalador automático do cluster que procure a capacidade pedida em todas as zonas especificadas. O escalador automático de clusters dá prioridade às reservas não usadas e às zonas com capacidade suficiente, o que pode levar à concentração de recursos do conjunto de nós. É a política de localização predefinida para o modo de aprovisionamento de início flexível e os conjuntos de nós que usam VMs Spot, mas também pode usá-la para conjuntos de nós que usam reservas ou nós a pedido.
Prática recomendada:

Use a política BALANCED se as suas cargas de trabalho usarem apenas recursos de acelerador facilmente obteníveis e beneficiarem da distribuição por zonas (por exemplo, para uma melhor tolerância a falhas). Use a política ANY para priorizar a utilização de reservas não utilizadas e uma maior obtenção de recursos de computação escassos (como aceleradores).

Reservas

A partir da versão 1.27 do GKE, o escalador automático do cluster considera sempre as reservas quando toma as decisões de escalamento vertical. Os conjuntos de nós com reservas não usadas correspondentes são prioritários quando escolhe o conjunto de nós para aumentar a escala, mesmo quando o conjunto de nós não é o mais eficiente. Além disso, as reservas não usadas são sempre priorizadas quando equilibram os aumentos de escala multizonais.

No entanto, o redimensionador automático de clusters verifica as reservas apenas no seu próprio projeto. Como resultado, se estiver disponível uma opção de nó menos dispendiosa no projeto do cluster, o escalador automático pode selecionar essa opção em vez da reserva partilhada. Se precisar de partilhar reservas entre projetos, considere usar classes de computação personalizadas, que lhe permitem configurar a prioridade que o redimensionador automático de clusters usa para redimensionar nós, incluindo reservas partilhadas.

Valores predefinidos

Para node pools de VMs Spot, a política de distribuição do escalador automático de clusters predefinida é ANY. Nesta política, as VMs de capacidade instantânea têm um risco menor de serem anuladas.

Para pools de nós não preemptíveis, a política de distribuição do escalador automático de clusters predefinida é BALANCED.

Tamanho mínimo e máximo do conjunto de nós

Quando cria um novo conjunto de nós, pode especificar o tamanho mínimo e máximo de cada conjunto de nós no cluster. O escalador automático do cluster toma decisões de reescalonamento dentro destas restrições de escalonamento. Para atualizar o tamanho mínimo, redimensione manualmente o cluster para um tamanho dentro das novas restrições depois de especificar o novo valor mínimo. Em seguida, o escalador automático do cluster toma decisões de reescalonamento com base nas novas restrições.

Tamanho atual do node pool Ação do redimensionador automático de clusters Restrições de dimensionamento
Inferior ao mínimo especificado O redimensionador automático de clusters aumenta a escala para aprovisionar pods pendentes. A redução está desativada. O conjunto de nós não é reduzido abaixo do valor especificado.
Dentro do tamanho mínimo e máximo especificado O redimensionador automático de clusters aumenta ou reduz recursos de acordo com a procura. O conjunto de nós permanece dentro dos limites de tamanho especificados.
Superior ao máximo especificado O redimensionador automático de clusters reduz apenas os nós que podem ser removidos com segurança. O aumento da escala está desativado. O conjunto de nós não é dimensionado acima do valor especificado.

Em clusters padrão, o redimensionador automático de clusters nunca reduz automaticamente um cluster para zero nós. Um ou mais nós têm de estar sempre disponíveis no cluster para executar pods do sistema. Além disso, se o número atual de nós for zero devido à remoção manual de nós, o dimensionamento automático do cluster e o aprovisionamento automático de nós podem ser dimensionados a partir de clusters com zero nós.

Para saber mais sobre as decisões do escalador automático, consulte as limitações do escalador automático de clusters.

Limites da escala automática

Pode definir o número mínimo e máximo de nós que o redimensionador automático de clusters deve usar ao redimensionar um conjunto de nós. Use as flags --min-nodes e --max-nodes para definir o número mínimo e máximo de nós por zona

A partir da versão 1.24 do GKE, pode usar as flags --total-min-nodes e --total-max-nodes para novos clusters. Estas flags definem o número mínimo e máximo do número total de nós no conjunto de nós em todas as zonas.

Exemplo de nós mínimos e máximos

O comando seguinte cria um cluster multizonal com dimensionamento automático com seis nós em três zonas inicialmente, com um mínimo de um nó por zona e um máximo de quatro nós por zona:

gcloud container clusters create example-cluster \
    --num-nodes=2 \
    --location=us-central1-a \
    --node-locations=us-central1-a,us-central1-b,us-central1-f \
    --enable-autoscaling --min-nodes=1 --max-nodes=4

Neste exemplo, o tamanho total do cluster pode estar entre três e doze nós, distribuídos pelas três zonas. Se uma das zonas falhar, o tamanho total do cluster pode estar entre dois e oito nós.

Exemplo de total de nós

O comando seguinte, disponível na versão 1.24 ou posterior do GKE, cria um grupo de nós de várias zonas com seis nós em três zonas inicialmente, com um mínimo de três nós e um máximo de doze nós no conjunto de nós em todas as zonas:

gcloud container clusters create example-cluster \
    --num-nodes=2 \
    --location=us-central1-a \
    --node-locations=us-central1-a,us-central1-b,us-central1-f \
    --enable-autoscaling --total-min-nodes=3 --total-max-nodes=12

Neste exemplo, o tamanho total do cluster pode estar entre três e doze nós, independentemente da distribuição entre zonas.

Perfis de escala automática

A decisão de quando remover um nó é um compromisso entre a otimização da utilização ou a disponibilidade de recursos. A remoção de nós pouco usados melhora a utilização do cluster, mas as novas cargas de trabalho podem ter de aguardar que os recursos sejam novamente aprovisionados antes de poderem ser executadas.

Pode especificar que perfil de dimensionamento automático usar quando tomar essas decisões. Os perfis disponíveis são:

  • balanced: o perfil predefinido que dá prioridade a manter mais recursos facilmente disponíveis para os agrupamentos recebidos e, assim, reduzir o tempo necessário para os ter ativos para clusters padrão. O perfil balanced não está disponível para clusters do Autopilot.
  • optimize-utilization: Priorize a otimização da utilização em vez de manter recursos adicionais no cluster. Quando ativa este perfil, o dimensionamento automático do cluster reduz o cluster de forma mais agressiva. O GKE pode remover mais nós e remover nós mais rapidamente. O GKE prefere agendar pods em nós que já tenham uma atribuição elevada de CPU, memória ou GPUs. No entanto, outros fatores influenciam o agendamento, como a distribuição de pods pertencentes à mesma implementação, StatefulSet ou serviço, entre nós.

O perfil de optimize-utilizationdimensionamento automático ajuda o dimensionador automático do cluster a identificar e remover nós subutilizados. Para alcançar esta otimização, o GKE define o nome do agendador na especificação do pod como gke.io/optimize-utilization-scheduler. Os pods que especificam um programador personalizado não são afetados.

O seguinte comando ativa o optimize-utilizationperfil de escalamento automático num cluster existente:

gcloud container clusters update CLUSTER_NAME \
    --autoscaling-profile optimize-utilization

Considerando o agendamento e a interrupção de pods

Ao reduzir a escala, o redimensionador automático de cluster respeita as regras de agendamento e despejo definidas nos pods. Estas restrições podem impedir que um nó seja eliminado pelo escalador automático. A eliminação de um nó pode ser impedida se este contiver um pod com qualquer uma das seguintes condições:

  • As regras de afinidade ou anti-afinidade do Pod impedem o reagendamento.
  • O pod não é gerido por um controlador, como uma implementação, um StatefulSet, um trabalho ou um ReplicaSet.
  • O pod tem armazenamento local e a versão do plano de controlo do GKE é inferior a 1.22. Nos clusters do GKE com a versão 1.22 ou posterior do plano de controlo, os pods com armazenamento local já não bloqueiam a redução da escala.
  • O agrupamento tem a anotação "cluster-autoscaler.kubernetes.io/safe-to-evict": "false".
  • A eliminação do nó excederia o PodDisruptionBudget configurado.

Para mais informações sobre o redimensionador automático de clusters e a prevenção de interrupções, consulte as seguintes perguntas nas Perguntas frequentes sobre o redimensionador automático de clusters:

Escala automática de TPUs no GKE

O GKE suporta unidades de processamento tensor (TPUs) para acelerar as cargas de trabalho de aprendizagem automática. O conjunto de nós de fatia de TPU de anfitrião único e o conjunto de nós de fatia de TPU de vários anfitriões suportam o dimensionamento automático e o aprovisionamento automático.

Com a flag --enable-autoprovisioning num cluster do GKE, o GKE cria ou elimina pools de nós de fatias de TPU de anfitrião único ou vários anfitriões com uma versão e uma topologia da TPU que cumprem os requisitos das cargas de trabalho pendentes.

Quando usa o --enable-autoscaling, o GKE dimensiona o conjunto de nós com base no respetivo tipo, da seguinte forma:

  • Pool de nós de fatia de TPU de host único: o GKE adiciona ou remove nós de TPU no pool de nós existente. O conjunto de nós pode conter qualquer número de nós de TPU entre zero e o tamanho máximo do conjunto de nós, conforme determinado pelas flags --max-nodes e --total-max-nodes. Quando o conjunto de nós é dimensionado, todos os nós da TPU no conjunto de nós têm o mesmo tipo de máquina e topologia. Para saber como criar um node pool de fatia de TPU de host único, consulte o artigo Crie um node pool.

  • Pool de nós de fatia de TPU com vários anfitriões: o GKE aumenta automaticamente a escala do pool de nós de zero para o número de nós necessários para satisfazer a topologia da TPU. Por exemplo, com um conjunto de nós da TPU com um tipo de máquina ct5lp-hightpu-4t e uma topologia de 16x16, o conjunto de nós contém 64 nós. O escalador automático do GKE garante que este conjunto de nós tem exatamente 0 ou 64 nós. Quando reduz a escala, o GKE despeja todos os pods agendados e esgota todo o conjunto de nós até zero. Para saber como criar um node pool de fatia de TPU com vários anfitriões, consulte o artigo Crie um node pool.

VMs do Spot e redimensionador automático de clusters

Uma vez que o escalamento automático de clusters prefere expandir os conjuntos de nós menos dispendiosos, quando as suas cargas de trabalho e a disponibilidade de recursos o permitem, o escalamento automático de clusters adiciona VMs Spot durante o escalamento.

No entanto, embora o escalador automático de clusters prefira adicionar VMs Spot, esta preferência não garante que a maioria dos seus pods seja executada nestes tipos de VMs. As VMs do Spot podem ser anuladas. Devido a esta preempção, é mais provável que os pods em VMs Spot sejam despejados. Quando são removidos, têm apenas 15 segundos para terminar.

Por exemplo, imagine um cenário em que tem 10 pods e uma mistura de VMs a pedido e VMs Spot:

  • Começa com 10 agrupamentos em execução em VMs a pedido porque as VMs de desconto não estavam disponíveis.
  • Não precisa de todos os 10 pods, pelo que o redimensionador automático de cluster remove dois pods e desliga as VMs a pedido adicionais.
  • Quando precisar novamente de 10 pods, o escalador automático do cluster adiciona VMs Spot (porque são mais baratas) e agenda dois pods nas mesmas. Os outros oito pods permanecem nas VMs a pedido.
  • Se o escalador automático do cluster precisar de reduzir novamente a escala, é provável que as VMs Spot sejam as primeiras a serem anuladas, deixando a maioria dos seus pods em execução em VMs a pedido.

Para dar prioridade às VMs de capacidade instantânea e evitar o cenário anterior, recomendamos que use classes de computação personalizadas. As classes de computação personalizadas permitem-lhe criar regras de prioridade que favorecem as VMs Spot durante o aumento da escala, dando-lhes uma prioridade mais elevada do que os nós a pedido. Para maximizar ainda mais a probabilidade de os seus pods serem executados em nós suportados por VMs Spot, configure a migração ativa.

O exemplo seguinte mostra uma forma de usar classes de computação personalizadas para priorizar VMs Spot. Para saber mais acerca dos parâmetros ComputeClass, consulte a documentação da CRD ComputeClass:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: prefer-l4-spot
spec:
  # Defines a prioritized list of machine types and configurations for node provisioning.
  priorities:
  - machineType: g2-standard-24
    # Specifically requests Spot VMs for this configuration. GKE will try to provision these VMs first.
    spot: true
    gpu:
      type: nvidia-l4
      count: 2
  # If GKE can't satisfy the preceding rule, request on-demand nodes with the same configuration
  - machineType: g2-standard-24
    spot: false
    gpu:
      type: nvidia-l4
      count: 2
  nodePoolAutoCreation:
    enabled: true
  # Configures active migration behavior for workloads using this ComputeClass.
  activeMigration:
    optimizeRulePriority: true
    # Enables Cluster Autoscaler to attempt to migrate workloads to Spot VMs
    # if Spot capacity becomes available and the workload is currently
    # running on an on-demand VM (based on the priority rules in this example).

No exemplo anterior, a regra de prioridade declara uma preferência pela criação de nós com o tipo de máquina g2-standard-24 e VMs de Spot. Se as VMs de capacidade disponível não estiverem disponíveis, o GKE usa VMs a pedido como opção alternativa. Esta classe de computação também permite activeMigration, ativar o redimensionador automático de clusters para migrar cargas de trabalho para VMs do Spot quando a capacidade fica disponível.

Se não puder usar classes de computação personalizadas, adicione uma afinidade de nós, uma mancha ou uma tolerância. Por exemplo, a seguinte regra de afinidade de nós declara uma preferência pela programação de pods em nós suportados por VMs Spot (o GKE adiciona automaticamente a etiqueta cloud.google.com/gke-spot=true a estes tipos de nós):

affinity:
  nodeAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 1
      preference:
        matchExpressions:
        # set to "true". GKE automatically applies this label to Spot VMs.
        - key: cloud.google.com/gke-spot
          operator: Equal
          values:
          - true

Para saber como usar afinidades de nós, taints e tolerâncias para agendar VMs Spot, consulte o blogue Executar uma aplicação GKE em nós spot com nós a pedido como alternativa.

CRD ProvisioningRequest

Um ProvisioningRequest é um recurso personalizado com espaço de nomes que permite aos utilizadores pedir capacidade para um grupo de pods ao redimensionador automático de cluster. Isto é particularmente útil para aplicações com pods interligados que têm de ser agendados em conjunto como uma única unidade.

Classes de aprovisionamento suportadas

Existem três ProvisioningClasses suportadas:

  • queued-provisioning.gke.io: esta classe específica do GKE integra-se com o programador de cargas de trabalho dinâmico, permite-lhe colocar pedidos em fila e vê-los serem processados quando os recursos ficam disponíveis. Esta opção é ideal para tarefas de lotes ou cargas de trabalho tolerantes a atrasos. Consulte o artigo Implemente GPUs para cargas de trabalho de IA e em lote com o Dynamic Workload Scheduler para saber como usar o aprovisionamento em fila no GKE. Suportado a partir da versão 1.28.3-gke.1098000 do GKE em clusters padrão e a partir da versão 1.30.3-gke.1451000 do GKE em clusters do Autopilot.

  • check-capacity.autoscaling.x-k8s.io: esta classe de código aberto verifica a disponibilidade de recursos antes de tentar agendar pods. Suportado a partir da versão 1.30.2-gke.1468000 do GKE.

  • best-effort-atomic.autoscaling.x-k8s.io: esta classe de código aberto tenta aprovisionar recursos para todos os pods no pedido em conjunto. Se for impossível aprovisionar recursos suficientes para todos os agrupamentos, não são aprovisionados recursos e todo o pedido falha. Suportado a partir da versão 1.31.27 do GKE.

Para saber mais acerca das classes CheckCapacity e BestEffortAtomicScaleUp, consulte a documentação de código aberto.

Limitações durante a utilização de ProvisioningRequest

  • O redimensionador automático de clusters do GKE suporta apenas 1 PodTemplate por ProvisioningRequest.
  • O redimensionador automático de clusters do GKE só pode aumentar a escala de um conjunto de nós de cada vez. Se o seu ProvisioningRequest exigir recursos de vários conjuntos de nós, tem de criar ProvisioningRequests separados para cada conjunto de nós.

Práticas recomendadas ao usar ProvisioningRequest

  • Use total-max-nodes: em vez de limitar o número máximo de nós (--max nodes), use --total-max-nodes para restringir os recursos totais consumidos pela sua aplicação.
  • Usar location-policy=ANY: esta definição permite que os seus Pods sejam agendados em qualquer localização disponível, o que pode acelerar o aprovisionamento e otimizar a utilização de recursos.
  • (Opcional) Integre com o Kueue: o Kueue pode automatizar a criação de ProvisioningRequests, simplificando o seu fluxo de trabalho. Para mais informações, consulte a documentação do Kueue.

Períodos de retirada

Uma operação de expansão pode falhar devido a erros de criação de nós, como quota insuficiente ou esgotamento de endereços IP. Quando estes erros ocorrem, o grupo de instâncias geridas (MIG) subjacente tenta novamente a operação após um recuo inicial de cinco minutos. Se os erros continuarem, este período de recuo aumenta exponencialmente até um máximo de 30 minutos. Durante este período, o redimensionador automático de clusters pode continuar a aumentar a escala de outros conjuntos de nós no cluster que não estejam a ter erros.

Informações adicionais

Pode encontrar mais informações sobre o redimensionador automático de clusters nas Perguntas frequentes sobre o redimensionamento automático no projeto Kubernetes de código aberto.

Limitações

O redimensionador automático de clusters tem as seguintes limitações:

  • Os volumes persistentes locais não são suportados pelo escalador automático do cluster.
  • Na versão do plano de controlo do GKE anterior a 1.24.5-gke.600, quando os pods pedem armazenamento efémero, o escalador automático do cluster não suporta o aumento da escala de um conjunto de nós com zero nós que usa SSD locais como armazenamento efémero.
  • Limitações de tamanho do cluster: até 15 000 nós. Tenha em conta outros limites de clusters e as nossas práticas recomendadas quando executar clusters deste tamanho.
  • Quando reduz a escala, o dimensionamento automático do cluster respeita um período de encerramento gradual de 10 minutos para reagendar os pods do nó para um nó diferente antes de terminar o nó à força.
  • Ocasionalmente, o redimensionador automático de clusters não consegue reduzir completamente os recursos e existe um nó adicional após a redução dos recursos. Isto pode ocorrer quando os pods do sistema necessários são agendados em nós diferentes, porque não existe nenhum acionador para que qualquer um desses pods seja movido para um nó diferente. Veja Tenho alguns nós com baixa utilização, mas não são reduzidos. Porquê?. Para contornar esta limitação, pode configurar um orçamento de interrupção de pods.
  • A programação personalizada com filtros alterados não é suportada.
  • O escalador automático de clusters considera o comportamento predefinido do kube-scheduler quando decide aprovisionar novos nós para pods pendentes. A utilização de programadores personalizados não é suportada e pode resultar num comportamento de escalabilidade inesperado.
  • Os nós não são dimensionados se os pods tiverem um valor PriorityClass inferior a -10. Saiba mais em Como funciona o redimensionador automático de clusters com a prioridade e a preemptividade de pods?
  • O redimensionador automático de clusters pode não ter espaço de endereço IP não atribuído suficiente para usar para adicionar novos nós ou pods, o que resulta em falhas de aumento de recursos, indicadas por eventos eventResult com o motivo scale.up.error.ip.space.exhausted. Pode adicionar mais endereços IP para nós expandindo a sub-rede principal ou adicionar novos endereços IP para pods através do CIDR de vários pods não contíguos. Para mais informações, consulte o artigo Não existe espaço de IP livre suficiente para os pods.
  • O redimensionador automático de clusters do GKE é diferente do redimensionador automático de clusters do projeto Kubernetes de código aberto. Os parâmetros do escalador automático do cluster do GKE dependem da configuração do cluster e estão sujeitos a alterações. Se precisar de mais controlo sobre o comportamento da escala automática, desative o redimensionador automático de clusters do GKE e execute o redimensionador automático de clusters do Kubernetes de código aberto. No entanto, o Kubernetes de código aberto não tem Google Cloud suporte.
  • Quando elimina um conjunto de nós do GKE com o dimensionamento automático ativado, os nós recebem a flag NoSchedule definida e todos os pods nesses nós são imediatamente removidos. Para mitigar a diminuição súbita dos recursos disponíveis, o dimensionamento automático do conjunto de nós pode aprovisionar novos nós no mesmo conjunto de nós. Estes nós recém-criados ficam disponíveis para agendamento e os pods desalojados são agendados novamente neles. Eventualmente, todo o conjunto de nós, incluindo os nós aprovisionados recentemente e os respetivos pods, é eliminado, o que pode originar potenciais interrupções do serviço. Como solução alternativa, para impedir que o escalador automático aprovisione novos nós durante a eliminação, desative o escalamento automático no conjunto de nós antes de iniciar a eliminação.
  • O redimensionador automático de clusters tem de prever a quantidade de recursos disponíveis em novos nós para tomar decisões de escalabilidade. Os pods DaemonSet estão incluídos, o que diminui os recursos disponíveis. As previsões não são 100% precisas e a quantidade de recursos disponíveis pode variar entre as versões do GKE. Por este motivo, não recomendamos o dimensionamento nem a restrição de cargas de trabalho para se ajustarem a um tipo de instância específico. Em alternativa, considere usar classes de computação personalizadas. Se uma carga de trabalho precisar de segmentar um tipo de instância específico, certifique-se de que o dimensiona de forma a deixar um buffer de recursos atribuíveis nos nós. Nesse caso, também tem de garantir que todos os pods DaemonSet relevantes cabem nos nós juntamente com os pods de carga de trabalho.
  • O redimensionador automático de clusters não suporta restrições de dispersão da topologia de pods rigorosas quando o campo whenUnsatisfiable está definido com o valor DoNotSchedule. Pode suavizar os requisitos de dispersão definindo o campo whenUnsatisfiable com o valor ScheduleAnyway.

Problemas conhecidos

  • Na versão do plano de controlo do GKE anterior à 1.22, o escalador automático do cluster do GKE deixa de aumentar a escala de todos os conjuntos de nós em clusters vazios (com zero nós). Este comportamento não ocorre no GKE na versão 1.22 e posteriores.

Resolução de problemas

Para obter conselhos sobre resolução de problemas, consulte as seguintes páginas:

O que se segue?