Por que o HPA não escala, e como resolver
O HorizontalPodAutoscaler compara a métrica dos pods com a meta e ajusta o número de réplicas. Quando ele não escala, quase sempre é porque não está conseguindo ler a métrica, e ele diz isso nas condições e nos eventos.
1. Veja o que o HPA enxerga
A coluna TARGETS mostra a métrica atual e a meta. <unknown> quer dizer que ele não consegue ler a métrica:
kubectl get hpa -n <namespace>
kubectl describe hpa <nome> -n <namespace>O que as condições e os eventos dizem
- FailedGetResourceMetric ou "unable to get metrics": o metrics-server não está instalado ou não responde. Confira com kubectl top pods.
- "missing request for cpu" (ou memory): a utilização é calculada em cima do request, então todos os containers do pod precisam de requests do recurso medido.
- ScalingLimited com TooManyReplicas: chegou ao maxReplicas. Suba o limite ou reveja a meta.
- ScalingActive false: o HPA está desligado para esse alvo, por exemplo porque o Deployment está com zero réplicas.
2. Confira as métricas
kubectl top pods -n <namespace>
kubectl get apiservice v1beta1.metrics.k8s.ioEscala, mas não como você esperava
- Demora para reduzir: por padrão, o HPA espera 5 minutos de métrica baixa antes de tirar réplicas (janela de estabilização), para não oscilar.
- Não reage a variações pequenas: há uma tolerância de 10% em volta da meta.
- Escala, mas os pods ficam Pending: não há espaço nos nós. Falta o autoscaler do cluster ou ele chegou ao máximo de nós.
- Request alto demais faz a utilização parecer baixa, e o HPA nunca escala; request baixo demais faz escalar cedo demais.
Sem terminal, no Kubepier
No Kubepier, a lista de Horizontal Pod Autoscalers mostra as métricas e as metas de cada um, eventos de aviso como FailedGetResourceMetric sobem para o topo e o consumo por namespace fica ao lado, de qualquer cluster, no navegador ou no celular.