Descrição geral do dimensionamento do Azure Kubernetes Service (AKS) — HPA, VPA, Cluster Autoscaler e KEDA

Quando executa aplicações no Azure Kubernetes Service (AKS), pode escalar pods, recursos dos pods, nós ou cargas de trabalho orientadas a eventos para acompanhar as alterações na procura. O AKS suporta dimensionamento manual, Horizontal Pod Autoscaler (HPA), Vertical Pod Autoscaler (VPA), Cluster Autoscaler, Kubernetes Event-driven Autoscaling (KEDA), autoprovisionamento de nós e dimensionamento em rajada com Azure Container Instances (ACI).

Escolha o método de escalonamento correto

Método de escalonamento Melhor para Métrica-chave Guide
Autoescalador de Pods Horizontais (HPA) Cargas de trabalho sem estado ou particionáveis com procura variável Utilização da CPU, RPS, profundidade da fila Quando devo usar o Horizontal Pod Autoscaling (HPA) no Kubernetes?
Escalador Automático de Pod Vertical (VPA) Cargas de trabalho não paralelizáveis; dimensionamento adequado dos pedidos de recursos do pod Utilização de recursos de CPU/memória Utilizar o Vertical Pod Autoscaler no AKS
Cluster Autoscaler Capacidade ao nível do nó quando os pods permanecem pendentes Pods pendentes Utilizar o Cluster Autoscaler no AKS
Aprovisionamento automático de nós (NAP) Cargas de trabalho pendentes que necessitam de capacidade de VM dimensionada corretamente Requisitos pendentes de recursos do pod Visão geral do autoprovisionamento de nós
KEDA Cargas de trabalho orientadas a eventos; capacidade de escalar até zero necessária Comprimento da fila, atraso de eventos Visão geral do complemento KEDA
Dimensionamento de picos do ACI Cargas de trabalho Linux com picos de procura que respeitam as limitações dos nós virtuais Picos de procura Criar nós virtuais com Azure Container Instances

Quando usar cada método de escala

  • Utilize o HPA quando a sua carga de trabalho puder executar várias réplicas idênticas e a procura variar consoante a CPU, a memória ou a taxa de pedidos.
  • Usa VPA quando a tua carga de trabalho não puder escalar horizontalmente (não paralelizável) ou quando precisares de dimensionar corretamente os pedidos de recursos para melhor agendamento.
  • Utilize o Cluster Autoscaler quando tiver conjuntos de nós predefinidos e precisar de adicionar ou remover nós com base nas necessidades dos pods pendentes.
  • Usa o NAP quando quiseres seleção automática de SKU de VM e provisionamento de nós sem configurar manualmente os pools de nós.
  • Usa o KEDA quando a escalabilidade deve responder a eventos externos (filas, fluxos, mensagens) ou precisas de capacidade de escalar para zero.
  • Use o dimensionamento dinâmico do ACI quando precisar de expandir rapidamente a capacidade para cargas de trabalho Linux sem ter de esperar pelo provisionamento da máquina virtual (normalmente, 2–5 minutos).

Recomendação rápida

Para a maioria das cargas de trabalho de produção, comece com o AKS Automatic, que pré-configura o NAP, VPA e KEDA. No AKS Standard, ativas e configuras estas funcionalidades explicitamente.

Dimensionar manualmente pods ou nós

Pode ajustar manualmente o número de réplicas dos pods e de nós para testar como a aplicação responde a alterações nos recursos disponíveis ou para manter uma capacidade fixa. Para escalar manualmente, defina o número necessário de réplicas ou de nós. O Kubernetes cria ou remove pods, enquanto o AKS adiciona ou remove nós do pool de nós correspondente.

Quando reduzes a escala dos nós, o AKS chama a API de computação do Azure relevante para o tipo de computação do cluster. Para clusters construídos sobre Conjuntos de Dimensionamento de Máquinas Virtuais, a API Conjuntos de Dimensionamento de Máquinas Virtuais determina quais os nós a remover. Para mais informações, consulte o Conjuntos de Dimensionamento de Máquinas Virtuais FAQ.

Para começar, consulte:

Escalador Horizontal de Pods

Use HPA quando a sua carga de trabalho pode correr várias réplicas idênticas e a procura variar. Dimensiona-se com base na CPU ou na memória, nas métricas da aplicação (pedidos por segundo, latência) ou em métricas externas da fila e dos pendentes. Quando as réplicas puderem exceder a capacidade dos nós existentes, utilize a funcionalidade NAP pré-configurada no AKS Automatic ou configure o Cluster Autoscaler ou o NAP no AKS Standard.

Não uses HPA e VPA nas mesmas métricas de CPU ou memória. Para usar ambos os autoescaladores, use o VPA em modo de recomendação ou configure o HPA para usar métricas personalizadas distintas.

Captura de ecrã de um diagrama que mostra como o Horizontal Pod Autoscaler funciona com o AKS.

Saiba mais: Quando devo usar o Horizontal Pod Autoscaling (HPA) no Kubernetes?

Veja também: Utilize o Vertical Pod Autoscaler no AKS para dimensionar adequadamente os pedidos de CPU e de memória do pod.

Autoescalador Vertical de Pods

O Vertical Pod Autoscaler analisa o uso de CPU e memória do pod e recomenda ou aplica pedidos de recursos apropriados. Use o VPA para ajustar cargas de trabalho que não conseguem escalar eficientemente adicionando réplicas ou para melhorar o agendamento e a utilização de recursos.

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

Para começar, veja Usar Vertical Pod Autoscaler no AKS.

Cluster Autoscaler

O Cluster Autoscaler ajusta o número de nós num pool de nós em função dos requisitos de agendamento de pods. Adiciona nós quando os pods não podem ser agendados devido à capacidade insuficiente dos nós e remove nós subutilizados quando as suas cargas de trabalho podem ser executadas noutros nós.

Captura de ecrã de um diagrama que mostra como o Cluster Autoscaler funciona com o AKS.

Cluster Autoscaler é comumente usado com HPA. O HPA ajusta o número de réplicas de pods em função da carga de trabalho, enquanto o Cluster Autoscaler ajusta a capacidade dos nós para acomodar esses pods.

Para começar, veja Usar Cluster Autoscaler no AKS.

Eventos de escala reduzida

Se um pool de nós não tiver recursos computacionais suficientes para um pod, o pod permanece Pendente. Quando o Cluster Autoscaler deteta pods que não podem ser programados devido às restrições de recursos do pool de nós, aumenta o número de nós desse pool. O Kubernetes agenda os pods pendentes depois de os novos nós estarem provisionados e ficarem prontos.

O provisionamento de nós baseados em VM pode demorar vários minutos. Para cargas de trabalho com picos súbitos de procura, considere utilizar nós virtuais e Azure Container Instances.

Eventos de redução de capacidade

O Cluster Autoscaler monitoriza os nós para detetar subutilização e determina se os respetivos pods podem ser executados noutros nós. Quando um nó deixa de ser necessário, o Kubernetes reescala os seus pods e o AKS remove o nó do pool de nós.

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

Kubernetes Autoscaling Orientado por Eventos

O Kubernetes Event-driven Autoscaling (KEDA) é um componente open-source que escala cargas de trabalho com base em eventos. A KEDA estende o Kubernetes com recursos personalizados, incluindo ScaledObject, que descrevem como uma carga de trabalho deve responder a uma fonte de evento ou métrica.

O KEDA é útil para cargas de trabalho que processam filas, fluxos, mensagens ou outros backlogs de eventos. Pode escalar as cargas de trabalho suportadas para zero quando não há eventos disponíveis e aumentar as réplicas à medida que o backlog cresce.

Não combines um KEDA ScaledObject com um HPA separado para a mesma carga de trabalho. KEDA cria e usa um HPA internamente, pelo que os mecanismos de escalamento automático competiriam entre si.

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

Autoprovisionamento de nós

O autoprovisionamento de nós (NAP) utiliza o projeto de código aberto Karpenter para provisionar e gerir nós de acordo com os requisitos pendentes dos pods. O NAP seleciona um SKU de máquina virtual e um número de nós adequados para dar resposta à procura da carga de trabalho em tempo real.

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

Escalonamento do plano de controlo e salvaguardas

O AKS escala automaticamente os componentes do plano de controlo com base no tamanho do cluster e na utilização dos recursos do servidor API. Esta orientação aplica-se ao AKS Automatic e ao AKS Standard. Utilize o escalão de preços Standard ou Premium para cargas de trabalho de produção ou em grande escala.

O Kubernetes tem um envelope de escala multidimensional em que cada tipo de recurso impõe diferentes exigências no plano de controlo. Por exemplo, os segredos são frequentemente vigiados por múltiplos controladores e pods que fazem uma chamada inicial LIST , criando mais carga no plano de controlo do que os recursos menos frequentemente observados. Escalar fortemente numa dimensão pode reduzir a capacidade noutras. Por exemplo, operar centenas de milhares de pods pode reduzir a taxa de mutação dos pods que o plano de controlo suporta. Para recomendações, consulte as melhores práticas do cliente Kubernetes para clusters AKS de grande escala.

Para verificar se o plano de controlo foi aumentado, 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 expande o plano de controlo.

Salvaguardas do plano de controlo

Se a escalabilidade automática do servidor API não o estabilizar sob carga elevada, o AKS pode implementar um guarda de servidor API gerido. Esta salvaguarda de último recurso restringe os pedidos de clientes que não são do sistema para evitar que o plano de controlo deixe de responder. Chamadas de servidor API críticas ao sistema a partir de componentes como kubelet continuam a funcionar.

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

kubectl get flowschemas
kubectl get prioritylevelconfigurations

A guarda está ativa quando aks-managed-apiserver-guard aparece em ambas as saídas de comando.

Se estes recursos estiverem presentes, consulte o guia de resolução de problemas do servidor API e do etcd para orientações de mitigação.

Burst para instâncias de contêiner do Azure (ACI)

Pode integrar o AKS com o Azure Container Instances para lidar com aumentos rápidos da procura. O escalonamento automático de pods pode criar mais réplicas do que o conjunto de nós existente pode suportar, enquanto o aprovisionamento de nós adicionais baseados em máquinas virtuais pode demorar vários minutos. O ACI fornece capacidade de computação sem necessidade de nós adicionais de VM.

Os nós virtuais (nós virtuais do Kubernetes baseados em ACI) suportam pods e nós Linux e requerem um cluster do AKS que utilize a rede Azure CNI. Não suportam alguns cenários comuns, incluindo intervalos de IP autorizados por servidores API, volumes persistentes e reclamações de volumes persistentes, IPv6 e identidades geridas ligadas a nós virtuais. Reveja as limitações dos nós virtuais antes de usar o escalonamento em rajada ACI.

Captura de ecrã de um diagrama que mostra como o Azure Container Instances funciona com o AKS.

O componente de nós virtuais do AKS baseia-se no Virtual Kubelet 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 contentor do 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 AKS. Esta configuração proporciona conectividade de rede privada entre o AKS e o ACI, permitindo que o ACI funcione como uma extensão lógica do cluster.

Conteúdo relacionado

Use os seguintes recursos para implementar o método de escalabilidade que se adapte à sua carga de trabalho:

Para mais informações sobre os conceitos centrais de Kubernetes e AKS, veja:

  • Last updated on