Container Service for Kubernetes:Node auto scaling FAQ

Os recursos disponíveis do nó podem não corresponder às especificações do tipo de instância

Os recursos disponíveis em um nó recém-provisionado são sempre ligeiramente inferiores às especificações anunciadas para o tipo de instância. O sistema operacional subjacente e os daemons do sistema na instância do Elastic Compute Service (ECS) consomem parte da CPU, memória e armazenamento antes do agendamento de qualquer pod. Para obter detalhes, consulte Por que o tamanho da memória é diferente da especificação do tipo de instância após a compra de uma instância?

Devido a essa sobrecarga, considere os pontos abaixo ao configurar as solicitações de recursos dos pods:

• Mantenha o total de solicitações abaixo da capacidade total da instância. Como diretriz geral, as solicitações totais de recursos de um pod não devem exceder 70% da capacidade do nó.

• Considere os static pods não gerenciados como DaemonSets. O cluster-autoscaler considera apenas as solicitações de recursos dos pods do Kubernetes (incluindo pods pendentes e pods de DaemonSet) ao avaliar a capacidade do nó. Reserve recursos manualmente para quaisquer static pods fora desse escopo.

• Teste pods com uso intenso de recursos antes da implantação em larga escala. Se um pod solicitar mais de 70% dos recursos de um nó, teste e confirme antecipadamente se ele pode ser agendado em um nó do mesmo tipo de instância.

O suporte a políticas de agendamento é limitado

O cluster-autoscaler suporta apenas um conjunto limitado de políticas de agendamento ao determinar se um pod não agendável cabe em um node pool com Auto Scaling ativado. Para obter detalhes, consulte Quais políticas de agendamento o cluster-autoscaler utiliza?

Apenas políticas do tipo resource são suportadas no ResourcePolicy

Ao usar ResourcePolicy para personalizar a prioridade de recursos elásticos, somente políticas do tipo resource são suportadas. Para mais informações, consulte Personalizar o agendamento de prioridade de recursos elásticos.

apiVersion: scheduling.alibabacloud.com/v1alpha1
kind: ResourcePolicy
metadata:
  name: nginx
  namespace: default
spec:
  selector:
    app: nginx
  units:
  - resource: ecs
  - resource: eci

Não há suporte para scale-out de um tipo de instância específico em um node pool com múltiplos tipos

Se um node pool estiver configurado com vários tipos de instância, não é possível direcionar o cluster-autoscaler para provisionar um tipo específico durante o scale-out. O autoscaler modela a capacidade de todo o node pool com base no menor tipo de instância disponível — aquele com menos recursos entre todos os tipos configurados. Para detalhes, consulte Como o autoscaler calcula a capacidade de um node pool com múltiplos tipos de instância?

Pods com restrições específicas de zona podem não acionar o scale-out em node pools multizona

Caso um node pool abranja várias zonas de disponibilidade, um pod com dependência de zona pode não acionar um scale-out. Isso se aplica a pods que exigem uma zona específica devido a:

• Uma persistent volume claim (PVC) vinculada a um volume nessa zona.

• Um nodeSelector, nodeAffinity ou outra regra de agendamento direcionada à zona.

Nesses casos, o cluster-autoscaler pode falhar ao provisionar um nó na zona necessária. Para mais cenários, consulte Por que meu node pool falha ao provisionar novos nós?

Restrições de armazenamento são invisíveis para o autoscaler

O autoscaler não tem visibilidade das restrições de armazenamento no nível do pod, tais como:

• Necessidade de execução em uma zona de disponibilidade específica para acessar um persistent volume (PV).

• Requisito de um nó que suporte um tipo de disco específico (como ESSD).

Solução: Configure um node pool dedicado para aplicações com dependências de armazenamento antes de ativar o Auto Scaling. Defina a zona de disponibilidade, o tipo de instância e o tipo de disco na configuração do node pool para garantir que os nós recém-provisionados atendam aos requisitos de armazenamento do pod.

Certifique-se também de que seus pods não referenciem uma PVC em estado Terminating. Um pod que não consegue ser agendado porque sua PVC está sendo encerrada falhará continuamente, o que pode levar o cluster-autoscaler a tomar decisões incorretas de scale-out ou scale-in (por exemplo, evictar o pod).

