Opções de dimensionamento para aplicações no Serviço Kubernetes do Azure (AKS)
Ao executar aplicativos no Serviço Kubernetes do Azure (AKS), talvez seja necessário aumentar ou diminuir a quantidade de recursos de computação. À 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 seu aplicativo responde a uma alteração nos recursos e no estado disponíveis. O dimensionamento manual de recursos permite definir uma quantidade definida de recursos a serem usados para manter um custo fixo, como o número de nós. Para dimensionar manualmente, defina a réplica ou a contagem 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 os nós, a API do Kubernetes chama a API de Computação do Azure relevante vinculada ao tipo de computação usado pelo 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 remover. 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.
Dimensionador automático de pods horizontal
O Kubernetes usa o autoscaler horizontal de pods (HPA) para monitorar a demanda de recursos e dimensionar automaticamente o número de pods. Por padrão, o HPA verifica a API de métricas a cada 15 segundos para quaisquer alterações necessárias na contagem de réplicas, e a API de métricas recupera dados do Kubelet a cada 60 segundos. Assim, o HPA é atualizado a cada 60 segundos. Quando são necessárias alterações, o número de réplicas é aumentado ou diminuído 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 na qual monitorar e basear quaisquer decisões de escala, como o uso da CPU.
Para começar a usar o autoscaler de pod horizontal no AKS, consulte Autoscale pods no AKS.
Resfriamento de eventos de dimensionamento
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.
Dimensionador 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 habilitados para RBAC do Kubernetes que executam o Kubernetes 1.10.x ou superior.
O autoscaler de cluster é normalmente usado ao lado do autoscaler de pod horizontal. 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 de computação estejam disponíveis no pool 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 aguardando 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 em eventos
O autoscaler de cluster também monitora o status de agendamento do pod para nós que não receberam recentemente novas solicitações 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 ultrapassam um limite por não serem mais necessários por 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 autoscaler 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. É diferente 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.
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 a réplica e a contagem de nós. No entanto, se seu aplicativo precisar ser dimensionado rapidamente, o autoscaler de pod horizontal pode agendar mais pods do que pode ser fornecido pelos recursos de computação existentes no pool de nós. 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 provisionem 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 são executados como instâncias ACI através de nós virtuais, não como pods em nós VM diretamente no cluster AKS.
Seu aplicativo não requer modificações para usar nós virtuais. Suas implantações podem ser dimensionadas entre AKS e ACI e sem atraso, pois o autoscaler do cluster implanta novos nós em 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 autoscaler de pod horizontal
- Usar o autoscaler de cluster
- Use o complemento [Kubernetes Event-driven Autoscaling (KEDA)][keda-addon]
Para obter mais informações sobre os principais conceitos de Kubernetes e AKS, consulte os seguintes artigos: