Um aumento inesperado de US$1.665/mês na AWS expôs anos de descompasso em infraestrutura, exigindo manutenção complexa. Entenda como evitar surpresas de custos e garantir a saúde do seu site.
Custo na Nuvem: Um Alerta Que Veio da Fatura
Imagine a cena: seu site empresarial está funcionando perfeitamente, sem alertas, sem reclamações de clientes, e os indicadores de CPU e memória parecem normais. De repente, a fatura da AWS chega com um aumento inesperado de US$1.665 por mês. Foi exatamente isso que aconteceu em um caso real, revelando uma complexa teia de descompassos na infraestrutura que passou despercebida por anos.
Inicialmente, o alerta veio de uma anomalia de custo relacionada ao suporte estendido do EKS (Elastic Kubernetes Service) e, dias depois, outra para o suporte estendido do RDS MySQL. O que parecia uma simples atualização de versão se transformou em uma manutenção de produção de seis horas, expondo a diferença crítica entre um sistema “funcionando” e um sistema “saudável e suportado”.
O Fim do Suporte Padrão: Quando a Data Custa Caro
A primeira anomalia de custo do EKS foi fácil de entender. A string de uso “EU-AmazonEKS-Hours:extendedSupport” indicava que o problema não era causado por mais tráfego ou recursos, mas sim por um evento de calendário. A versão do Kubernetes havia atingido o fim do suporte padrão da AWS. O cluster não mudou, mas a data sim, e o preço do control-plane do EKS subiu de aproximadamente US$0,10/hora para US$0,60/hora – um aumento de 6x.
O mesmo padrão se repetiu com o RDS MySQL, onde a string “EU-ExtendedSupport:Yr1-Yr2:MySQL8.0” indicava que uma versão simplesmente se tornou antiga o suficiente para a AWS começar a cobrar pelo suporte contínuo. A detecção de anomalias de custo da AWS fez seu trabalho ao sinalizar a cobrança, mas entender a causa real exigiu uma investigação aprofundada.
Descompasso de Versões: O Perigo Silencioso da Infraestrutura
A versão do Kubernetes (1.23) no control plane era simples de corrigir. O problema real estava nos add-ons do cluster, que não haviam sido atualizados. Enquanto o control plane recebia upgrades regulares, componentes como kube-proxy, vpc-cni, CoreDNS e cluster-autoscaler estavam várias versões atrás, alguns parecendo pertencer ao cluster original de 2023. O kube-proxy, por exemplo, estava sete versões menores do Kubernetes atrás do servidor da API.
Esses add-ons não eram gerenciados pelo EKS, mas sim por Deployments e DaemonSets comuns no kube-system. Isso significa que o EKS não era responsável por atualizá-los nem alertaria sobre o descompasso de versões. Essa é uma armadilha operacional comum: o upgrade do control plane é visível, mas o ciclo de vida dos add-ons é diferente, podendo levar a componentes críticos desatualizados.
Preparação é Tudo: O Que Quebraria Antes do Upgrade
Antes de qualquer atualização, o foco foi verificar a capacidade do cluster de sobreviver a uma substituição de nó. Essa etapa se mostrou mais valiosa do que o próprio upgrade.
- PodDisruptionBudgets (PDBs) Inadequados: Três componentes do Vertical Pod Autoscaler (VPA) tinham PDBs que impediam a remoção voluntária de pods, bloqueando o esvaziamento de nós. A solução foi flexibilizar o PDB, permitindo a remoção temporária de um pod durante a manutenção, ao invés de escalar o componente.
- Node Group Sem Margem de Manobra: O grupo de nós estava configurado com
minSize: 3,desiredSize: 3emaxSize: 3. Isso eliminava a margem de segurança para o Cluster Autoscaler e para a criação de nós de substituição durante um upgrade. Aumentar omaxSizepara 6 e configurarmaxUnavailable: 1na atualização do node group forneceu a capacidade de emergência necessária sem custos adicionais, já quemaxSizenão custa dinheiro, apenas nós em execução. - Falta de PDB na Aplicação Principal: O deployment da API principal não possuía PDB. Durante o esvaziamento de nós, não havia garantia de que muitos pods da API não desapareceriam simultaneamente. Um PDB inicial de
minAvailable: 5se mostrou problemático, pois o HPA (Horizontal Pod Autoscaler) poderia escalar para 3 pods, criando um impasse. A solução foimaxUnavailable: 1, que funciona em toda a faixa de escala do HPA.
Para aprender mais sobre como garantir que seu site esteja pronto para o futuro, confira nosso artigo sobre Deploy na Produção: O Que Acontece nos Bastidores e Por Que Seu Site Empresarial Precisa de um Processo Robusto.
O Desafio do Helm e a Importância da Fonte da Verdade
Ao criar PDBs manualmente com kubectl para uma aplicação gerenciada por Helm, surgiu um problema de propriedade. A próxima implantação do Helm falharia por não “possuir” o recurso. A solução foi transferir explicitamente a propriedade do PDB para o Helm usando kubectl label e kubectl annotate.
Este incidente reforçou uma lição crucial: mudanças de infraestrutura têm dois estados – o que existe no cluster e o que o sistema de registro (como Terraform ou Helm) pensa que deveria existir. Corrigir apenas o primeiro é temporário. É fundamental atualizar a fonte da verdade para que o reparo não tenha uma data de expiração, evitando que futuras reconciliações revertam as melhorias.
Otimização de Custos e Performance: Um Bug de Memória Oculto
Durante a preparação do upgrade, foi notado que todos os pods da API estavam sofrendo Out Of Memory (OOM) kills. A causa raiz era uma versão antiga do JVM rodando em um container com limite de memória. Essa JVM não tinha consciência confiável do cgroup v2, e via a memória disponível do host em vez do limite do container, alocando um heap excessivo.
A correção foi simples: definir um limite explícito de heap com -Xmx5g. Após a mudança, o uso de memória caiu drasticamente. Curiosamente, isso também revelou um problema de custo oculto: o HPA, que usava a memória como sinal de escalonamento, mantinha o deployment no máximo de réplicas. Com o uso de heap corrigido, o HPA escalou a API de sete para três pods, gerando economia significativa. Este é um exemplo de como infraestrutura, comportamento de runtime e gestão de custos se encontram.
Questões de performance e otimização são cruciais para a saúde de um site empresarial. Para entender mais sobre como o design impacta a performance, veja nosso post sobre UX no Site: 10 Fatos Comprovados por Dados que Geram Mais Receita e Retenção.
Adotando Add-ons Gerenciados pelo EKS: Uma Migração Cautelosa
Com o cluster seguro para drenagem, o próximo passo foi corrigir o descompasso dos add-ons. A abordagem foi converter os componentes auto-gerenciados para add-ons gerenciados pelo EKS, um componente por vez: kube-proxy, CoreDNS, VPC CNI e Cluster Autoscaler. Essa estratégia de um componente por vez é crucial para facilitar a depuração, caso algo dê errado.
A flag --resolve-conflicts OVERWRITE, usada para essa conversão, exige cautela. A AWS pode substituir a configuração local pelos padrões do add-on gerenciado. Portanto, é essencial inspecionar a configuração existente antes de aplicar a sobrescrita, garantindo que nenhuma personalização crítica seja perdida.
Perguntas frequentes
Por que meu site pode ter custos inesperados na nuvem?
Custos inesperados podem surgir do fim do suporte padrão para versões de software, como Kubernetes ou bancos de dados, levando a cobranças por suporte estendido. Descompassos na infraestrutura e configurações ineficientes também contribuem.
Como posso identificar problemas de infraestrutura antes que causem custos?
Implemente monitoramento de anomalias de custo, revise regularmente as versões de software e add-ons, e realize auditorias de configuração para garantir que a infraestrutura esteja alinhada com as melhores práticas e não tenha descompassos.
Qual a importância de um PodDisruptionBudget (PDB) para a estabilidade do site?
Um PDB garante que um número mínimo de pods esteja sempre disponível durante manutenções ou atualizações, evitando interrupções no serviço. Ele é crucial para a resiliência e a experiência do usuário do seu site empresarial.
O que significa “infraestrutura drift” e como afeta meu site?
“Infraestrutura drift” é o descompasso entre a configuração real da sua infraestrutura e o que está documentado ou esperado. Isso pode levar a vulnerabilidades de segurança, problemas de performance e custos inesperados, pois os sistemas podem não estar otimizados ou suportados.
Fonte: DEV Community
