AKS (Serviço de Kubernetes do Azure) visão geral de dimensionamento — HPA, VPA, Dimensionador Automático de Cluster e KEDA

Ao executar aplicativos no AKS (Serviço de Kubernetes do Azure), você pode dimensionar pods, recursos de pod, nós ou cargas de trabalho orientadas por eventos para corresponder às alterações na demanda. O AKS dá suporte ao dimensionamento manual, HPA (Dimensionador Automático de Pod Horizontal), VPA (Dimensionador Automático de Pod Vertical), Dimensionador Automático de Cluster, KEDA (Dimensionamento Automático Orientado a Eventos do Kubernetes), provisionamento automático de nós e dimensionamento de intermitência com a ACI (Instância de Contêiner do Azure).

Escolher o método de dimensionamento correto

Método de redimensionamento	Mais adequado para	Métrica-chave	Guide
Escalonador automático horizontal de pods (HPA)	Cargas de trabalho sem estado ou particionáveis com demanda variável	Utilização da CPU, RPS, profundidade da fila	Quando devo usar o HPA (Dimensionamento Automático de Pod Horizontal) no Kubernetes?
VPA (Dimensionador Automático de Pod Vertical)	Cargas de trabalho não paralelizáveis; dimensionamento adequado das solicitações de recursos de pods	Uso de recursos de CPU/memória	Usar o Dimensionador Automático de Pod Vertical no AKS
Escalador automático de cluster	Capacidade em nível de nó quando os pods permanecem pendentes	Pods pendentes	Usar o Cluster Autoscaler no AKS
Provisionamento automático de nós (NAP)	Cargas de trabalho pendentes que precisam de capacidade de VM de tamanho certo	Requisitos de recursos de pod pendentes	Visão geral do provisionamento automático de nós
KEDA	Cargas de trabalho orientadas por eventos; escalonamento até zero necessário	Tamanho da fila, acúmulo de eventos	Visão geral do complemento KEDA
Dimensionamento de intermitência do ACI	Cargas de trabalho do Linux com demanda em picos que se enquadram nas limitações do nó virtual	Pico de demanda	Criar nós virtuais com Instâncias de Contêiner do Azure

Quando usar cada método de dimensionamento

Use o HPA quando sua carga de trabalho puder executar várias réplicas idênticas e a demanda flutuar com base na CPU, na memória ou na taxa de solicitação.
Use VPA quando sua carga de trabalho não puder escalar horizontalmente (não paralelizável) ou quando você precisar ajustar corretamente as solicitações de recursos para melhorar o agendamento.
Use o Dimensionador Automático de Cluster quando tiver pools de nós predefinidos e precisar adicionar ou remover nós com base na demanda pendente do pod.
Use o NAP quando quiser a seleção automática de SKU da VM e o provisionamento de nós sem configurar manualmente os pools de nós.
Use o KEDA quando o escalonamento precisar responder a eventos externos (filas, streams, mensagens) ou quando você precisar da capacidade de escalar até zero.
Use o dimensionamento de intermitência da ACI quando precisar de expansão rápida de capacidade para cargas de trabalho do Linux sem esperar pelo provisionamento de VM (normalmente de 2 a 5 minutos).

Recomendação rápida

Para a maioria das cargas de trabalho de produção, comece com o AKS Automatic, que pré-configura NAP, VPA e KEDA. No AKS Standard, você habilita e configura esses recursos explicitamente.

Dimensionar manualmente os pods ou os nós

Você pode dimensionar manualmente réplicas de pod e nós para testar como seu aplicativo responde a alterações nos recursos disponíveis ou para manter uma capacidade fixa. Para dimensionar manualmente, defina a réplica ou a contagem de nós necessária. Em seguida, o Kubernetes cria ou remove pods, enquanto o AKS adiciona ou remove nós do pool de nós aplicável.

Quando você reduz o número de nós, o AKS chama a API do Azure Compute correspondente ao tipo de computação do cluster. Para clusters criados em Conjuntos de Dimensionamento de Máquinas Virtuais, a API Conjuntos de Dimensionamento de Máquinas Virtuais determina quais nós serão removidos. Para obter mais informações, consulte as perguntas frequentes sobre Conjuntos de Dimensionamento de Máquinas Virtuais.

Para começar, consulte:

Dimensionador automático de pod horizontal

