Container Service for Kubernetes:Perguntas frequentes sobre dimensionamento automático de nós

Os recursos disponíveis no 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 do 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 mais detalhes, consulte Why is the memory size different from the instance type specification after I purchase an instance?.

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 alto consumo de recursos antes da implantação em 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 mais 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 detalhes, consulte Customize elastic resource priority scheduling.

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 específico de instância 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 mais 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 o 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 específico de disco (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 novos nós 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 alocado 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 mais detalhes, consulte Enable node auto scaling.

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 parcela de CPU, memória e armazenamento para o kernel do SO, services do sistema e daemons do Kubernetes (kubelet, kube-proxy, Terway e container runtime), o que gera uma diferença entre a capacidade total do nó e seus recursos alocáveis.

Ao tomar decisões de scale-out, o cluster-autoscaler usa a resource reservation policy do Kubernetes 1.28 e versões anteriores, independentemente da versão do cluster ACK.

Para utilizar uma política de reserva mais precisa, mude para a node instant scaling, que emprega um algoritmo atualizado. Alternativamente, defina reservas de recursos personalizados na configuração do node pool.

Para detalhes sobre o consumo de recursos:

• Recursos do sistema: Why does a purchased instance have a memory size different from the instance type?

• Nós padrão instalam add-ons de sistema; mantenha as solicitações de recursos dos pods abaixo da capacidade anunciada do tipo de instância. Resource reservation policy

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 individualmente por cluster. Conclua todas as etapas de autorização descritas em Enable node auto scaling for the cluster.

Comportamento de amortecimento para nós não saudáveis

O autoscaler entra em estado de amortecimento quando ocorre uma das seguintes condições em um node pool com dimensionamento automático:

• Um nó falha ao ingressar no cluster dentro do tempo esperado.

• Um nó permanece com status NotReady além da duração permitida.

Enquanto estiver nesse estado de amortecimento, todas as operações de dimensionamento são suspensas até que os nós não saudáveis sejam resolvidos, garantindo a precisão das decisões subsequentes de dimensionamento.

Nenhum nó no cluster

O cluster-autoscaler não consegue operar quando o cluster não possui nós. Configure cada node pool com no mínimo dois nós para assegurar o funcionamento normal dos add-ons e componentes do cluster.

Para dimensionamento partindo de zero ou reduzindo a zero nós, utilize a node instant scaling.

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 de 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 que solicite mais de 4 vCPU ou mais de 16 GiB não acionará o scale-out para este grupo, mesmo que o tipo de instância B pudesse atender à solicitação de CPU.

Se houver vários node pools com Auto Scaling ativado, 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 forem elegíveis, o autoscaler adota 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 sem uso 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 reconheça 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 já 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 faz o scale-in de um nó?

O cluster-autoscaler ignora um nó durante o scale-in se alguma das condições abaixo 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. Caso um pod utilize um nodeSelector ou nodeAffinity que impeça seu reagendamento para qualquer outro nó, o scale-in do nó não será possível.

• Um pod está protegido por um PodDisruptionBudget (PDB). Se a evicção de um pod violar a configuração minAvailable do PDB, o nó será mantido. Para mais 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 obter a 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 Step 1: Enable node auto scaling for the cluster.

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

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

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

• Desativar evicção para os 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 aos 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 aguardar a conclusão da evicção. Para fazer com que o autoscaler aguarde a evicção completa de um pod específico de DaemonSet antes de prosseguir, adicione a seguinte annotation juntamente com enable-ds-eviction:

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

Essas annotations 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ó?

O cluster-autoscaler pode bloquear a remoção de um nó nos seguintes casos:

• O pod não foi criado por um controlador nativo do Kubernetes (por exemplo, não foi criado por um Deployment, ReplicaSet, Job ou StatefulSet).

• O pod no nó não pode ser encerrado ou migrado com segurança.

Para obter a lista completa de condições que bloqueiam o scale-in de nós, consulte What types of pods can prevent CA from removing a node?

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 annotation 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 período superior ao atraso especificado. Isso concede ao agendador do Kubernetes tempo extra para alocar o pod em nós existentes antes de acionar o scale-out.

Exemplo:

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

Como uso annotations de pod para controlar o comportamento de scale-in?

Utilize a annotation 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 esse 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 fazer o scale-in de um nó específico?

Adicione a annotation 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, clique no nome do seu cluster. No painel de navegação à esquerda, clique em 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, mesmo com a autorização de função concluída

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

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

1. Na página Clusters do ACK, clique no nome do seu cluster. No painel de navegação à esquerda, clique em 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.

   Na caixa de diálogo Node Scaling Configuration, após a aprovação da verificação prévia, clique no link do nome da função na área de prompt para acessar o Resource Access Management (RAM) e concluir a autorização.

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 entrem em vigor imediatamente.