O Helm chart do Cluster Autoscaler é uma forma de instalar o Cluster Autoscaler do Kubernetes, que adiciona worker nodes quando seus pods não podem ser agendados e remove nós quando eles não são mais necessários. Você pode instalá-lo com um único comando helm install, mas duas coisas têm grande impacto no seu bom funcionamento: as configurações que você define e os requests de recursos dos seus pods.
Este guia cobre os dois pontos, além de explicar como o Cluster Autoscaler toma decisões de escalonamento. Você vai aprender como o Cluster Autoscaler decide quando adicionar ou remover nós, qual chart instalar, como instalar e verificar a instalação no EKS, AKS e GKE, quais valores do Helm controlam seu comportamento, como ajustá-lo para clusters grandes e como resolver problemas comuns de escalonamento.
O que é o Helm chart do Cluster Autoscaler?
O Cluster Autoscaler altera o número de nós do seu cluster com base no que os pods precisam. Ele adiciona nós quando os pods não podem ser agendados por falta de capacidade e remove nós que não são mais necessários quando seus pods podem rodar em outros nós.
Ele faz isso alterando o tamanho dos grupos de nós do seu provedor de nuvem, como os Auto Scaling Groups (ASGs) da AWS, os Virtual Machine Scale Sets (VMSS) do Azure ou os Managed Instance Groups (MIGs) do Google Compute Engine.
O Helm chart empacota o Deployment do Cluster Autoscaler, suas permissões RBAC e a configuração em uma única instalação. Isso facilita instalar, gerenciar e atualizar. O Cluster Autoscaler escala nós, enquanto o HPA e o KEDA escalam pods.
Como o Cluster Autoscaler decide adicionar e remover nós?
Estes são os principais fatores que o Cluster Autoscaler usa para decidir quando adicionar ou remover nós:
Pods pendentes acionam o scale-up
A cada 10 segundos, com base na configuração --scan-interval, o autoscaler procura pods presos em Pending porque não cabem nos nós existentes. Ele verifica se um novo nó de cada grupo de nós poderia rodar esses pods, escolhe um grupo adequado e aumenta o tamanho desejado do grupo para que o provedor de nuvem adicione um nó. Se não houver pods não agendáveis, o Cluster Autoscaler não adiciona nós.
Baixa utilização e um tempo de espera acionam o scale-down
Quando não há necessidade de adicionar nós, o autoscaler verifica se algum nó pode ser removido. Um nó vira candidato quando os requests de CPU e memória dos seus pods ficam abaixo do --scale-down-utilization-threshold, cujo padrão é 0,5 (50%). O nó precisa permanecer subutilizado pelo tempo definido em --scale-down-unneeded-time, cujo padrão é 10 minutos. O autoscaler também espera após um scale-up antes de remover nós, com base em --scale-down-delay-after-add, cujo padrão também é 10 minutos. Por isso o scale-down costuma ser mais lento que o scale-up.
Grupos de nós e expanders decidem de onde vêm os novos nós
O autoscaler precisa saber quais grupos de nós deve gerenciar. Ele pode descobri-los automaticamente ou usar uma lista explícita. Se vários grupos de nós puderem rodar os pods pendentes, a configuração --expander decide qual grupo expandir. As opções são random, most-pods, least-waste, price e priority.
Os requests de recursos guiam as decisões de escalonamento
Este é um dos pontos mais importantes de entender. O Cluster Autoscaler usa os requests de recursos dos pods, não o uso real de CPU e memória. Ele adiciona nós quando os recursos solicitados não cabem e considera um nó subutilizado com base nos requests dos seus pods. Por exemplo, se os pods solicitam 80% da capacidade de um nó mas usam apenas 20%, o autoscaler ainda enxerga o nó como 80% utilizado e pode não removê-lo. Requests superdimensionados podem, portanto, manter nós extras rodando e aumentar seus custos de nuvem.
Qual chart do Cluster Autoscaler instalar?
Para novas instalações, use o chart oficial autoscaler/cluster-autoscaler do repositório kubernetes/autoscaler.
Você ainda pode encontrar os charts antigos stable/aws-cluster-autoscaler e stable/cluster-autoscaler. Eles estão descontinuados e não recebem mais manutenção, então evite-os.
O Helm não é a única opção. Serviços gerenciados de Kubernetes podem oferecer o Cluster Autoscaler por meio de suas próprias ferramentas, e algumas equipes usam o Terraform para gerenciá-lo. A escolha certa depende de como você gerencia o seu cluster.
Pré-requisitos e compatibilidade de versões
Antes de instalar, estes são os dois pontos a verificar:
Alinhe a versão do Cluster Autoscaler com a versão do Kubernetes
Você deve usar o Cluster Autoscaler v1.30.x com o Kubernetes 1.30, v1.31.x com o Kubernetes 1.31 e assim por diante. O autoscaler usa sua própria lógica de agendamento para verificar se um pod cabe em um novo nó, então usar uma versão incompatível pode levar a decisões de escalonamento incorretas. Verifique a tag de imagem padrão do chart e fixe-a na versão correta, se necessário.
Dê ao Cluster Autoscaler acesso ao seu provedor de nuvem
O autoscaler precisa de permissão para alterar o tamanho dos seus grupos de nós e precisa saber quais grupos ele gerencia. Na AWS, isso significa as permissões de IAM necessárias e Auto Scaling Groups (ASGs) com as tags corretas. No Azure e no GCE, você precisa das permissões equivalentes e de VM Scale Sets (VMSS) ou Managed Instance Groups (MIGs) configurados corretamente.
Certifique-se de que essas permissões e configurações de grupos de nós estão corretas antes de instalar. O chart pode iniciar com sucesso mesmo quando elas estão erradas, mas o Cluster Autoscaler não conseguirá escalonar os nós.
Instalando o chart em um cluster em execução
Primeiro, adicione o repositório oficial:
helm repo add autoscaler https://kubernetes.github.io/autoscalerhelm repo updateAntes de instalar, você precisa informar ao Cluster Autoscaler quais grupos de nós ele deve gerenciar. A configuração depende do seu provedor de nuvem.
No AKS e no GKE gerenciados, o autoscaling de nós já está disponível como recurso nativo, habilitado no nível do node pool, então normalmente você não precisa instalar este Helm chart neles. O chart é útil principalmente para o Amazon EKS e clusters autogerenciados.
Instalando no EKS
No EKS, a descoberta automática é a abordagem mais simples. Primeiro, aplique a cada Auto Scaling Group (ASG) que o Cluster Autoscaler deve gerenciar as tags k8s.io/cluster-autoscaler/enabled e k8s.io/cluster-autoscaler/<your-cluster-name>.
Depois, instale o chart:
helm install cluster-autoscaler autoscaler/cluster-autoscaler \ --namespace kube-system \ --set cloudProvider=aws \ --set autoDiscovery.clusterName=<your-cluster-name> \ --set awsRegion=<your-region>Instalando em Azure ou GCE autogerenciados
Para um cluster autogerenciado no Azure ou no GCE, defina cloudProvider=azure ou cloudProvider=gce e informe os detalhes dos scale sets ou instance groups que o Cluster Autoscaler deve gerenciar.
As configurações exatas variam por provedor de nuvem, mas o setup básico é o mesmo: especifique o provedor de nuvem, os grupos de nós e as credenciais ou identidade que o Cluster Autoscaler deve usar.
Após instalar, verifique se o pod do Cluster Autoscaler está em execução:
kubectl get pods -n kube-system -l app.kubernetes.io/instance=cluster-autoscalerEm seguida, verifique seu status:
kubectl describe configmap cluster-autoscaler-status -n kube-systemO ConfigMap de status mostra o tamanho de cada grupo de nós e a atividade recente de scale-up ou scale-down. Isso dá uma visão rápida para saber se o Cluster Autoscaler está rodando e tomando decisões de escalonamento.
Valores do Helm que alteram o comportamento do autoscaler
Estes são os valores importantes:
cloudProvider e autoDiscovery
Eles informam ao Cluster Autoscaler qual provedor de nuvem você usa e como encontrar os grupos de nós que ele deve gerenciar. Se estiverem errados, o autoscaler não tem grupos de nós para escalonar.
Anotações da service account para acesso à nuvem
Você pode dar ao Cluster Autoscaler suas próprias permissões de nuvem por meio da service account dele, em vez de dar permissões amplas a todos os nós. No EKS, isso costuma ser feito com IAM Roles for Service Accounts (IRSA). No Azure e no GCE, é possível usar Workload Identity. As anotações da service account são configuradas com rbac.serviceAccount.annotations.
extraArgs para o comportamento de escalonamento
Você usa extraArgs para definir opções do Cluster Autoscaler como scan-interval, scale-down-utilization-threshold, scale-down-unneeded-time e expander. Também pode usar expendable-pods-priority-cutoff para definir a prioridade abaixo da qual os pods podem ser tratados como descartáveis. Essas configurações controlam a frequência com que o autoscaler verifica o cluster e como ele escolhe os nós a adicionar ou remover.
Número de réplicas, eleição de líder e recursos
Para alta disponibilidade, você pode rodar mais de uma réplica. O Cluster Autoscaler usa eleição de líder, então apenas uma réplica fica ativa por vez enquanto as outras ficam prontas para assumir. Defina também requests e limits de CPU e memória para o autoscaler. Clusters grandes podem precisar de mais memória, porque o autoscaler mantém o estado do cluster em memória.
Você pode definir esses valores em um arquivo values.yaml e instalar o chart com -f:
cloudProvider: awsautoDiscovery: clusterName: my-clusterawsRegion: us-east-1replicaCount: 2extraArgs: scan-interval: 10s scale-down-utilization-threshold: "0.5" expander: least-waste balance-similar-node-groups: "true"resources: requests: cpu: 100m memory: 300Mi limits: cpu: 200m memory: 500MiAjustando o chart para clusters grandes ou multi-tenant
Clusters grandes precisam de ajustes extras porque o Cluster Autoscaler tem mais pods, nós e grupos de nós para verificar a cada varredura. Algumas configurações e padrões ajudam a mantê-lo saudável à medida que o cluster cresce:
Reduza o número de grupos de nós
Quanto mais grupos de nós o autoscaler gerencia, mais trabalho ele faz a cada varredura. Sempre que possível, mantenha um número menor de grupos de nós e use tags de descoberta automática para incluir apenas os grupos que precisam de autoscaling.
Use sharding para clusters muito grandes
Você pode rodar várias instâncias do Cluster Autoscaler, cada uma gerenciando um conjunto diferente de grupos de nós. Isso distribui o trabalho entre várias instâncias do autoscaler. A contrapartida é que essas instâncias não se coordenam entre si, então duas delas podem responder ao mesmo pod pendente e adicionar temporariamente mais nós do que o necessário. Esses nós extras podem ser removidos depois durante o scale-down.
Use nós Spot com o expander priority
Você pode combinar grupos de nós Spot com o expander priority em clusters focados em custo. Isso permite que o autoscaler priorize a capacidade Spot, de menor custo, e recorra a nós on-demand quando necessário.
Use overprovisioning para escalonar mais rápido
O overprovisioning usa pods de baixa prioridade como placeholders para reservar capacidade extra no cluster. Quando os workloads reais chegam, esses pods placeholder são removidos para abrir espaço enquanto o autoscaler adiciona novos nós.
Escale grupos de nós a partir de zero
Um grupo de nós pode ser reduzido a zero quando não está em uso. Isso é especialmente útil para grupos de nós com GPUs, que são caros. No EKS, garanta que o grupo de nós tenha os labels e taints necessários nas tags do autoscaler, para que o Cluster Autoscaler saiba o que os nós podem oferecer mesmo quando o grupo tem zero nós.
Diagnosticando uma instalação que não está escalonando
Quando o Cluster Autoscaler não está escalonando como esperado, o ConfigMap de status e os logs do pod são os melhores pontos de partida. Estes são os casos mais comuns:
Pods ficam em Pending e nenhum nó é adicionado
Comece com kubectl describe pod <pod-name> e verifique os eventos do pod. Depois, verifique os logs do Cluster Autoscaler. As causas comuns incluem o grupo de nós já estar no tamanho máximo, nenhum grupo de nós ter capacidade suficiente para os requests de recursos do pod, ou o node selector ou a afinidade do pod não corresponder a nenhum grupo de nós disponível. Permissões de nuvem ou tags de grupos de nós ausentes também podem impedir que o autoscaler encontre ou altere o grupo de nós.
Nós permanecem subutilizados e não são removidos
O Cluster Autoscaler ignora alguns nós por padrão. Por exemplo, ele ignora nós que rodam pods do kube-system quando --skip-nodes-with-system-pods está habilitado e nós com pods que usam armazenamento local quando --skip-nodes-with-local-storage está habilitado. Ele também aguarda durante o tempo de espera do scale-down. Mais importante: lembre-se de que o Cluster Autoscaler usa requests de recursos, não o uso real. Se os requests mantiverem um nó acima do limite de utilização, o nó não se tornará candidato à remoção mesmo quando o uso real de CPU e memória for baixo.
Anotações e PodDisruptionBudgets bloqueiam a remoção de nós
O Cluster Autoscaler não removerá um nó se isso violar um PodDisruptionBudget (PDB). Ele também ignora pods com cluster-autoscaler.kubernetes.io/safe-to-evict: "false" e nós com a anotação scale-down-disabled. Essas configurações protegem os workloads contra despejos indesejados, mas uma configuração antiga ou desnecessária pode manter um nó rodando por mais tempo do que o esperado. Verifique kubectl describe configmap cluster-autoscaler-status -n kube-system para ver quais nós não podem ser removidos e por quê.
Ferramentas que funcionam junto com o Cluster Autoscaler
O Cluster Autoscaler gerencia o número de nós, mas as ferramentas a seguir podem ajudar no dimensionamento de pods e no provisionamento de nós.
PerfectScale
O Cluster Autoscaler toma decisões de escalonamento com base nos requests de recursos dos pods, não no uso real de CPU e memória. Se os requests forem altos demais, ele pode adicionar nós desnecessários e manter nós que poderiam ser removidos. O PerfectScale monitora o uso real dos workloads e fornece recomendações automatizadas de right-sizing para aproximar os requests de CPU e memória do uso real. Isso ajuda o Cluster Autoscaler a tomar decisões de escalonamento melhores. Você pode experimentar ou agendar uma sessão técnica.
Vertical Pod Autoscaler (VPA) e Goldilocks
O VPA ajusta os requests de recursos dos pods com base no uso observado. O Goldilocks fornece um dashboard para visualizar as recomendações do VPA. Ambos podem ajudar a manter os requests de recursos mais próximos do uso real, o que dá ao Cluster Autoscaler informações melhores para suas decisões de escalonamento.
Karpenter
O Karpenter adota uma abordagem diferente para o escalonamento de nós. Em vez de redimensionar grupos de nós fixos, ele pode provisionar nós com base nos requisitos dos pods pendentes.
Boas práticas para rodar o Cluster Autoscaler em produção
Estas são as práticas que podem ajudar a manter o autoscaling de nós eficiente e seguro:
1. Faça right-sizing dos requests dos pods antes de ajustar as configurações do autoscaler
O Cluster Autoscaler toma suas decisões com base nos requests de recursos dos pods, então requests precisos são mais importantes do que alterar as configurações do autoscaler. Os requests de recursos devem ser corrigidos primeiro; depois, ajuste os timers e expanders.
2. Mantenha os grupos de nós semelhantes em CPU, memória e zona de disponibilidade
Espera-se que os nós dentro de um mesmo grupo sejam semelhantes. Tipos de instância ou zonas de disponibilidade diferentes podem tornar a simulação de agendamento do autoscaler menos precisa. Grupos de nós semelhantes podem ser balanceados com balance-similar-node-groups.
3. Defina PodDisruptionBudgets para workloads que não devem ser interrompidos
Um PodDisruptionBudget (PDB) define quantos pods podem ficar indisponíveis ao mesmo tempo. Isso ajuda o Cluster Autoscaler a remover nós mantendo réplicas suficientes disponíveis para o workload.
4. Fixe a versão do chart e teste as atualizações
A versão do Cluster Autoscaler deve corresponder à versão do seu Kubernetes. Um upgrade do Kubernetes deve, portanto, ser testado com a versão correspondente do autoscaler antes de a mudança chegar à produção.
5. Exporte as métricas do autoscaler para o Prometheus e crie alertas para falhas de scale-up
O Cluster Autoscaler expõe métricas do Prometheus que mostram a atividade de escalonamento e as falhas. Alertas para falhas de scale-up e pods que permanecem em Pending podem ajudar a identificar problemas antes que afetem os workloads por muito tempo.
6. Revise os limites de scale-down em relação à economia real de custos
Um scale-down agressivo pode reduzir custos, mas workloads com picos repentinos de tráfego podem escalar para cima e para baixo com frequência demais. O scale-down-utilization-threshold e os timers de scale-down podem ser ajustados para os seus padrões reais de tráfego, em vez de serem calibrados apenas para reduzir o número de nós.