Visão geral do dimensionamento automático de cluster no Serviço Kubernetes do Azure (AKS)

Para acompanhar as demandas de aplicativos no Serviço Kubernetes do Azure (AKS), talvez seja necessário ajustar o número de nós que executam suas cargas de trabalho. O componente autoscaler do cluster monitoriza pods no seu cluster que não podem ser agendados devido a restrições de recursos. Quando o autoscaler do cluster deteta pods não agendados, ele aumenta o número de nós no pool de nós para atender à demanda da aplicação. O sistema verifica regularmente os nós que não têm pods programados e, além disso, reduz o número de nós conforme necessário.

Este artigo ajuda você a entender como o autoscaler de cluster funciona no AKS. Ele também fornece orientação, práticas recomendadas e considerações ao configurar o Cluster Autoscaler para as suas cargas de trabalho no AKS. Se você quiser habilitar, desabilitar ou atualizar o autoscaler de cluster para suas cargas de trabalho AKS, consulte Usar o autoscaler de cluster no AKS.

Acerca do escalonador automático de clusters

Os clusters geralmente precisam de uma maneira de dimensionar automaticamente para se ajustar às demandas de aplicativos em constante mudança, como entre dias úteis e noites ou fins de semana. Os clusters AKS podem ser dimensionados das seguintes maneiras:

• O escalonador automático de clusters verifica periodicamente se há pods que não podem ser agendados para execução em nós devido a restrições de recursos. Em seguida, o cluster aumenta automaticamente o número de nós. O dimensionamento manual é desativado quando utiliza o dimensionamento automático de clusters. Para obter mais informações, consulte Como funciona o aumento de escala?.
• O Horizontal Pod Autoscaler usa o Metrics Server em um cluster Kubernetes para monitorar a demanda de recursos de pods. Se um aplicativo precisar de mais recursos, o número de pods é automaticamente aumentado para atender à demanda.
• O Vertical Pod Autoscaler define automaticamente solicitações de recursos e limites em contêineres por carga de trabalho com base no uso anterior para garantir que os pods sejam agendados em nós que tenham os recursos de CPU e memória necessários.

É uma prática comum ativar o autoscaler de clusters para os nós e o Vertical Pod Autoscaler ou o Horizontal Pod Autoscaler para os pods. Quando você habilita o dimensionador automático de cluster, ele aplica as regras de dimensionamento especificadas quando o tamanho do pool de nós é menor do que a contagem mínima de nós, até a contagem máxima de nós. O autoscaler de cluster aguarda para entrar em vigor até que um novo nó seja necessário no pool de nós ou até que um nó possa ser excluído com segurança do pool de nós atual. Para obter mais informações, consulte Como funciona a redução de escala?

Práticas recomendadas e considerações

• Ao implementar zonas de disponibilidade com o autoscaler de cluster, recomendamos o uso de um único pool de nós para cada zona. Você pode definir o parâmetro --balance-similar-node-groups para True para manter uma distribuição equilibrada de nós entre zonas para suas cargas de trabalho durante operações de expansão. Quando essa abordagem não é implementada, as operações de redução de escala podem interromper o equilíbrio de nós entre zonas.
• Para clusters com mais de 400 nós, recomendamos usar o Azure CNI ou o Azure CNI Overlay.
• Para executar efetivamente cargas de trabalho simultaneamente em pools de nós Spot e Fixo, considere o uso de expansores de prioridade. Essa abordagem permite que você programe pods com base na prioridade do pool de nós.
• Tenha cuidado ao atribuir solicitações de CPU/memória em pods. O autoscaler do cluster escalona com base em pods pendentes em vez de pressão de memória/CPU nos nós do cluster.
• Para clusters que hospedam simultaneamente cargas de trabalho de longa duração, como aplicativos Web, e cargas de trabalho curtas/intermitentes, recomendamos separá-las em pools de nós distintos com Regras de Afinidade/ ou usar PodDisruptionBudget para ajudar a evitar a drenagem desnecessária de nós ou a redução das operações. Especificar a anotação cluster-autoscaler.kubernetes.io/safe-to-evict: "false" na especificação do Pod também impedirá que o Pod seja removido. Use esta anotação com cuidado, pois pode fazer com que o Ajustador Automático de Clusters enfrente problemas ao libertar um nó com um Pod ativo que inclua esta anotação.
• Em um pool de nós habilitado para autoscaler, reduza os nós removendo cargas de trabalho, em vez de reduzir manualmente a contagem min/max do pool de nós. Isso pode ser problemático se o pool de nós já estiver na capacidade máxima ou se houver cargas de trabalho ativas em execução nos nós, potencialmente causando um comportamento inesperado pelo autoscaler do cluster.
• Os nós não são escalados se os pods tiverem um valor de PriorityClass abaixo de -10. A prioridade -10 é reservada para pods de superprovisionamento. Para obter mais informações, consulte Usando o autoscaler de cluster com prioridade de Pod e preempção.
• Não combine outros mecanismos de dimensionamento automático de nós, como escaladores automáticos do Conjunto de Escala de Máquina Virtual, com o autoscaler de cluster.
• O autoscaler de clusters pode não conseguir reduzir a escala se os pods não conseguirem mover-se, como nas seguintes situações:
  • Um pod criado diretamente não apoiado por um objeto controlador, como um Deployment ou ReplicaSet.
  • Um orçamento de interrupção de pods (PDB) que é demasiado limitativo e não permite que o número de pods fique abaixo de um determinado limite.
  • Um pod usa seletor de nós ou antiafinidade que não podem ser respeitados se programados em um nó diferente. Para obter mais informações, consulte Que tipos de pods podem impedir que o autoscaler do cluster remova um nó?.

