Natura aumenta em 168% a economia com Spot ao adotar Karpenter no EKS

De oito clusters estáticos para um motor que escolhe a instância na hora

A Natura começou a rodar Kubernetes em 2016, ainda sem Amazon EKS, usando o kOps para administrar o control plane na mão. Entre 2018 e 2019 esse modelo acumulou 106 horas de indisponibilidade, número publicado pela própria equipe de Cloud/SRE da empresa em post no blog da AWS. O salto de 80% no número de microsserviços, puxado pela expansão digital do grupo, empurrou a companhia para o Amazon EKS, que tira o control plane das mãos do cliente.

O problema seguinte estava uma camada abaixo: o data plane. A Natura usava o Cluster Autoscaler (CAS) para decidir quando subir e derrubar nodes, e o CAS trabalha em cima de Amazon EC2 Auto Scaling groups (ASGs) fixos. Cada combinação de família de instância, Spot ou On-Demand, ARM ou GPU, vira um ASG separado, e cada ASG precisa de folga para não faltar capacidade na hora do pico. Hoje a Natura opera 8 clusters EKS em produção, com mais de 300 nodes e mais de 800 microsserviços, e foi nessa escala que o modelo de ASG estático começou a custar caro.

Por que o CAS deixa dinheiro na mesa

O Cluster Autoscaler só enxerga pods pendentes e pede mais máquinas do ASG configurado; ele não escolhe, em tempo real, qual tipo de instância é mais barato ou mais disponível naquele segundo. Na prática isso gera dois vazamentos de custo: provisionamento excessivo preventivo (sobra capacidade ociosa para não faltar no pico) e lentidão para reagir a picos reais de tráfego, porque o ASG escala dentro de uma lista fixa de tipos de instância.

A Natura trocou o CAS pelo Karpenter, projeto open-source que não trabalha com node groups. Em vez de escalar um ASG pré-definido, o Karpenter observa pods pendentes e chama diretamente a API EC2 Fleet para descobrir, no exato momento da requisição, quais tipos de instância estão disponíveis e a que preço. O resultado mais imediato foi velocidade: o provisionamento de um node caiu para 40 a 60 segundos, 70% mais rápido que no CAS.

A conta do Spot: de onde vem o salto de 168%

Rapidez de provisionamento é pré-requisito para usar Spot em escala: se a instância pode ser interrompida com pouco aviso, o cluster só aguenta depender dela se conseguir repor a capacidade quase na mesma velocidade. Foi essa folga que o Karpenter abriu. Com ele, a Natura migrou praticamente toda a carga de negócio para Amazon EC2 Spot Instances, mantendo em On-Demand só o node dedicado ao próprio controlador do Karpenter.

O post da AWS não divulga valores absolutos em dólar ou real: a métrica publicada é a variação percentual da economia com Spot em relação ao cenário anterior, de 168%. Para dimensionar o efeito importa menos o percentual isolado e mais a premissa por trás dele: hoje cerca de 97% dos workloads de negócio em produção e 100% dos ambientes não produtivos da Natura rodam em Spot. Antes do Karpenter, essa adoção era limitada pela rigidez dos ASGs, que travava a troca de tipo de instância quando um ficava escasso.

Um ponto técnico explica a diferença: os NodePools do Karpenter não fixam um tipo de instância, usam faixas. Veja a configuração publicada pela equipe da Natura, que restringe por família, vCPU e memória em vez de travar num único tipo:

nodepools:
- name: default-spot
  capacityType:
    operator: In
    values:
      - spot
  instanceCpu:
    operator: Lt
    values: ["17"]
  instanceMemory:
    operator: Gt
    values: ["8000"]
  instanceCategory:
    - r
    - t
  instanceSize:
    operator: NotIn
    values: [nano, micro, xlarge]

Quem mexe com capacidade Spot em Kubernetes reconhece o ganho: quanto mais larga a faixa de tipos elegíveis, maior o pool de capacidade Spot disponível e menor a chance de uma interrupção forçar queda para On-Demand. A Natura usa os operadores In, Lt (menor que) e Gt (maior que) justamente para manter essa faixa aberta, e o Karpenter decide, a cada NodeClaim, qual opção é a mais barata disponível naquele instante.

O preço de rodar em Spot: interrupção, drenagem e graceful shutdown

Rodar 97% da produção em Spot só funciona se a aplicação sobrevive à interrupção sem o cliente perceber. A Natura monta esse amortecimento em duas camadas. A primeira é uma fila Amazon SQS integrada a regras do Amazon EventBridge, que captura eventos de Spot Interruption Warning com até 2 minutos de antecedência; o Karpenter usa essa janela para provisionar o node substituto e começar a drenar o node que vai cair antes que o Amazon EC2 o interrompa de fato.