Quais políticas de agendamento o cluster-autoscaler usa para determinar se um pod não agendável pode ser agendado em um node pool com Auto Scaling ativado?

O cluster-autoscaler avalia as seguintes políticas de agendamento:

• PodFitsResources

• GeneralPredicates

• PodToleratesNodeTaints

• MaxGCEPDVolumeCount

• NoDiskConflict

• CheckNodeCondition

• CheckNodeDiskPressure

• CheckNodeMemoryPressure

• CheckNodePIDPressure

• CheckVolumeBinding

• MaxAzureDiskVolumeCount

• MaxEBSVolumeCount

• ready

• NoVolumeZoneConflict

Quais tipos de recursos o cluster-autoscaler pode simular durante a análise de agendamento?

O cluster-autoscaler consegue simular e avaliar os seguintes tipos de recursos:

cpu
memory
sigma/eni
ephemeral-storage
aliyun.com/gpu-mem (shared GPUs only)
nvidia.com/gpu

Para dimensionar com base em outros tipos de recursos, consulte Como configuro recursos personalizados para um node pool com Auto Scaling ativado?

Por que meu node pool falha ao provisionar novos nós?

Verifique as causas comuns abaixo:

O Auto Scaling não está ativado no node pool

O dimensionamento automático de nós funciona apenas em node pools com Auto Scaling configurado. Certifique-se de que o recurso de dimensionamento automático no nível do cluster esteja ativado e que o modo de dimensionamento do node pool esteja definido como Auto. Para detalhes, consulte Ativar o dimensionamento automático de nós.

As solicitações de recursos do pod excedem a capacidade alocável

As especificações anunciadas de uma instância ECS representam a capacidade total, não a capacidade alocável. O ACK reserva uma parte da CPU, memória e armazenamento para o kernel do SO, serviços do sistema e daemons do Kubernetes (kubelet, kube-proxy, Terway e o runtime de contêiner). O cluster-autoscaler padrão calcula as decisões de dimensionamento usando a política de reserva de recursos do Kubernetes 1.28 e versões anteriores.

Para utilizar uma política de reserva mais precisa, mude para o dimensionamento instantâneo de nós, que utiliza o algoritmo atualizado. Alternativamente, defina reservas de recursos personalizadas na configuração do node pool.

Para detalhes sobre o consumo de recursos:

• Recursos do sistema: Por que uma instância comprada tem um tamanho de memória diferente do tipo de instância?

• Os nós padrão instalam add-ons do sistema; mantenha as solicitações de recursos dos pods abaixo da capacidade anunciada do tipo de instância. Política de reserva de recursos

Uma restrição de zona do pod está impedindo o scale-out

Se um pod tiver uma dependência de agendamento em uma zona de disponibilidade específica — devido a uma PVC vinculada a um volume zonal ou a uma regra de afinidade de nó — o cluster-autoscaler pode não conseguir provisionar um nó nessa zona, especialmente em um node pool multizona.

Permissões necessárias estão ausentes

O cluster-autoscaler requer permissões no escopo do cluster concedidas por cluster. Conclua todas as etapas de autorização descritas em Ativar o dimensionamento automático de nós para o cluster.

O autoscaler está temporariamente pausado devido a nós não íntegros

Se os nós provisionados falharem ao ingressar no cluster ou permanecerem em NotReady por um período prolongado, o autoscaler pausa temporariamente novos dimensionamentos para evitar falhas repetidas. Resolva os problemas dos nós não íntegros — o dimensionamento será retomado automaticamente assim que a condição for normalizada.

O cluster não possui worker nodes

O cluster-autoscaler executa como um pod dentro do cluster. Sem worker nodes, o pod do autoscaler não consegue executar e não pode provisionar novos nós. Configure node pools com um mínimo de dois nós para garantir alta disponibilidade para os add-ons principais do cluster. Para dimensionar de zero ou até zero nós, utilize o dimensionamento instantâneo de nós.

Se um grupo de dimensionamento estiver configurado com múltiplos tipos de instância, como o autoscaler calcula a capacidade do grupo para decisões de dimensionamento?

Para um grupo de dimensionamento com múltiplos tipos de instância, o cluster-autoscaler modela a capacidade do grupo usando o valor mínimo para cada dimensão de recurso entre todos os tipos configurados.