• O autoscaler de cluster não é responsável por impor uma "contagem máxima de nós" em um pool de nós de cluster, independentemente das considerações de agendamento de pod. Se qualquer ator que não seja o escalador automático de cluster definir o número do grupo de nós para além do máximo configurado pelo escalador automático de cluster, o escalador automático de cluster não remove automaticamente os nós. Os comportamentos de redução de escala do autoscaler de cluster continuam focados em remover nós subutilizados. O único objetivo da configuração de contagem máxima de nós do autoscaler do cluster é impor um limite superior para operações de scale-up. Não tem qualquer efeito sobre as considerações de redução de escala.

Perfil de autoscaler de cluster

O perfil do autoscaler do cluster é um conjunto de parâmetros que controlam o comportamento do autoscaler do cluster. Você pode configurar o perfil do autoscaler do cluster ao criar um cluster ou atualizar um cluster existente.

Otimização do perfil do autoscaler do cluster

Você deve ajustar as configurações do perfil do autoscaler do cluster de acordo com seus cenários de carga de trabalho específicos e, ao mesmo tempo, considerar as compensações entre desempenho e custo. Esta seção fornece exemplos que demonstram essas compensações.

É importante observar que as configurações do perfil do autoscaler do cluster são válidas para todo o cluster e aplicadas a todos os pools de nós habilitados para dimensionamento automático. Quaisquer ações de dimensionamento que ocorram em um pool de nós podem afetar o comportamento de dimensionamento automático de outros pools de nós, o que pode levar a resultados inesperados. Certifique-se de aplicar configurações de perfil consistentes e sincronizadas em todos os pools de nós relevantes para garantir que você obtenha os resultados desejados.

Exemplo 1: Otimizando para desempenho

Para clusters que lidam com cargas de trabalho substanciais e intermitentes, com foco principal no desempenho, recomendamos aumentar o scan-interval e diminuir o scale-down-utilization-threshold. Essas configurações ajudam a agrupar várias operações de dimensionamento em uma única chamada, otimizando o tempo de dimensionamento e a utilização de cotas de leitura/gravação de computação. Ele também ajuda a mitigar o risco de reduzir rapidamente as operações em nós subutilizados, aumentando a eficiência do agendamento do pod. Também aumente ok-total-unready-count e max-total-unready-percentage.

Para clusters com pods daemonset, recomendamos definir ignore-daemonsets-utilization para true, o que efetivamente ignora a utilização dos nós por os pods daemonset e minimiza operações desnecessárias de redução de escala. Veja o perfil para cargas de trabalho intermitentes

Exemplo 2: Otimização para custo

Se você quiser um perfil de custo otimizado, recomendamos definir as seguintes configurações de parâmetro:

• Reduzir scale-down-unneeded-time, que é a quantidade de tempo que um nó deve estar desnecessário antes de ser elegível para redução de capacidade.
• Reduzir scale-down-delay-after-add, que é a quantidade de tempo de espera após a adição de um nó antes de considerá-lo para redução de escala.
• Aumentar scale-down-utilization-threshold, que é o limite de utilização para remover nós de rede.
• Aumentar max-empty-bulk-delete, que é o número máximo de nós que podem ser excluídos em uma única chamada.
• Defina skip-nodes-with-local-storage como false.
• Aumentar ok-total-unready-counte max-total-unready-percentage.

Problemas comuns e recomendações de mitigação

Visualize falhas de dimensionamento e eventos de escalonamento não acionados via CLI ou Portal.

Não acionar operações de aumento de escala

Aumente a escala das falhas de operação

Reduza as falhas de operação

Outros problemas

Grupo de nós em retrocesso

O pool de nós em recuo foi introduzido na versão 0.6.2 e faz com que o escalador automático do cluster reduza o dimensionamento de um pool de nós após uma falha.

Dependendo de quanto tempo as operações de dimensionamento têm sofrido falhas, pode levar até 30 minutos antes de fazer outra tentativa. Você pode redefinir o estado de backoff do pool de nós desativando e reativando o dimensionamento automático.