Por que os autoscalers do Kubernetes brigam entre si, segundo Nikhil Kurup

O argumento de Nikhil Kurup parte de um exemplo concreto: o checkout-api tem no Helm replicas: 3, cpu: 1000m e memory: 2Gi. No cluster, o HPA escalou para 11 réplicas por CPU, o VPA recomenda cpu: 350m e memory: 3.1Gi, o KEDA pede 24 réplicas por lag no Kafka e o Karpenter subiu dois nodes dimensionados pelos requests declarados. Cinco fontes, cinco respostas.

O problema, segundo ele, é que HPA, VPA, KEDA e Karpenter rodam em loops de reconciliação independentes e mexem nos mesmos campos: .spec.replicas, .resources.requests e o node pool. Ele lista quatro modos de falha. Na death spiral, o VPA reduz os requests (o denominador da conta do HPA), o HPA escala para fora, o uso por pod cai e o VPA reduz de novo. Com KEDA e HPA no mesmo sub-recurso /scale, workers com muito I/O e pouca CPU são reduzidos pelo HPA enquanto a fila cresce. Com GitOps, o Argo CD marca o HPA como OutOfSync e, com auto-sync, devolve o baseline no pico. Já o Karpenter provisiona para demanda fantasma: o texto cita CPU média de cluster perto de 8% em frotas de produção.

A proposta é manter esses controllers como atuadores e adicionar uma camada central de decisão, preditiva e com decisões explicáveis, que otimize réplicas, requests, limits e thresholds contra SLOs de latência e custo.

Para quem opera plataforma, a leitura prática é auditar quem escreve em cada campo do workload. Combinar VPA e HPA no mesmo recurso, ou KEDA e HPA no mesmo deployment, merece revisão. O mesmo vale para o ignoreDifferences no GitOps, que resolve o ciclo de sync, mas tira do Git a fonte da verdade sobre réplicas. O texto é uma tese de opinião, não um produto pronto.