Por exemplo, com dois tipos de instância:

• Tipo de instância A: 4 vCPU, 32 GiB de memória

• Tipo de instância B: 8 vCPU, 16 GiB de memória

O autoscaler calcula:

• CPU mínima: min(4, 8) = 4 vCPU

• Memória mínima: min(32, 16) = 16 GiB

Todo o grupo de dimensionamento é tratado como se pudesse provisionar apenas nós com 4 vCPU e 16 GiB. Um pod pendente solicitando mais de 4 vCPU ou mais de 16 GiB não acionará um scale-out para este grupo, mesmo que o tipo de instância B possa atender à solicitação de CPU.

Se vários node pools com Auto Scaling ativado estiverem disponíveis, como o cluster-autoscaler escolhe qual deles expandir?

Quando um pod não é agendável, o cluster-autoscaler simula quais node pools podem acomodá-lo. A simulação avalia rótulos, taints e tipos de instância disponíveis de cada node pool.

Se vários node pools se qualificarem, o autoscaler usa por padrão a estratégia de menor desperdício: ele seleciona o node pool que deixa a menor quantidade de recursos de CPU e memória não utilizados após o agendamento do pod.

Como configuro recursos personalizados para um node pool com Auto Scaling ativado?

Adicione tags ECS com o seguinte prefixo ao node pool para que o autoscaler possa reconhecer recursos personalizados disponíveis no pool ou valores precisos para recursos específicos:

k8s.io/cluster-autoscaler/node-template/resource/{resource_name}:{resource_size}

Exemplo:

k8s.io/cluster-autoscaler/node-template/resource/hugepages-1Gi:2Gi

Por que não consigo ativar o Auto Scaling para um node pool?

Não é possível ativar o Auto Scaling nos seguintes casos:

• É o node pool padrão. O recurso de dimensionamento automático de nós não suporta o node pool padrão do cluster.

• O node pool contém nós adicionados manualmente. Remova primeiro os nós adicionados manualmente ou crie um novo node pool dedicado com o Auto Scaling ativado desde o início.

• O node pool usa instâncias baseadas em assinatura. O dimensionamento automático de nós funciona apenas com instâncias de pagamento conforme o uso.

Por que o cluster-autoscaler não realiza o scale-in de um nó?

O cluster-autoscaler ignora um nó durante o scale-in se qualquer uma das condições a seguir se aplicar:

• A utilização dos pods excede o limiar. As solicitações totais de recursos dos pods no nó estão acima do limiar de scale-in configurado.

• O nó executa pods do namespace kube-system. Por padrão, o cluster-autoscaler não remove nós que executam pods do namespace kube-system.

• Um pod possui restrições rígidas de agendamento. Se um pod usa um nodeSelector ou nodeAffinity que impede seu reagendamento para qualquer outro nó, o nó não pode sofrer scale-in.

• Um pod é protegido por um PodDisruptionBudget (PDB). Se a evicção de um pod violar a configuração minAvailable ou maxUnavailable do PDB, o nó é mantido. Para detalhes, consulte PodDisruptionBudget.

• Durante o período de atraso de scale-down, se pods recém-agendados (como pods temporários criados por um Job) mantiverem a utilização de recursos acima do limiar, o nó não sofrerá scale-in. Pods não criados por um Deployment, ReplicaSet, Job ou StatefulSet bloqueiam a remoção do nó por padrão.

Para uma lista completa de condições que podem bloquear o scale-in de um nó, consulte o FAQ do cluster-autoscaler.

Como ativo ou desativo a evicção para um DaemonSet específico?

A configuração Evict DaemonSet Pods na configuração do cluster controla a evicção de DaemonSets globalmente. Para mais informações, consulte Etapa 1: Ativar o dimensionamento automático de nós para o cluster.

Substitua essa configuração por DaemonSet adicionando uma anotação aos pods do DaemonSet (no modelo de pod, não no objeto DaemonSet em si):

• Ativar evicção para pods de um DaemonSet específico:

  cluster-autoscaler.kubernetes.io/enable-ds-eviction: "true"

• Desativar evicção para pods de um DaemonSet específico:

  cluster-autoscaler.kubernetes.io/enable-ds-eviction: "false"

Se a configuração global Evict DaemonSet Pods estiver desativada, enable-ds-eviction: "true" aplica-se apenas a pods de DaemonSet em nós não vazios. Para evictar pods de DaemonSet de nós vazios, ative primeiro a configuração global.

Por padrão, o cluster-autoscaler evicta pods de DaemonSet de forma não bloqueante e prossegue sem esperar que a evicção seja concluída. Para fazer com que o autoscaler aguarde a evicção completa de um pod específico de DaemonSet antes de prosseguir, adicione a seguinte anotação junto com enable-ds-eviction:

cluster-autoscaler.kubernetes.io/wait-until-evicted: "true"

Essas anotações não têm efeito em pods que não fazem parte de um DaemonSet.

Quais tipos de pods podem impedir que o cluster-autoscaler remova um nó?

Para obter uma lista completa de condições que bloqueiam o scale-in de nós, consulte Quais tipos de pods podem impedir que o CA remova um nó? no FAQ upstream do cluster-autoscaler.

O cluster-autoscaler suporta CustomResourceDefinitions (CRDs)?

Não. O cluster-autoscaler suporta apenas objetos padrão do Kubernetes e não oferece suporte a CRDs.

Como atraso o scale-out para um pod específico?

Adicione a anotação cluster-autoscaler.kubernetes.io/pod-scale-up-delay ao pod. O cluster-autoscaler não considerará o pod para scale-out até que ele permaneça não agendável por um tempo superior ao atraso especificado. Isso concede ao agendador do Kubernetes tempo extra para posicionar o pod em nós existentes antes de acionar um scale-up.

Exemplo:

cluster-autoscaler.kubernetes.io/pod-scale-up-delay: "600s"

Como uso anotações de pod para controlar o comportamento de scale-in?

Utilize a anotação cluster-autoscaler.kubernetes.io/safe-to-evict para marcar explicitamente um pod como seguro ou inseguro para evicção durante o scale-in:

• Impedir o scale-in do nó: Adicione "cluster-autoscaler.kubernetes.io/safe-to-evict": "false" a um pod em execução no nó. O autoscaler não encerrará o nó enquanto este pod estiver presente.

• Permitir o scale-in do nó: Adicione "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" para marcar explicitamente o pod como seguro para evicção.

Como impeço o cluster-autoscaler de realizar o scale-in de um nó específico?

Adicione a anotação cluster-autoscaler.kubernetes.io/scale-down-disabled: "true" ao nó. Substitua <nodename> pelo nome do nó alvo:

kubectl annotate node <nodename> cluster-autoscaler.kubernetes.io/scale-down-disabled=true

Como atualizo o cluster-autoscaler para a versão mais recente?

1. Faça login no console do ACK. No painel de navegação à esquerda, clique em Clusters.

2. Na página Clusters, localize o cluster e clique em seu nome. No painel de navegação à esquerda, escolha Nodes > Node Pools.

3. Clique em Edit à direita de Node Scaling. No painel exibido, clique em OK para atualizar para a versão mais recente.

Quais ações acionam uma atualização automática do cluster-autoscaler?

O cluster-autoscaler é atualizado automaticamente quando:

• A configuração de dimensionamento automático é modificada.

• Um node pool com Auto Scaling ativado é criado, excluído ou atualizado.

• A versão do Kubernetes do cluster é atualizada com sucesso.

O dimensionamento de nós não está funcionando no meu cluster gerenciado ACK, embora a autorização de função esteja completa

Isso geralmente significa que o token addon.aliyuncsmanagedautoscalerrole.token está ausente em um Secret no namespace kube-system. O ACK usa a Worker Role do cluster para ativar o dimensionamento automático, e esse token é necessário para autenticação.

Reaplique a política necessária à Worker Role usando o console do ACK:

1. Na página Clusters, localize o cluster e clique em seu nome. No painel de navegação à esquerda, escolha Nodes > Node Pools.

2. Na página Node Pools, clique em Enable à direita de Node Scaling.

3. Siga as instruções na tela para autorizar a KubernetesWorkerRole e anexar a política de sistema AliyunCSManagedAutoScalerRolePolicy.

   

4. Reinicie manualmente o Deployment cluster-autoscaler (dimensionamento automático de nós) ou o Deployment ack-goatscaler (dimensionamento instantâneo de nós) no namespace kube-system para que as permissões tenham efeito imediato.