Solução de dimensionamento para workloads e recursos de computação em clusters ACK - Container Service for Kubernetes: Central de Documentação do Alibaba Cloud

Observações de uso

Antes de configurar o dimensionamento de workloads e o dimensionamento de nós, familiarize-se com as soluções da comunidade, como Horizontal Pod Autoscaler (HPA), Vertical Pod Autoscaler (VPA) e Cluster Autoscaling.
Se o seu cluster tiver mais de 500 nós ou 10.000 pods, consulte Plan scaling rates para garantir a estabilidade do cluster e do plano de controle.

Dimensionamento de workloads e dimensionamento de recursos de computação

O Auto Scaling do ACK opera em duas camadas:

Dimensionamento de workloads: ajusta a quantidade de pods ou a alocação de recursos por pod na camada de agendamento. Por exemplo, o HPA dimensiona os pods da aplicação conforme as variações de tráfego.
Dimensionamento de recursos de computação: ajusta os recursos do cluster por meio do dimensionamento de nós e do dimensionamento de nós virtuais, com base no agendamento de pods e no uso de recursos.

Combine ambas as camadas para melhorar a utilização de recursos e atender às demandas de agendamento de pods.

Soluções de dimensionamento de workloads

Para dimensionamento temporário, execute kubectl scale e ajuste manualmente a quantidade de pods. Para dimensionamento automatizado, selecione uma das seguintes soluções de dimensionamento de workloads.

Solução	Descrição	Métrica de dimensionamento	Cenário	Referências
HPA	O HPA aumenta os pods durante picos e reduz nos períodos de baixa demanda para otimizar custos. Adequado para a maioria dos cenários.	Métricas de recursos, como utilização de CPU e memória Métricas personalizadas	Ideal para serviços online com flutuações frequentes de tráfego, como e-commerce, educação online e serviços financeiros.	Use Horizontal Pod Autoscaler (HPA)
CronHPA	O CronHPA dimensiona pods conforme um cronograma predefinido semelhante ao Crontab, com suporte a fuso horário e data. É possível excluir datas específicas, como feriados. Compatível com HPA.	Dimensionamento agendado	Recomendado para aplicações com padrões de tráfego previsíveis ou tarefas agendadas.	Use CronHPA Make CronHPA compatible with HPA
VPA	O VPA monitora o consumo de recursos dos pods, recomenda a alocação de CPU e memória e ajusta essa alocação sem alterar a quantidade de réplicas.	O VPA recomenda e, opcionalmente, ajusta automaticamente as solicitações e limites de CPU e memória para pods.	Mais indicado para alocação estável de recursos, como aplicações com estado e grandes implantações monolíticas. O VPA geralmente entra em vigor quando os pods se recuperam de anomalias.	Vertical Pod Autoscaler (VPA)
Kubernetes-based Event Driven Autoscaling (KEDA)	O KEDA permite o Auto Scaling orientado a eventos para workloads provenientes de diversas fontes.	Quantidade de eventos, como o tamanho da fila.	Projetado para trabalhos offline baseados em eventos que exigem dimensionamento instantâneo, como transcodificação de vídeo e áudio, tarefas orientadas a eventos e processamento de streams.	Event-driven autoscaling
Advanced Horizontal Pod Autoscaler (AHPA)	O AHPA aprende padrões de flutuação de workloads a partir de métricas históricas para prever a demanda de recursos e habilitar o dimensionamento preditivo.	Métricas de recursos, como utilização de CPU, memória e GPU Métricas de tráfego, como consultas por segundo (QPS) e tempo de resposta (RT) Outras métricas personalizadas	Ideal para padrões de tráfego periódicos, como streaming ao vivo, educação online e jogos.	Auto Scaling Prediction (AHPA)

O controlador UnitedDeployment gerencia workloads do mesmo tipo em vários subconjuntos, com ajuste de réplicas por subconjunto. Combine-o com as soluções de dimensionamento acima para obter flexibilidade entre diferentes tipos de recursos de computação. Consulte Implement workload scaling based on the UnitedDeployment controller.

Dimensionamento de recursos de computação

Os componentes de dimensionamento de recursos de computação detectam pods pendentes e provisionam nós ECS ou instâncias de contêiner elásticas para atender às demandas de agendamento.

Para comparações sobre o dimensionamento de nós, consulte Node scaling.

Importante

As estatísticas de entrega de recursos na tabela a seguir são teóricas. Os valores reais podem variar conforme o ambiente.

Solução	Descrição	Cenário	Eficiência na entrega de recursos	Referências
Node auto scaling	O ACK dimensiona nós automaticamente quando os recursos do cluster não conseguem atender ao agendamento de pods.	Adequado para todos os cenários, especialmente serviços online, tarefas de deep learning e dimensionamento em pequena escala. Recomendado para clusters com menos de 20 node pools de Auto Scaling ou node pools com menos de 100 nós.	Tempo necessário para adicionar 100 nós a um cluster: Modo padrão: 120 segundos. Modo rápido: 60 segundos. Modo padrão com images that support quick boot (Qboot): 90 segundos. Modo rápido com images that support quick boot (Qboot): 45 segundos.	Ative node autoscaling
Node instant scaling	O Node instant scaling oferece dimensionamento mais rápido, maiores taxas de sucesso na entrega e monitoramento do estoque de instâncias ECS em comparação ao node auto scaling. Consulte Solution comparison.	Indicado para todos os cenários, especialmente clusters de grande escala que exigem dimensionamento mais rápido, uso de múltiplos tipos de instância e zonas, ou agendamento avançado, como restrições de distribuição de topologia. Um cluster é considerado grande se qualquer node pool de Auto Scaling tiver mais de 100 nós ou se o cluster possuir mais de 20 node pools de Auto Scaling.	Tempo necessário para adicionar 100 nós a um cluster: ContainerOS in swift mode: 45 segundos. Modo padrão: 103 segundos. Ainda não suportado	Ative node instant scaling Visualize the health status of node instant scaling
Nós virtuais	Os nós virtuais eliminam o gerenciamento de nós e o planejamento de capacidade. Um cluster suporta até 50.000 pods em nós virtuais, permitindo a criação de até 10.000 pods em 1 minuto durante o scale-out.	Aplicável a todos os cenários, especialmente tarefas pontuais, tarefas agendadas, computação de dados, aplicações de IA e picos de workload.	Tempo necessário para criar 1.000 pods em um cluster: Com cache de imagem desativado: 30 segundos. Com image caching ativado: 15 segundos.	Schedule pods to run on ECI

Faturamento

O Auto Scaling em si é gratuito. Como o componente de dimensionamento executa como pods, seu cluster deve ter pelo menos um nó. Você será cobrado pelos nós adicionados por meio do Auto Scaling. Consulte Billing overview.

Perguntas frequentes

Consulte Auto scaling FAQs.

Clique em para visualizar o índice de perguntas frequentes sobre o 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

Clique em para visualizar o índice de perguntas frequentes sobre o node instant scaling

Categoria	Subcategoria	Link
Node instant scaling comportamento	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?

Clique em para visualizar o índice de perguntas frequentes sobre o dimensionamento de workloads** (incluindo HPA e CronHPA)

Referências

Para pré-instalação ou dimensionamento de alta performance, consulte Custom images for scaling optimization.
Para coletar logs de Auto Scaling, consulte Collect log files of system components.
Siga as orientações em Recommended workload configurations ao configurar seus workloads.
Para contêineres serverless, o Knative dimensiona pods com base na quantidade de requisições e na concorrência, incluindo redução a zero (scale-to-zero). Consulte Enable auto scaling to withstand traffic fluctuations.