O que é o Cluster Autoscaler do Kubernetes?
O Cluster Autoscaler do Kubernetes é um componente open-source projetado para ajustar automaticamente o tamanho de um cluster Kubernetes com base na demanda atual dos workloads. Ele funciona monitorando pods que não conseguem ser agendados por falta de recursos e, quando necessário, expande o cluster adicionando mais nós. Na direção oposta, ele identifica nós subutilizados e reduz o cluster removendo nós desnecessários, garantindo o uso ideal dos recursos e eficiência de custos.
Esse escalonamento dinâmico ajuda a manter alta disponibilidade e desempenho sem intervenção manual. O Cluster Autoscaler oferece suporte a vários provedores de nuvem, incluindo AWS, Azure e Google Cloud, integrando-se perfeitamente aos serviços gerenciados de Kubernetes de cada um. Ele usa APIs específicas de cada provedor para provisionar e desativar nós conforme necessário, permitindo que as organizações respondam a mudanças nos padrões de tráfego em tempo real.
Este artigo faz parte de uma série sobre autoscaling no Kubernetes
Neste artigo:
- O que são Helm charts?
- Tutorial: primeiros passos com o Cluster Autoscaler via Helm Chart
- Boas práticas do Cluster Autoscaler com Helm Chart
O que são Helm charts?
Helm charts são pacotes padronizados para aplicações Kubernetes, contendo todos os manifestos YAML e templates necessários para definir, configurar e implantar workloads complexos. Eles simplificam o processo de deploy ao agrupar recursos da aplicação, dependências e valores de configuração em um único artefato reutilizável. Os Helm charts podem ser:
- Versionados
- Compartilhados
- Armazenados em repositórios
Com Helm charts, as equipes podem automatizar a instalação, o upgrade e o rollback de aplicações, reduzindo o risco de erro humano e garantindo consistência entre ambientes. O mecanismo de templates do Helm permite deployments personalizáveis, possibilitando que os usuários sobrescrevam valores padrão por meio de um arquivo de values ou de argumentos de linha de comando.
Guia rápido: executando o Cluster Autoscaler com Helm Chart
Pré-requisitos do Helm Chart do Cluster Autoscaler
Antes de instalar o chart do Cluster Autoscaler, certifique-se de estar usando Helm 3+ e Kubernetes 1.35.x ou superior. O Azure AKS exige Kubernetes 1.10 ou superior com RBAC habilitado.
Internamente, o Cluster Autoscaler simula o comportamento do scheduler do Kubernetes. Embora outras versões do Kubernetes possam funcionar ao sobrescrever a imagem do container, versões incompatíveis podem introduzir problemas sutis de agendamento. O chart atual usa a versão v2 da API de Helm chart, portanto versões do Helm anteriores à 3 não são suportadas.
Se você está migrando de uma versão 1.X do cluster-autoscaler-chart, desinstale essa release antes de instalar o cluster-autoscaler na versão 9.0.0 ou posterior. As releases 1.X mais antigas do chart estão descontinuadas.
Passo 1: adicione o repositório Helm do Cluster Autoscaler
O chart do Cluster Autoscaler é instalado a partir do caminho autoscaler/cluster-autoscaler. Antes da instalação, verifique se o repositório que contém esse chart está configurado no seu ambiente Helm.
O chart não cria um deployment funcional de autoscaling apenas com os valores padrão. Durante a instalação, é preciso configurar o auto-discovery de grupos de nós ou grupos de nós estáticos. Não é recomendado usar as duas abordagens ao mesmo tempo.
Com o auto-discovery, defina autoDiscovery.clusterName e os valores específicos do provedor que forem necessários. Para a configuração estática, defina um ou mais grupos por meio de autoscalingGroups ou autoscalingGroupsnamePrefix.
Passo 2: como instalar o Cluster Autoscaler com Helm
Instale o chart com helm install, fornecendo a configuração exigida pelo seu provedor de nuvem. Para configurações armazenadas em um arquivo de values, use:
helm install my-release autoscaler/cluster-autoscaler -f myvalues.yaml
Seus values precisam identificar os grupos de nós que o autoscaler pode gerenciar. Você pode configurar o auto-discovery com autoDiscovery.clusterName ou definir explicitamente os grupos e seus tamanhos mínimo e máximo.
Após a instalação, verifique os logs do autoscaler para confirmar que seu loop principal está em execução. Se não estiver, inspecione o pod gerado e confira os argumentos passados ao comando cluster-autoscaler.
Passo 3: instale o Cluster Autoscaler na AWS usando Helm
Na AWS, o Cluster Autoscaler pode descobrir automaticamente os Auto Scaling Groups (ASGs). Marque cada ASG gerenciado com as tags k8s.io/cluster-autoscaler/enabled e k8s.io/cluster-autoscaler/<CLUSTER NAME>. Apenas as chaves das tags são relevantes.
Em seguida, instale o chart com o nome do cluster e a região da AWS:
helm install my-release autoscaler/cluster-autoscaler \
--set autoDiscovery.clusterName=<CLUSTER NAME> \
--set awsRegion=<YOUR AWS REGION>
Você também pode fornecer awsAccessKeyID e awsSecretAccessKey durante a instalação. No Amazon EKS, uma alternativa é associar a service account do autoscaler a uma role do IAM e passar seu ARN por meio da annotation da service account.
Se não quiser usar o auto-discovery, especifique os ASGs manualmente:
helm install my-release autoscaler/cluster-autoscaler \
--set "autoscalingGroups[0].name=your-asg-name" \
--set "autoscalingGroups[0].maxSize=10" \
--set "autoscalingGroups[0].minSize=1"
O worker que executa o autoscaler precisa ter as permissões de IAM necessárias para inspecionar e modificar os recursos relevantes do AWS Auto Scaling.
Conteúdo relacionado: leia nosso comparativo Karpenter vs. Cluster Autoscaler
Passo 4: faça o upgrade do Helm Chart do Cluster Autoscaler
Ao atualizar instalações mais antigas, leve em conta as mudanças de versão do chart. As releases a partir da versão 9.0.0 usam o nome de chart cluster-autoscaler. Para migrar de uma release descontinuada 1.X do cluster-autoscaler-chart, primeiro desinstale a instalação 1.X existente e depois instale a versão 9.0.0 ou posterior.
A versão 9.1.0 também muda o significado de envFromConfigMap. Ele deve conter o nome de um ConfigMap referenciado por envFrom. Configurações que dependem do comportamento anterior de envFromConfigMap devem renomear essa configuração para extraEnvConfigMaps.
Para referência, uma release pode ser removida com:
helm uninstall my-release
Isso exclui os componentes Kubernetes associados a essa release do Helm. Antes de mudar de versão, revise os valores de configuração que podem ter mudado entre a versão instalada e a versão de destino do chart.
Boas práticas do Cluster Autoscaler com Helm Chart
A seguir, algumas práticas importantes para levar em conta ao trabalhar com o Cluster Autoscaler via Helm charts.
1. Dimensione corretamente as requests de CPU e memória
Fazer o right-sizing das requests de CPU e memória dos seus workloads é essencial ao usar o Cluster Autoscaler. Se as requests forem muito altas, o scheduler pode provisionar nós em excesso, gerando desperdício de recursos e aumento de custos. Por outro lado, definir requests muito baixas traz risco de disputa por recursos e possível instabilidade da aplicação.
Ações principais:
- Analise o histórico de uso de recursos e defina requests e limits com base nas necessidades reais, e não em valores padrão ou suposições.
- Revise e ajuste essas configurações regularmente conforme os workloads evoluem.
- Use ferramentas de monitoramento do Kubernetes para observar o consumo de recursos em tempo real e identificar oportunidades de otimização.
Requests de recursos bem calibradas melhoram a eficiência do autoscaler, garantindo que novos nós sejam adicionados apenas quando realmente necessário e que os recursos existentes sejam bem aproveitados.
2. Trate o right-sizing de workloads e o autoscaling de nós como um único sistema
O right-sizing de workloads e o autoscaling de nós não devem ser gerenciados de forma isolada. Mudanças nas requests de recursos das aplicações impactam diretamente como o autoscaler escala o cluster. Se os workloads estiverem consistentemente superprovisionados, o autoscaler adicionará nós desnecessariamente, enquanto o subprovisionamento pode resultar em pods que não podem ser agendados e queda de desempenho. Coordenar esses processos ajuda a manter o equilíbrio entre disponibilidade de recursos e custo.
Ações principais:
- Implemente ferramentas ou políticas automatizadas que ajustem em conjunto as requests dos workloads e o tamanho dos grupos de nós.
- Garanta comunicação regular entre as equipes de desenvolvimento e operações para que as decisões de escalonamento reflitam as necessidades reais das aplicações.
Ao tratar right-sizing e autoscaling como processos interconectados, você alcança melhor utilização de recursos, estabilidade das aplicações e eficiência de custos.
Conteúdo relacionado: leia nosso guia sobre o Vertical Pod Autoscaler do Kubernetes
3. Revise o uso de recursos continuamente
O monitoramento contínuo do uso de recursos é vital para manter uma configuração de autoscaling eficiente. Alocações estáticas de recursos ficam rapidamente desatualizadas à medida que a demanda das aplicações muda, gerando ineficiências ou problemas de desempenho. Analisar regularmente os dados de uso permite fazer ajustes bem embasados nas requests dos workloads e nas configurações do autoscaler.
Ações principais:
- Use dashboards do Kubernetes e plataformas de monitoramento para acompanhar a utilização de CPU, memória e nós ao longo do tempo.
- Estabeleça um processo de revisão periódica, como auditorias mensais ou alertas automatizados para padrões de uso anômalos.
- Responda rapidamente a mudanças no consumo de recursos para evitar superprovisionamento e garantir que o cluster escale de forma adequada.
A revisão contínua sustenta uma abordagem proativa, reduzindo custos operacionais e mantendo um ambiente responsivo.
4. Projete grupos de nós para um bin packing eficiente
Bin packing eficiente significa alocar workloads nos nós de forma a maximizar a utilização de recursos e minimizar o desperdício. Ao projetar grupos de nós, é importante selecionar tipos e tamanhos de instância alinhados aos perfis dos seus workloads.
Ações principais:
- Evite nós grandes ou pequenos demais, que levam à fragmentação de recursos ou à subutilização.
- Agrupe workloads semelhantes para promover padrões de uso mais previsíveis e simplificar a configuração do autoscaler.
- Ajuste as configurações dos grupos de nós conforme suas aplicações evoluem.
- Monitore como os workloads são distribuídos e identifique oportunidades de consolidar ou dividir grupos de nós para um empacotamento melhor.
Um bin packing eficiente reduz o número total de nós necessários, otimiza o desempenho do autoscaler e diminui os custos de infraestrutura ao aproveitar ao máximo os recursos disponíveis.
5. Garanta que o HPA e o Cluster Autoscaler trabalhem juntos
O Horizontal Pod Autoscaler (HPA) e o Cluster Autoscaler precisam ser configurados para trabalhar em harmonia e garantir um escalonamento ideal. O HPA ajusta o número de pods com base em métricas dos workloads, enquanto o Cluster Autoscaler gerencia os nós subjacentes. Se o HPA escalar os pods além da capacidade disponível dos nós, o Cluster Autoscaler precisa conseguir adicionar nós com rapidez suficiente para acomodá-los. Configurações desalinhadas podem resultar em falhas no agendamento de pods ou em alocação desnecessária de recursos.
Ações principais:
- Coordene as políticas e os limites de escalonamento entre o HPA e o Cluster Autoscaler.
- Monitore a interação entre os dois, usando métricas e logs para identificar gargalos ou atrasos nas ações de escalonamento.
- Ajuste os targets do HPA e os parâmetros do Cluster Autoscaler para alcançar um escalonamento equilibrado e responsivo.
Garantir que os dois componentes trabalhem juntos reduz o tempo de inatividade, melhora a disponibilidade das aplicações e promove o uso eficiente dos recursos.
Maximize a eficiência do Cluster Autoscaler com a PerfectScale
Autoscalers de nós como o Cluster Autoscaler e o Karpenter aumentam e reduzem os nós conforme a demanda, melhorando a disponibilidade do cluster e reduzindo custos com ociosidade. Mas mesmo um autoscaler bem configurado encontra limites quando os workloads abaixo dele estão mal configurados: containers superprovisionados desperdiçam capacidade e forçam o autoscaler a adicionar mais nós do que o necessário, containers subprovisionados causam evictions de pods e pressão sobre os nós, e um bin packing ineficiente deixa recursos subutilizados enquanto dispara eventos de escalonamento desnecessários. A PerfectScale resolve esses problemas no nível do workload e do nó, para que sua configuração de autoscaling entregue de fato a eficiência que promete.
Principais recursos da PerfectScale para autoscaling no Kubernetes:
- Detecção proativa de erros de configuração: analisa continuamente os workloads para identificar e corrigir erros de configuração como CPU Request Not Set, Memory Request Not Set e Memory Limit Not Set, evitando evictions imprevisíveis, over-commitment de nós e autoscaling ineficiente.
- Right-sizing autônomo de workloads: ajusta instantaneamente os recursos dos workloads com base na utilização real e melhora o bin packing dos pods para aumentar a eficiência do autoscaling, sem interação manual.
- Visibilidade de autoscaling groups e node pools: oferece visibilidade dos custos e da utilização dos seus autoscaling groups e node pools, para que você identifique ineficiências em todo o cluster.
- Seleção ideal de tipos de nó: ajuda você a selecionar tipos de nó que melhoram a utilização, alcançam uma distribuição precisa de recursos e maximizam a eficiência de custos.
- Amplo suporte a autoscalers: funciona em conjunto com Karpenter, Cluster Autoscaler e Node Auto Provisioning, combinando otimização no nível dos nós com right-sizing no nível dos pods para um bin packing melhor e decisões de escalonamento mais rápidas.
Saiba mais sobre como maximizar o autoscaling de nós do Kubernetes com a PerfectScale