Como reduzimos em 47% a fatura de Kubernetes de um cliente com instâncias Spot

Um cliente SaaS europeu veio ter connosco com um problema conhecido: a fatura da AWS tinha passado de $15K para $38K por mês em 18 meses, enquanto a base de utilizadores apenas duplicara. O Kubernetes tornava fácil escalar — e fácil desperdiçar dinheiro. Eis exatamente como baixámos a fatura para $20K.

O ponto de partida

O cliente tinha 3 clusters EKS: produção, staging e desenvolvimento. Os três corriam 24/7 em instâncias on-demand m5.2xlarge. Principais conclusões da nossa auditoria inicial:

• Utilização média de CPU em todos os nós: 18%
• Utilização média de memória: 34%
• Clusters de staging e desenvolvimento a correr 24/7 apesar de só serem usados em horário laboral (9 AM - 7 PM CET)
• Nenhum autoscaling configurado — número fixo de nós definido há meses
• Resource requests sobredimensionados — a maioria dos pods pedia 2-4x o consumo real
• 23 volumes EBS órfãos de PVC antigos — $420/mês por nada

Fase 1: right-sizing (semana 1-2)

Implementámos o Vertical Pod Autoscaler em modo de recomendação em todos os namespaces e recolhemos dados durante 14 dias. Os resultados foram impressionantes:

Um serviço de API em Java pedia 2 CPU e 4Gi de memória, mas usava de forma consistente 400m de CPU e 800Mi de memória — 80% de desperdício num único deployment com 6 réplicas. Multiplica isso por 47 serviços.

Ajustámos os resource requests e limits com base na utilização P95, com uma margem de 30%. Só isto nos permitiu reduzir os worker nodes de produção de 24 para 14.

Poupança: $5,200/mês

Fase 2: instâncias Spot para cargas de trabalho stateless (semana 3)

Analisámos que cargas de trabalho eram compatíveis com spot: - Serviços de API stateless (12 serviços, 34 pods) — totalmente compatíveis com spot - Servidores web de frontend — compatíveis com spot - Workers em segundo plano e consumidores de filas — compatíveis com spot - Bases de dados e serviços stateful — têm de ficar em on-demand

Configurámos pools de instâncias mistas com o Karpenter (em substituição do Cluster Autoscaler predefinido). O Karpenter escolhe entre 15+ tipos de instância em 3 AZ, maximizando a disponibilidade de spot e minimizando as interrupções.

As regras de node affinity garantem que as cargas de trabalho stateful (PostgreSQL, Redis, Elasticsearch) só são agendadas em nós on-demand, enquanto os serviços stateless preferem nós spot.

O preço das instâncias spot para a nossa combinação foi, em média, 68% mais barato do que on-demand.

Poupança: $7,400/mês

Fase 3: agendar os ambientes de não produção (semana 3)

Os clusters de staging e desenvolvimento não precisam de estar a correr às 3 AM. Implementámos:

• Cluster de desenvolvimento: escala para zero nós fora do horário 8 AM - 8 PM CET, de segunda a sexta
• Cluster de staging: escala para o mínimo (2 nós) fora do horário laboral e para a capacidade total durante as execuções de CI/CD

Combinando o escalamento de nós do Karpenter com CronJobs que fazem cordon/drain dos nós, reduzimos a computação de não produção em 65%.

Poupança: $3,800/mês

Fase 4: limpeza e otimização do armazenamento (semana 4)

• Eliminámos 23 volumes EBS órfãos ($420/mês)
• Migrámos o armazenamento de logs de EBS gp3 para S3 com políticas de ciclo de vida ($280/mês de poupança)
• Mudámos as bases de dados de desenvolvimento da storage class io2 para gp3 ($190/mês de poupança)
• Implementámos a limpeza automática de PVC ao eliminar um namespace

Poupança: $890/mês

Fase 5: preços baseados em compromisso (semana 5)

Ao fim de 4 semanas de dados de utilização já otimizada, tínhamos uma visibilidade clara da computação de base que ia estar sempre a correr. Comprámos:

• Um Compute Savings Plan de 1 ano que cobria 70% da base on-demand restante
• Isto cobria as cargas de trabalho stateful de produção e a capacidade mínima de staging

Poupança: $1,100/mês

Resumo dos resultados

| Categoria | Poupança mensal | |----------|----------------| | Right-sizing | $5,200 | | Instâncias Spot | $7,400 | | Agendamento de não produção | $3,800 | | Limpeza de armazenamento | $890 | | Savings Plans | $1,100 | | Total | $18,390 |

Fatura mensal final: $19,610 (face a $38,000) Redução: 47%

O que NÃO fizemos

Importa sublinhar que não: - Alterámos qualquer código da aplicação - Reduzimos o número de réplicas dos serviços em produção - Comprometemos a disponibilidade nem a recuperação de desastres - Introduzimos novos pontos únicos de falha - Tivemos qualquer indisponibilidade durante a otimização

A aplicação continuou a servir o mesmo tráfego com a mesma latência. Os utilizadores não notaram nada. O CFO notou muito.

Lições aprendidas

1. 1Começa pela visibilidade — Não consegues otimizar o que não medes. O Kubecost ou o OpenCost devem ser a tua primeira implementação.
2. 2Primeiro, right-sizing — É a otimização mais segura e com maior ROI. Faz isto antes de tudo o resto.
3. 3O spot está pronto para produção — Com pod disruption budgets bem configurados, várias réplicas e pools de instâncias mistas, as interrupções de spot são invisíveis para os utilizadores.
4. 4O desperdício fora de produção é enorme — Os ambientes de dev e staging representam muitas vezes 30-40% da despesa cloud, mas ficam sem uso 70% do tempo.
5. 5Compromete-te no fim — Só compres reservas depois de teres otimizado. Caso contrário, estás a fixar o desperdício.

Conclusão

A otimização de custos cloud não é poupar à custa da qualidade — é eliminar desperdício. Cada dólar gasto em computação ociosa é um dólar que não vai para desenvolvimento de produto, recrutamento ou aquisição de clientes. As ferramentas e técnicas deste caso de estudo aplicam-se a qualquer ambiente Kubernetes a correr em cloud pública, e o intervalo de poupança de 30-50% é alcançável de forma consistente.