A segunda camada fica no próprio pod. A Natura configurou um preStop hook que espera 180 segundos antes de enviar o sinal de terminação, para dar tempo das requisições em andamento terminarem:

lifecycle:
  preStop:
    exec:
      command:
        - /bin/sh
        - -c
        - sleep 180

Esse é o tipo de ajuste que separa "Spot barato" de "Spot que explode em produção". Sem o aviso antecipado via SQS e sem o tempo de dreno no preStop, a mesma economia de 168% viria acompanhada de erro 5xx toda vez que uma instância fosse reclamada pela AWS.

O efeito colateral que ninguém pediu: concentração em uma única zona

Como o Karpenter otimiza custo, em algum momento ele concentrou nodes novos numa única Zona de Disponibilidade (AZ), por ser a mais barata e com mais capacidade disponível naquele instante. Em clusters menores isso esgotou os IPs da sub-rede daquela AZ e desbalanceou a topologia. A correção não foi no Karpenter, foi no deployment da aplicação, via topologySpreadConstraints:

topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: kubernetes.io/zone
    whenUnsatisfiable: ScheduleAnyway

É um lembrete útil para quem desenha NodePool: otimização de custo sem restrição de topologia pode transformar economia em risco de disponibilidade, porque concentra o blast radius numa AZ só.

Menos incidente também é economia: de 190 para 55 por mês

A parte do caso que fala de incidentes tem efeito direto na fatura, mesmo sem aparecer como linha separada na cobrança da AWS. Com o featureGate: NodeRepair ativado, o Karpenter passou a detectar e reciclar sozinho nodes presos em NotReady, sem esperar um humano acordar de madrugada. O número de alertas mensais caiu de aproximadamente 190 para 55, queda de 71%.

Outros dois ganhos de eficiência operacional reforçam a mesma lógica de FinOps, menos hora de engenheiro gasta por unidade de infraestrutura mantida:

• Upgrade de versão do Amazon EKS: de três janelas de manutenção de três horas cada (uma por grupo de clusters) para uma única janela de duas a três horas cobrindo todos os clusters, redução de cerca de 78% no tempo total.
• Atualização de AMI em ambientes não produtivos: com o alias al2023@latest no AMI Selector do Karpenter, o processo que levava de 2 a 3 horas de trabalho manual passou a acontecer de forma automática a cada nova imagem lançada pela AWS.

Desligar o que não precisa rodar à noite

Fora da produção, a Natura foi além do Spot e atacou o desperdício mais óbvio de FinOps: cluster ligado sem ninguém usando. A equipe construiu uma automação própria que, no horário programado, injeta cpu: "0" no limite de cada NodePool de ambientes de desenvolvimento e homologação. Com o teto de CPU zerado, o Karpenter é forçado a desprovisionar todas as máquinas daquele pool.

A automação também lida com um obstáculo clássico: o Pod Disruption Budget (PDB), que normalmente impede o Kubernetes de remover réplicas além de um mínimo definido. Como o objetivo aqui é esvaziar o cluster por completo fora do horário comercial, a ferramenta força o scale-down dos workloads protegidos por PDB antes do drain, algo que não faria sentido na operação normal do dia a dia.

O que ainda não fechou

A própria equipe da Natura lista o que falta. A política de graceful shutdown ainda está concentrada nas aplicações críticas; o resto do catálogo de mais de 800 microsserviços precisa do mesmo tratamento para não quebrar requisição quando o Karpenter decide reciclar um node. O ajuste fino de PDB também está restrito aos serviços mais críticos, e o Horizontal Pod Autoscaler (HPA) de boa parte dos projetos ainda não acompanha a velocidade de provisionamento que a infraestrutura já entrega em menos de 60 segundos.

Para quem decide onde rodar o workload

O caso da Natura interessa a quem lida com capacidade Spot em Kubernetes porque mostra a ordem certa das coisas: a economia de 168% não veio de configurar mais Spot, veio de resolver primeiro o provisionamento lento do CAS, motivo pelo qual muitos times evitam Spot em cargas críticas. Sem reposição rápida de capacidade, cada interrupção Spot vira incidente; com Karpenter, fila SQS, preStop e topologySpreadConstraints, a interrupção vira evento rotineiro.

Vale uma ressalva: nada disso elimina o custo de engenharia. Configurar fila de interrupção, calibrar preStop hook, revisar PDB aplicação por aplicação e escrever NodePool com faixas largas de instância é trabalho de SRE recorrente, não ajuste único. Quem não tem orçamento de engenharia para manter essa camada tende a sentir mais dor de interrupção do que ganho de economia ao migrar carga crítica para Spot sem essa fundação.

Fonte: AWS Brasil — Blog