Opções dimensionamento para aplicativos no AKS (Serviço de Kubernetes do Azure)
Ao executar aplicativos no AKS (Serviço de Kubernetes do Azure), talvez precise aumentar ou diminuir a quantidade de recursos de computação. Ao alterar o número de instâncias do aplicativo que você possui, talvez precisará alterar o número de nós subjacentes do Kubernetes. Talvez você também precise provisionar um grande número de outras instâncias de aplicativos.
Este artigo apresenta os principais conceitos de dimensionamento de aplicativos do AKS, incluindo dimensionamento manual de pods ou nós, usando o Dimensionador automático de pod horizontal, usando o Dimensionador automático de cluster e integrando-se com as Instâncias de Contêiner do Azure (ACI).
Dimensionar manualmente os pods ou os nós
Você pode dimensionar manualmente réplicas, ou pods e nós para testar como seu aplicativo responde a uma alteração no estado e nos recursos disponíveis. Dimensionar os recursos manualmente permite estabelecer 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 contagem de réplicas e de nós. A API do Kubernetes agenda a criação de mais pods ou a descarga de nós com base nessa contagem de réplicas ou nós.
Ao reduzir os nós verticalmente, 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 construídos em Conjuntos de Dimensionamento de Máquinas Virtuais, a API de Conjuntos de Dimensionamento de Máquinas Virtuais determina quais nós serão removidos. Para saber mais sobre como os nós são selecionados para remoção na redução vertical, confira as Perguntas frequentes sobre os Conjuntos de Dimensionamento de VMs.
Para começar a dimensionar manualmente os nós, consulte como dimensionar manualmente os nós em um cluster do AKS. Para dimensionar manualmente o número de pods, consulte o comando kubectl scale.
Dimensionador automático de pod horizontal
O Kubernetes usa o HPA (dimensionador automático de pod horizontal) para monitorar a demanda por recursos e dimensionar automaticamente o número de pods. Por padrão, a cada 15 segundos o HPA verifica se há alguma alteração necessárias na contagem de réplicas da API de Métricas, 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 aumenta ou diminui de acordo. O HPA funciona com clusters do AKS que implantaram o Servidor de Métricas para Kubernetes na versão 1.8 e superior.
Ao configurar o HPA para uma determinada implantação, você define os números mínimo e máximo de réplicas que podem ser executados. Você também define a métrica para monitorar e basear quaisquer decisões de dimensionamento, como uso da CPU.
Para começar a usar o dimensionador automático de pod horizontal no AKS, confira Dimensionamento automático de pods no AKS.
Resfriamento de eventos de dimensionamento
Uma vez que o HPA verifica a API de métricas, de fato, a cada 60 segundos, eventos de escala anteriores podem não ter sido concluídos antes de outra verificação ser feita. Esse comportamento pode fazer o HPA mudar o número de réplicas antes que o evento de dimensionamento anterior seja capaz de receber a carga de trabalho do aplicativo e as demandas de recursos para ajustar-se adequadamente.
Para minimizar os eventos de corrida, um valor de atraso é definido. Esse valor define quanto o HPA deve esperar após um evento de escala, antes que outro evento de escala possa ser disparado. Esse comportamento permite que a nova contagem de réplicas entre em vigor e a API de Métricas reflita a carga de trabalho distribuída. Não há nenhum atraso para eventos de escala vertical a partir do Kubernetes 1.12, no entanto, o atraso padrão em eventos de redução vertical é de 5 minutos.
Dimensionador automático de cluster
Para responder a mudanças nas demandas de pod, o dimensionador automático de cluster do Kubernetes ajusta o número de nós de acordo com os recursos de computação solicitados no pool de nós. Por padrão, o dimensionador automático de cluster verifica o servidor de API de Métricas a cada dez segundos quanto a alterações necessárias na contagem de nós. Se o dimensionador automático de cluster determinar que uma alteração é necessária, o número de nós no cluster do AKS aumentará ou diminuirá de acordo. O dimensionador automático de cluster funciona com clusters do AKS habilitados para RBAC do Kubernetes que executam o Kubernetes 1.10.x ou superior.
O dimensionador automático do cluster normalmente é usado junto com o dimensionador automático de pod horizontal. Quando combinado, o dimensionador automático de pod horizontal aumenta ou diminui o número de pods com base na demanda do aplicativo, e o dimensionador automático de cluster ajusta o número de nós para executar mais pods.
Para começar a usar o dimensionador automático de cluster no AKS, confira Dimensionador automático de cluster no AKS.
Eventos de escala horizontal
Se um nó não tiver recursos de computação suficientes para executar um pod solicitado, esse pod não poderá avançar pelo processo de agendamento. O pod não pode ser iniciado a menos que haja mais recursos de computação disponíveis no pool de nós.
Quando o dimensionador automático de cluster observa pods que não podem ser agendados devido a restrições de recursos do pool de nós, o número de nós no pool é aumentado para fornecer recursos de computação adicionais. Quando os nós foram implantados com sucesso e estão disponíveis para uso dentro do pool de nós, os pods são agendados para serem executados neles.
Se o aplicativo precisar ser dimensionado rapidamente, alguns pods podem permanecer em um estado de espera para serem agendados até que mais nós implantados pelo dimensionador automático de 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.
Eventos de redução horizontal
O dimensionador automático do cluster também monitora o status de agendamento do pod para nós que não receberam novas solicitações de agendamento recentemente. 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 diminuído. 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, pods são agendados para execução em outros nós dentro do pool de nós e o dimensionador automático de cluster diminui o número de nós.
Seus aplicativos podem apresentar alguma interrupção, uma vez que os pods são agendados em nós diferentes quando o dimensionador automático cluster diminui o número de nós. Para minimizar as interrupções, evite a aplicativos que usem uma instância única de pod.
KEDA (Dimensionamento Automático controlado por Eventos do Kubernetes)
O KEDA (dimensionamento automático controlado por eventos) do Kubernetes é um componente de código aberto para o dimensionamento automático de cargas de trabalho controladas por eventos. Ele escala cargas de trabalho dinamicamente de acordo com o número de eventos recebidos. O KEDA estende o Kubernetes com uma CRD (definição de recurso personalizado), conhecida como ScaledObject, para descrever como os aplicativos devem ser escalados em resposta a um tráfego específico.
O dimensionamento KEDA é útil em cenários em que as cargas de trabalho recebem intermitências de tráfego ou lidam com grandes volumes de dados. Ele é diferente do Dimensionador Automático de Pod Horizontal, pois o KEDA é controlado por eventos e é escalado de acordo com o 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, confira Visão geral do KEDA.
Intermitência para Instâncias de Contêiner do Azure (ACI)
Para dimensionar rapidamente o cluster do AKS, você pode integrar com ACI (Instâncias de Contêiner do Azure). O Kubernetes tem componentes internos para dimensionar a contagem de nós e de réplicas. No entanto, se o aplicativo precisar dimensionar rapidamente, o dimensionador automático de pod horizontal poderá agendar mais pods, que podem ser fornecidos pelos recursos de computação existentes no pool de nós. Se configurado, esse cenário dispararia o dimensionador automático de cluster para implantar mais nós no pool de nós, mas pode levar alguns minutos para que esses nós sejam provisionados com sucesso e permitam que o agendador do Kubernetes execute os pods neles com êxito.
As ACI permitem implantar rapidamente instâncias de contêiner sem sobrecarga adicional à infraestrutura. Quando você se conecta com o AKS, ACI torna-se uma extensão segura e lógica do seu cluster do AKS. O componente nós virtuais, que tem base no Kubelet virtual, é instalado em seu cluster do AKS que apresenta ACI como um nó virtual do Kubernetes. O Kubernetes então pode agendar pods que são executados como instâncias ACI por meio de nós virtuais, não como pods em nós de VM diretamente no cluster do AKS.
Seu aplicativo não requer modificações para usar os nós virtuais. As suas implantações podem ser dimensionadas para AKS e ACI e sem atraso, uma vez que o dimensionador automático de cluster implanta novos nós no cluster do AKS.
Os nós virtuais são implantados em outra sub-rede na mesma rede virtual do cluster do AKS. Essa configuração de rede virtual protege que o tráfego entre ACI e AKS. Como um cluster do AKS, uma instância ACI é um recurso de computação seguro e lógico, isolado de outros usuários.
Próximas etapas
Para começar a usar o dimensionamento de aplicativos, consulte os seguintes recursos:
- Dimensionar manualmente os pods ou os nós
- Use o dimensionador automático de pod horizontal
- Usar o dimensionador automático de cluster
- Usar o complemento do KEDA (dimensionamento automático controlado por eventos do Kubernetes)][keda-addon]
Para obter mais informações sobre os principais conceitos do Kubernetes e do AKS, confira os seguintes artigos: