Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Ao executar aplicativos no Serviço Kubernetes do Azure (AKS), talvez seja necessário aumentar ou diminuir ativamente a quantidade de recursos de computação em seu cluster. À medida que você altera o número de instâncias de aplicativo que você tem, talvez seja necessário alterar o número de nós Kubernetes subjacentes. Também pode ser necessário provisionar um grande número de outras instâncias de aplicativo.
Este artigo apresenta os principais conceitos de dimensionamento de aplicativos AKS, incluindo o dimensionamento manual de pods ou nós, usando o autoscaler de pod horizontal, usando o autoscaler de cluster e integrando-o com as Instâncias de Contêiner do Azure (ACI).
Dimensionar manualmente pods ou nós
Você pode dimensionar manualmente réplicas ou pods e nós para testar como a sua aplicação responde a uma alteração nos recursos disponíveis e no estado. O dimensionamento manual de recursos permite definir uma quantidade definida de recursos a serem usados, como o número de nós, para manter um custo fixo. Para escalar manualmente, defina o número de réplicas ou de nós. Em seguida, a API do Kubernetes agenda a criação de mais pods ou a drenagem de nós com base nessa réplica ou contagem de nós.
Ao reduzir a escala dos nós, a API do Kubernetes aciona a API de Computação do Azure relevante associada ao tipo de computação utilizado pelo seu cluster. Por exemplo, para clusters criados em Conjuntos de Dimensionamento de Máquina Virtual, a API de Conjuntos de Dimensionamento de Máquina Virtual determina quais nós devem ser removidos. Para saber mais sobre como os nós são selecionados para remoção em escala reduzida, consulte as Perguntas frequentes sobre conjuntos de escala de máquina virtual.
Para começar a dimensionar nós manualmente, consulte Dimensionar manualmente nós em um cluster AKS. Para dimensionar manualmente o número de pods, consulte o comando kubectl scale.
Autoscaler horizontal de pod
O Kubernetes usa o escalador automático horizontal de pods (HPA) para monitorizar a procura de recursos e dimensionar automaticamente o número de pods. Por padrão, a HPA verifica a API de métricas a cada 15 segundos para quaisquer alterações necessárias na contagem de réplicas, enquanto a API de métricas recupera dados do Kubelet a cada 60 segundos. Como resultado, o HPA é atualizado a cada 60 segundos. Quando são necessárias alterações, o número de réplicas é dimensionado de acordo. A HPA trabalha com clusters AKS que implantaram o Metrics Server for Kubernetes versão 1.8 e superior.
Ao configurar o HPA para uma determinada implantação, você define o número mínimo e máximo de réplicas que podem ser executadas. Você também define a métrica para monitorar e basear as decisões de dimensionamento, como o uso da CPU.
Para começar a usar o autoscaler de pod horizontal no AKS, consulte Autoscale pods no AKS.
Intervalo de eventos de ajuste de escala
Como o HPA é efetivamente atualizado a cada 60 segundos, os eventos de escala anteriores podem não ter sido concluídos com êxito antes que outra verificação seja feita. Esse comportamento pode fazer com que o HPA altere o número de réplicas antes que o evento de escala anterior possa receber a carga de trabalho do aplicativo e as demandas de recursos sejam ajustadas adequadamente.
Para minimizar os eventos de corrida, um valor de atraso é definido. Esse valor define quanto tempo o HPA deve aguardar após um evento de escala antes que outro evento de escala possa ser acionado. Esse comportamento permite que a nova contagem de réplicas entre em vigor e que a API de métricas reflita a carga de trabalho distribuída. Não há atraso para eventos de expansão a partir do Kubernetes 1.12. No entanto, o atraso padrão em eventos de redução de escala é de 5 minutos.
Escalador automático de cluster
Para responder às mudanças nas demandas de pod, o autoscaler de cluster do Kubernetes ajusta o número de nós com base nos recursos de computação solicitados no pool de nós. Por padrão, o autoscaler do cluster verifica o servidor da API de métricas a cada 10 segundos em busca de alterações necessárias na contagem de nós. Se o autoscaler do cluster determinar que uma alteração é necessária, o número de nós no cluster AKS será aumentado ou diminuído de acordo. O autoscaler de cluster funciona com clusters AKS com RBAC do Kubernetes ativado, que executam a versão 1.10.x ou superior do Kubernetes.
O autoscaler de cluster é normalmente usado juntamente com o autoscaler horizontal de pod . Quando combinado, o autoscaler de pod horizontal aumenta ou diminui o número de pods com base na demanda de aplicativos, e o autoscaler de cluster ajusta o número de nós para executar mais pods.
Para começar a usar o autoscaler de cluster no AKS, consulte Autoscaler de cluster no AKS.
Dimensionar eventos
Se um nó não tiver recursos de computação suficientes para executar um pod solicitado, esse pod não poderá progredir no processo de agendamento. O pod não pode ser iniciado a menos que mais recursos computacionais sejam disponibilizados no grupo de nós.
Quando o autoscaler do cluster percebe pods que não podem ser agendados devido a restrições de recursos do pool de nós, o número de nós dentro do pool de nós é aumentado para fornecer recursos de computação extras. Quando os nós são implantados com êxito e estão disponíveis para uso dentro do pool de nós, os pods são agendados para serem executados neles.
Se seu aplicativo precisar ser dimensionado rapidamente, alguns pods podem permanecer em um estado de espera para serem agendados até que mais nós implantados pelo autoscaler do cluster possam aceitar os pods agendados. Para aplicativos que têm altas demandas de intermitência, você pode dimensionar com nós virtuais e Instâncias de Contêiner do Azure.
Escala de magnitude em eventos
O escalador automático de cluster também monitora o estado de agendamento do pod para nodos que não receberam recentemente novos pedidos de agendamento. Esse cenário indica que o pool de nós tem mais recursos de computação do que o necessário e o número de nós pode ser reduzido. Por padrão, os nós que passam um limite de não serem necessários por pelo menos 10 minutos são agendados para exclusão. Quando essa situação ocorre, os pods são agendados para serem executados em outros nós dentro do pool de nós e o escalador automático do cluster diminui o número de nós.
Seus aplicativos podem sofrer alguma interrupção, pois os pods são agendados em nós diferentes quando o autoscaler do cluster diminui o número de nós. Para minimizar interrupções, evite aplicativos que usam uma única instância de pod.
Dimensionamento automático orientado a eventos do Kubernetes (KEDA)
O Kubernetes Event-driven Autoscaling (KEDA) é um componente de código aberto para dimensionamento automático controlado por eventos de cargas de trabalho. Ele dimensiona cargas de trabalho dinamicamente com base no número de eventos recebidos. O KEDA estende o Kubernetes com uma definição de recurso personalizada (CRD), referida como ScaledObject, para descrever como os aplicativos devem ser dimensionados em resposta ao tráfego específico.
O dimensionamento KEDA é útil em cenários em que as cargas de trabalho recebem picos de tráfego ou lidam com grandes volumes de dados. O KEDA difere do Horizontal Pod Autoscaler, pois o KEDA é controlado por eventos e dimensionado com base no número de eventos, enquanto o HPA é controlado por métricas com base na utilização de recursos (por exemplo, CPU e memória).
Para começar a usar o complemento KEDA no AKS, consulte Visão geral do KEDA.
Autoprovisionamento de nós
O provisionamento automático de nós (visualização) (NAP) usa o projeto Karpenter de código aberto que implanta, configura e gerencia automaticamente o Karpenter em seu cluster AKS. A NAP provisiona dinamicamente nós com base nos requisitos pendentes de recursos do pod; ele selecionará automaticamente a SKU e a quantidade ideais de máquina virtual (VM) para atender à demanda em tempo real.
A NAP usa uma lista predefinida de SKUs de VM como ponto de partida para decidir qual SKU é mais adequado para cargas de trabalho pendentes. Para um controle mais preciso, os usuários podem definir os limites superiores de recursos usados por um pool de nós e preferências de onde as cargas de trabalho devem ser agendadas se houver vários pools de nós.
Escalonamento do Plano de Controlo e Salvaguardas
O Kubernetes tem um envelope de escala multidimensional, com cada tipo de recurso a representar uma dimensão. Nem todos os recursos são iguais. Por exemplo, os relógios são frequentemente definidos em segredos, o que resulta em chamadas de lista para o kube-apiserver, o que acrescenta custo e uma carga desproporcionalmente maior no plano de controlo em comparação com recursos sem relógios.
O plano de controlo gere toda a escalabilidade de recursos no cluster, por isso quanto mais escalares o cluster dentro de uma dada dimensão, menos podes escalar dentro de outras dimensões. Por exemplo, operar centenas de milhares de pods num cluster AKS afeta a taxa de rotação de pods (mutações de pod por segundo) que o plano de controlo consegue suportar. Consulte as melhores práticas.
O AKS escala automaticamente os componentes do plano de controlo com base em sinais-chave, como o número total de núcleos no cluster e CPU ou a pressão da memória nos componentes do plano de controlo.
Para verificar se o plano de controlo foi expandido, verifique o _ConfigMap_ nomeado 'large-cluster-control-plane-scaling-status'.
kubectl describe configmap large-cluster-control-plane-scaling-status -n kube-system
Salvaguardas do Plano de Controlo
Se escalar automaticamente o servidor API não o estabilizar em cenários de alta carga, o AKS implementa um guardião gerido do servidor API. Esta guarda atua como um mecanismo de último recurso para proteger o servidor API, limitando os pedidos do cliente que não são do sistema e impedindo que o plano de controlo se torne completamente inresponsivo. As chamadas críticas ao sistema para o servidor de API de componentes como o kubelet continuarão a funcionar normalmente.
Para verificar se a API managed server guard foi aplicada, verifique a presença do FlowSchema "aks-managed-apiserver-guard" e do PriorityLevelConfiguration.
kubectl get flowschemas
kubectl get prioritylevelconfigurations
Consulte o API server e o guia de resolução de problemas do Etcd se o FlowSchema "aks-managed-apiserver-guard" e o PriorityLevelConfiguration tiverem sido aplicados no cluster para uma mitigação rápida.
Burst para instâncias de contêiner do Azure (ACI)
Para dimensionar rapidamente seu cluster AKS, você pode integrar com as Instâncias de Contêiner do Azure (ACI). O Kubernetes tem componentes internos para dimensionar as réplicas e a contagem de nós. No entanto, se seu aplicativo precisar ser dimensionado rapidamente, o autoscaler de pod horizontal poderá agendar mais pods do que os recursos de computação existentes no pool de nós podem suportar. Se configurado, esse cenário acionaria o autoscaler do cluster para implantar mais nós no pool de nós, mas pode levar alguns minutos para que esses nós sejam provisionados com êxito e permitam que o agendador do Kubernetes execute pods neles.
O ACI permite implantar rapidamente instâncias de contêiner sem sobrecarga extra de infraestrutura. Quando você se conecta com o AKS, o ACI se torna uma extensão lógica e segura do seu cluster AKS. O componente de nós virtuais , que é baseado no Kubelet virtual, é instalado no cluster AKS que apresenta o ACI como um nó Kubernetes virtual. O Kubernetes pode, então, agendar pods que funcionam como instâncias ACI através de nós virtuais, em vez de como pods em nós VM diretamente no cluster AKS.
Seu aplicativo não requer modificações para usar nós virtuais. As suas implantações podem ser dimensionadas entre AKS e ACI sem atraso, à medida que o autoscaler do cluster implanta novos nós no seu cluster AKS.
Os nós virtuais são implantados em outra sub-rede na mesma rede virtual do cluster AKS. Esta configuração de rede virtual protege o tráfego entre ACI e AKS. Como um cluster AKS, uma instância ACI é um recurso de computação lógico e seguro isolado de outros usuários.
Próximos passos
Para começar a usar aplicativos de dimensionamento, consulte os seguintes recursos:
- Dimensionar manualmente pods ou nós
- Use o escalador automático de pods horizontal
- Usar o escalonador automático de clusters
- Utilize o complemento Kubernetes Event-driven Autoscaling (KEDA)
Para obter mais informações sobre os principais conceitos de Kubernetes e AKS, consulte os seguintes artigos: