Visão geral do dimensionamento de nós em clusters ACK - Container Service for Kubernetes: Central de Documentação do Alibaba Cloud

Se o cluster ACK não conseguir agendar pods pendentes, use o dimensionamento de nós para adicionar ou remover nós automaticamente. O ACK oferece node auto scaling e node instant scaling. Comparado ao node auto scaling, o node instant scaling é mais rápido e simples.

Antes de começar

Leia este tópico para entender as soluções de dimensionamento de nós do ACK e escolha a mais adequada à sua carga de trabalho antes de ativar o dimensionamento de nós.

Familiarize-se com os conceitos de dimensionamento manual, auto scaling, dimensionamento horizontal e vertical na documentação oficial do Kubernetes.

Como funciona o dimensionamento de nós

O dimensionamento de nós no Kubernetes difere do modelo tradicional baseado em limiares de utilização de recursos. Considere essa diferença ao migrar de data centers ou outros sistemas de orquestração para o Kubernetes.

O modelo tradicional adiciona nós quando a utilização de CPU ou memória ultrapassa um limiar definido. No entanto, esse modelo apresenta os seguintes problemas:

Como os limiares de dimensionamento são definidos?

Nós sobrecarregados geralmente apresentam utilização de recursos superior à dos demais nós.

Se o acionamento ocorrer pela utilização média, a demanda dos nós sobrecarregados fica mascarada pelos nós subutilizados, impedindo uma expansão oportuna.
Se o acionamento ocorrer pelo pico de utilização, geralmente haverá desperdício de recursos em todo o cluster.

Como a carga é reduzida após a adição de nós?

No Kubernetes, os pods são as menores unidades implantáveis. Adicionar nós não redistribui a carga dos pods existentes: a quantidade de pods e os limites de recursos permanecem inalterados. Portanto, os novos nós não recebem tráfego dos pods sobrecarregados.

Como o dimensionamento de nós é acionado e executado?

O dimensionamento baseado em utilização pode remover pods com altas solicitações de recursos, mas baixo uso real. Se houver muitos pods nessa situação, os recursos agendáveis se esgotam e alguns pods tornam-se não agendáveis.

Para resolver essas questões, o ACK utiliza o dimensionamento de nós (camada de recursos) e o dimensionamento de carga de trabalho (camada de agendamento). O dimensionamento de nós aciona o ajuste de escala com base na utilização de recursos dos pods.

Como as atividades de expansão são acionadas?

O modelo de dimensionamento de nós monitora pods não agendáveis. Quando os pods falham no agendamento devido à insuficiência de recursos, o sistema simula o agendamento, seleciona um node pool adequado com auto scaling ativado e adiciona nós ao cluster.

Nota

A simulação abstrai cada node pool com auto scaling ativado como um nó virtual, com capacidade de CPU, memória e GPU correspondente aos tipos de instância configurados, além dos rótulos e taints do node pool. O agendador inclui esse nó virtual na lista de nós agendáveis, calcula a quantidade necessária de nós e provisiona os nós conforme o resultado.

Como as atividades de redução são acionadas?

A redução aplica-se apenas a nós em node pools com auto scaling ativado; nós estáticos não são gerenciados. Quando a utilização de um nó cai abaixo do limiar de redução, o modelo simula a remoção de pods para verificar se o nó pode ser drenado. Pods que não sejam DaemonSet no namespace kube-system e pods protegidos por PodDisruptionBudget são ignorados. Após a migração de todos os pods elegíveis para outros nós, o sistema remove o nó.

Como ocorre a seleção quando existem vários node pools com auto scaling ativado?

Vários node pools com auto scaling ativado são tratados como nós abstratos. O autoscaler os pontua usando a política de agendamento padrão e prioriza regras de afinidade, como node affinity.

Se nenhuma correspondência for encontrada pelas regras de afinidade, o node auto scaling recorre ao princípio de menor desperdício e seleciona o node pool que deixa menos recursos ociosos após a expansão.

Nota

Quando tanto node pools acelerados por GPU quanto por CPU com auto scaling ativado atendem às condições de expansão, o pool acelerado por CPU tem prioridade.

Por padrão, o node instant scaling avalia a disponibilidade e o custo das instâncias, priorizando tipos com capacidade suficiente e menor preço.

Como melhorar a taxa de sucesso do auto scaling?

A taxa de sucesso do auto scaling depende dos seguintes fatores:

Cumprimento das condições de agendamento

Após criar um node pool com auto scaling ativado, confirme a política de agendamento de pods para esse node pool. Em caso de dúvida, configure o nodeSelector com o rótulo do node pool e execute uma simulação de agendamento.
Suficiência de recursos

Após a simulação, o sistema seleciona um node pool com auto scaling ativado e adiciona nós. Contudo, o estoque de tipos de instância ECS na configuração do node pool afeta a taxa de sucesso da expansão. Especifique múltiplos tipos de instância em diferentes zonas para aumentar a taxa de sucesso.

Como acelerar o auto scaling?

Método 1: Use o modo rápido. Após um node pool com auto scaling ativado concluir um ciclo de expansão e redução, ele entra no modo rápido. Consulte Enable node autoscaling.
Método 2: Use uma imagem personalizada baseada no Alibaba Cloud Linux 3 para melhorar a eficiência de entrega de recursos IaaS em 50%. Consulte Optimize scaling with custom images.

Soluções de dimensionamento: node auto scaling e node instant scaling

O dimensionamento de nós é um recurso de infraestrutura que ajusta automaticamente a quantidade de nós no cluster. Quando a capacidade existente é insuficiente para o agendamento de pods, o autoscaler provisiona nós adicionais.

O ACK oferece duas soluções para dimensionamento de nós.

Introdução

Importante

Apenas um componente de dimensionamento pode ser executado em um cluster. As duas soluções não podem coexistir. Para ativar o dimensionamento de nós, consulte Enable node autoscaling e Enable node instant scaling.
As estatísticas de dimensionamento neste tópico são valores teóricos baseados em imagens personalizadas. Os resultados reais no seu ambiente podem variar. Consulte Optimize scaling with custom images.
Ambas as soluções de dimensionamento aplicam-se a nós dentro de node pools com auto scaling ativado.

Solução	Componente	Descrição
Solução 1: node auto scaling	cluster-autoscaler	Verifica o status do cluster em um ciclo rotativo e dimensiona os nós quando as condições são atendidas.
Solução 2: node instant scaling	ACK GOATScaler	Autoscaler de nós orientado a eventos que garante entrega eficiente de recursos em grandes clusters e cenários de expansão consecutiva. Um cluster é considerado grande se um node pool com auto scaling ativado contiver mais de 100 nós ou se mais de 20 node pools no cluster tiverem o auto scaling ativado. Velocidade de dimensionamento: 45 segundos; taxa de sucesso: 99%; redução de fragmentação de recursos: 30%. Suporta políticas de dimensionamento personalizadas para extensibilidade.

Comparação das soluções

Para node pools com auto scaling ativado (sem o modo rápido), o recurso de node instant scaling é compatível com a configuração existente do node pool e suporta todos os tipos de pods. A tabela a seguir compara o node instant scaling com o node auto scaling.

Benefício	Node auto scaling	Node instant scaling
Velocidade e eficiência de dimensionamento	60 segundos no modo padrão; 50 segundos no modo rápido.	Com dimensionamento orientado a eventos e Alibaba Cloud ContainerOS, cada atividade leva de 35 a 55 segundos.
	O auto scaling atinge um gargalo de desempenho em 1 minuto. A eficiência flutua conforme a quantidade de node pools e os cenários de dimensionamento. Exceder 100 node pools aumenta a duração para 100–150 segundos.	A duração do dimensionamento permanece estável à medida que a quantidade de node pools ou pods aumenta, tornando-o adequado para cenários de dimensionamento rápido.
	Modo rotativo com atualizações de status do cluster. Latência mínima: 5 segundos.	Orientado a eventos. Latência: 1–3 segundos.
Taxa de sucesso do dimensionamento de recursos	Devido à flutuação no estoque de recursos em nuvem e à variabilidade dos tipos de instância, a taxa de sucesso do node auto scaling é de aproximadamente 97%.	Uma política de seleção automática de estoque filtra milhares de tipos de instância da Alibaba Cloud por condições e prioridades predefinidas. Ela seleciona automaticamente tipos ideais ou alternativas de fallback quando os tipos especificados estão indisponíveis. Isso simplifica a O&M e aumenta a taxa de sucesso para 99%.
	A expansão utiliza tipos de instância da configuração do node pool. Quando múltiplos tipos são especificados, o tipo de menor especificação tem preferência.	É possível especificar múltiplos tipos de instância para atividades de expansão.
	O autoscaler tenta novamente periodicamente quando o dimensionamento de recursos falha.	O autoscaler pode gerar alertas quando os tipos de instância especificados são insuficientes.
Uso e O&M	Comparado ao node auto scaling, o node instant scaling facilita o uso nos seguintes aspectos: Manutenção da configuração do node pool: O node instant scaling seleciona automaticamente instâncias entre tipos e zonas para hospedar pods pendentes. Com o node auto scaling, você precisa manter manualmente as configurações do node pool e atualizá-las sempre que as configurações dos pods mudarem. O&M de nós: Exceções de dimensionamento aparecem em eventos de pod, permitindo que os desenvolvedores foquem no gerenciamento do ciclo de vida dos pods. Extensão de recursos: Ambas as soluções funcionam com o Descheduler para preparar recursos elásticos. O node instant scaling é não intrusivo e suporta ações personalizadas em políticas de provisionamento de recursos e gerenciamento de ciclo de vida de nós para desenvolvimento secundário.
Política de agendamento	Além dos recursos de agendamento do node auto scaling, o node instant scaling também suporta: Topologia: Atende aos requisitos de alta disponibilidade entre zonas. Pod Disruption Budgets: Limita remoções voluntárias simultâneas de pods em aplicações com múltiplos pods, garantindo estabilidade durante interrupções planejadas.
Política de agendamento	O node instant scaling reduz a taxa de fragmentação de recursos em 30% usando políticas de Bin Packing e PreBind (recurso personalizado).

Limitações do node instant scaling

As seguintes limitações aplicam-se ao node instant scaling. Revise-as antes de ativar o node instant scaling.

O node instant scaling não suporta o modo rápido.
Um node pool pode conter até 180 nós por lote de expansão.
Não é possível desativar a redução para um cluster específico.

Nota
Para desativar a redução para um nó específico, consulte How to prevent a node from being scaled in by node instant scaling?
A solução de node instant scaling não verifica o estoque de instâncias preemptíveis. Se o Billing Method do node pool estiver definido como instâncias preemptíveis e a opção Use Pay-as-you-go Instances When Spot Instances Are Insufficient estiver ativada, instâncias pay-as-you-go poderão ser expandidas mesmo que haja instâncias preemptíveis suficientes disponíveis.

Selecione uma solução de dimensionamento de nós

Consulte Solution comparison e Limits of node instant scaling. Escolha o node auto scaling se sua carga de trabalho tiver demandas menores quanto à velocidade de dimensionamento e certeza de entrega, e as limitações do node instant scaling forem inaceitáveis.

Se sua carga de trabalho apresentar qualquer um dos requisitos a seguir, recomenda-se o node instant scaling:

Clusters grandes degradam severamente a eficiência do node auto scaling. Opte pelo node instant scaling, pois o tamanho do cluster tem impacto mínimo em sua eficiência de dimensionamento. Um cluster é considerado grande se um node pool com auto scaling ativado contiver mais de 100 nós ou se mais de 20 node pools no cluster tiverem o auto scaling ativado.
Necessidade de maior velocidade de dimensionamento. Modo padrão: o node auto scaling leva 60 segundos; o node instant scaling leva 45 segundos.
Lotes consecutivos de expansão frequentes. Em cenários de dimensionamento consecutivo, o desempenho do node auto scaling degrada e flutua, enquanto o node instant scaling mantém um tempo de dimensionamento consistente de aproximadamente 45 segundos.

Notas de uso

Cotas e limites

Uma tabela de rotas VPC suporta até 200 entradas de rota personalizadas. Para aumentar esse limite, envie uma solicitação no console do Quota Center. Para outras cotas de recursos, consulte Underlying Cloud Product Quotas.
Configure cuidadosamente o número máximo de nós em um node pool com auto scaling ativado. Garanta que os recursos dependentes e as cotas sejam suficientes, como blocos CIDR da VPC e vSwitches. Caso contrário, as atividades de expansão podem falhar. Para limites de node pools, consulte Enable node autoscaling. Para planejamento de rede, consulte ACK managed cluster network planning.
O dimensionamento de nós não suporta nós por assinatura. Não defina o método de faturamento como assinatura ao criar um node pool com auto scaling ativado. Para node pools existentes, garanta que não haja nós por assinatura antes de ativar o auto scaling.
O recurso de dimensionamento de nós é incompatível com SideCar Containers. Implante cargas de trabalho de Sidecar Container em node pools com auto scaling desativado.

Manutenção de recursos dependentes

Se endereços IP elásticos (EIPs) estiverem associados a nós ECS adicionados pelo dimensionamento de nós, não exclua esses nós diretamente do console ECS. Os EIPs não serão liberados automaticamente.

Referências

Consulte Enable node autoscaling e Enable node instant scaling.

Consulte Node auto scaling FAQ.

Expandir para ver índice de perguntas frequentes sobre node auto scaling

Categoria	Subcategoria	Links
Comportamento do node auto scaling	Known limitations
	Scale-out behavior	Scheduling policies Resource types Scale-out failures Multiple instance types Node pool selection Custom resources Enabling Auto Scaling
	Scale-in behavior	Scale-in failures DaemonSet eviction Pods that prevent node removal
	Extension support	CustomResourceDefinitions (CRDs)
Comportamento de dimensionamento personalizado	Pod-level control	Delay scale-out
Comportamento de dimensionamento personalizado	Node-level control	Prevent scale-in
Gerenciamento de add-ons		Upgrade cluster-autoscaler Automatic updates Role authorization

Expandir para ver índice de perguntas frequentes sobre node instant scaling

Categoria	Subcategoria	Link
Node instant scaling behavior	Known limitations
	Scale-out behavior	What resource types does node instant scaling use for scaling simulations? Does node instant scaling select an appropriate instance type from a node pool based on pod resource requests? How does node instant scaling select an instance type from a node pool with multiple types? How do I monitor the inventory of instance types in a node pool when using node instant scaling? How can I optimize the node pool configuration to avoid scale-out failures from insufficient inventory? Why does node instant scaling fail to scale out nodes? How do I configure custom resources for a node pool with node instant scaling enabled?
	Scale-in behavior	Why does node instant scaling fail to scale in nodes? What types of pods can prevent node instant scaling from removing a node?
Comportamento de dimensionamento personalizado	Controlling scaling with pods	How can I control node scale-in by using pods?
Comportamento de dimensionamento personalizado	Controlling scaling with nodes	How do I specify which node to delete during a scale-in? How do I prevent a specific node from being scaled in? Can node instant scaling be configured to scale in only empty nodes?
Node instant scaling add-on		Does the node instant scaling add-on update automatically? Why does node scaling fail on my ACK managed cluster after I granted the required permissions?