Use o HPA quando sua carga de trabalho puder executar várias réplicas idênticas e a demanda for variável. Ele escala com base em CPU ou memória, métricas da aplicação (requisições por segundo, latência) ou métricas externas de fila e acúmulo. Quando as réplicas puderem exceder a capacidade existente dos nós, use a funcionalidade NAP pré-configurada no AKS Automático ou configure o Dimensionador Automático de Cluster ou o NAP no AKS Padrão.

Não use HPA e VPA nas mesmas métricas de CPU ou memória. Para usar os dois dimensionadores automáticos, use o VPA no modo de recomendação ou configure o HPA para usar métricas personalizadas distintas.

Saiba mais: Quando devo usar o HPA (Dimensionamento Automático de Pod Horizontal) no Kubernetes?

Veja também: Usar o Dimensionador Automático de Pod Vertical no AKS para dimensionar corretamente as solicitações de CPU e memória do pod.

Autoescalador de Pod Vertical

O Dimensionador Automático de Pod Vertical analisa o uso da CPU e da memória do pod e recomenda ou aplica solicitações de recurso apropriadas. Use o VPA para dimensionar corretamente cargas de trabalho que não podem ser escaladas com eficiência por meio da adição de réplicas ou para melhorar o agendamento e a utilização de recursos.

Dependendo do modo de atualização, o VPA pode aplicar recomendações na criação dos pods ou remover e recriar pods com solicitações de recursos atualizadas. Examine os requisitos de disponibilidade da carga de trabalho antes de permitir que a VPA aplique alterações automaticamente.

Para começar, consulte Use Vertical Pod Autoscaler in AKS.

Dimensionador automático de cluster

O Dimensionador Automático de Cluster ajusta o número de nós em um pool de nós de acordo com os requisitos de agendamento de pods. Ele adiciona nós quando os pods não podem ser agendados devido à capacidade insuficiente nos nós e remove nós subutilizados quando suas cargas de trabalho podem ser executadas em outros lugares.

Cluster Autoscaler geralmente é usado com HPA. O HPA ajusta o número de réplicas de pod com base na demanda da carga de trabalho, enquanto o Dimensionador Automático de Cluster ajusta a capacidade dos nós para acomodar esses pods.

Para começar, consulte Usar o Escalonador Automático de Cluster no AKS.

Eventos de expansão

Se um pool de nós não tiver recursos de computação suficientes para um pod, o pod permanece Pendente. Quando o Dimensionador Automático de Cluster detecta pods que não podem ser agendados devido a limitações de recursos no pool de nós, ele aumenta o número de nós nesse pool. O Kubernetes agenda os pods pendentes depois que os novos nós são provisionados e estão prontos.

O provisionamento de nós baseados em VM pode levar vários minutos. Para cargas de trabalho com picos repentinos de demanda, considere usar nós virtuais e Instâncias de Contêiner do Azure.

Eventos de redução

O Dimensionador Automático monitora os nós em busca de subutilização e determina se os pods desses nós podem ser executados em outros nós. Quando um nó não é mais necessário, o Kubernetes reagenda seus pods e o AKS remove o nó do pool de nós.

As operações de redução podem interromper as cargas de trabalho à medida que os pods se movem entre os nós. Execute várias réplicas de pod e configure controles de disponibilidade adequados para minimizar interrupções.

Dimensionamento automático controlado por eventos do Kubernetes

O KEDA (Dimensionamento Automático controlado por eventos) do Kubernetes é um componente de software livre que dimensiona cargas de trabalho com base em eventos. O KEDA estende o Kubernetes com recursos personalizados, incluindo ScaledObject, que descrevem como uma carga de trabalho deve responder a uma origem ou métrica de evento.

O KEDA é útil para cargas de trabalho que processam filas, fluxos, mensagens ou outros acúmulos de eventos. Ele pode reduzir a zero as cargas de trabalho compatíveis quando não houver eventos e aumentar o número de réplicas à medida que a lista de pendências cresce.

Não combine um KEDA ScaledObject com um HPA separado para a mesma carga de trabalho. O KEDA cria e usa um HPA internamente, para que os dimensionadores automáticos concorram entre si.

Para começar, confira a visão geral do complemento KEDA.

Provisionamento automático de nós

O NAP (Provisionamento Automático de Nós) usa o projeto de código aberto Karpenter para provisionar e gerenciar nós de acordo com os requisitos de pod pendentes. O NAP seleciona um SKU de máquina virtual adequado e uma quantidade de nós adequada para atender à demanda da carga de trabalho em tempo real.

O NAP começa com um conjunto permitido de SKUs de VM e seleciona a capacidade para cargas de trabalho pendentes. Você pode definir limites de recursos e preferências de agendamento para controlar como ele provisiona nós e distribui cargas de trabalho.

Escalabilidade e mecanismos de proteção do plano de controle

O AKS dimensiona automaticamente os componentes do plano de controle com base no tamanho do cluster e na utilização de recursos do servidor de API. Essas diretrizes se aplicam ao AKS Automatic e ao AKS Standard. Use a camada de preço Standard ou Premium para cargas de trabalho de produção ou em escala.

O Kubernetes tem um envelope de escala multidimensional no qual cada tipo de recurso coloca demandas diferentes no plano de controle. Por exemplo, os segredos geralmente são observados por vários controladores e pods que fazem uma chamada inicial LIST, criando mais carga no plano de controle do que recursos observados com menos frequência. Ampliar muito uma dimensão específica pode reduzir a capacidade nas outras. Por exemplo, executar centenas de milhares de pods pode reduzir a taxa de mutação de pods com suporte pelo plano de controle. Para obter recomendações, consulte as práticas recomendadas do cliente do Kubernetes para clusters AKS em larga escala.

Para verificar se o plano de controle foi ampliado, inspecione o ConfigMap large-cluster-control-plane-scaling-status:

kubectl describe configmap large-cluster-control-plane-scaling-status -n kube-system

A presença deste ConfigMap confirma que o AKS escala o plano de controle.

Proteções do plano de controle

Se o dimensionamento automático do servidor de API não o estabilizar sob alta carga, o AKS poderá implantar um guarda de servidor de API gerenciado. Essa salvaguarda de último recurso restringe as solicitações de clientes não pertencentes ao sistema para evitar que o plano de controle deixe de responder. Chamadas ao servidor de API críticas para o sistema, provenientes de componentes como kubelet, continuam funcionando.

Para determinar se a proteção do servidor de API gerenciado foi aplicada, verifique a presença de aks-managed-apiserver-guardFlowSchema e PriorityLevelConfiguration:

kubectl get flowschemas
kubectl get prioritylevelconfigurations

A proteção está ativa quando aks-managed-apiserver-guard aparece em ambas as saídas dos comandos.

Se esses recursos estiverem presentes, consulte o servidor de API e o guia de solução de problemas etc. para obter diretrizes de mitigação.

Intermitência para Instâncias de Contêiner do Azure (ACI)

Você pode integrar o AKS com Instâncias de Contêiner do Azure para lidar com aumentos rápidos na demanda. O dimensionamento automático de pods pode criar mais réplicas do que o pool de nós existente consegue suportar, enquanto o provisionamento de nós adicionais baseados em máquinas virtuais pode levar vários minutos. A ACI fornece capacidade de computação sem a necessidade de nós de VM adicionais.

Os nós virtuais (nós do Kubernetes virtuais com suporte da ACI) dão suporte a pods e nós do Linux e exigem um cluster do AKS que usa rede CNI do Azure. Eles não dão suporte a alguns cenários comuns, incluindo intervalos de IP autorizados do servidor de API, volumes persistentes e declarações de volume persistente, IPv6 e identidades gerenciadas anexadas a nós virtuais. Revise as limitações do nó virtual antes de usar o dimensionamento intermitente do ACI.

O componente de nós virtuais do AKS baseia-se no Kubelet Virtual e apresenta a ACI como um nó virtual do Kubernetes. O Kubernetes pode agendar pods elegíveis por meio do nó virtual para serem executados como instâncias de contêiner no ACI, em vez de serem executados diretamente nos nós de VM do AKS.

Os nós virtuais usam outra sub-rede na mesma rede virtual do cluster do AKS. Essa configuração fornece conectividade de rede privada entre o AKS e a ACI, permitindo que a ACI atue como uma extensão lógica do cluster.

Use os seguintes recursos para implementar o método de dimensionamento que se ajusta à carga de trabalho:

Para obter mais informações sobre os principais conceitos do Kubernetes e do AKS, consulte:

Comentários

Esta página foi útil?

Last updated on 2026-08-20