Todas as equipas de infraestrutura acabam por enfrentar a mesma pergunta: porque é que a nossa fatura de Kubernetes é tão alta? A resposta é quase sempre a mesma — sobreaprovisionamento. Os engenheiros pedem mais CPU e memória do que as cargas de trabalho realmente precisam, os autoscalers estão configurados de forma demasiado agressiva e ninguém tem um processo sistemático de right-sizing.
O resultado são clusters a funcionar com 15-25% de utilização real enquanto pagas por 100%.
A Site Reliability Engineering dá-te o enquadramento para resolver isto sem partir nada. As práticas SRE ligam diretamente a otimização de custos à fiabilidade — por isso não estás a cortar custos às cegas, estás a eliminar desperdício mantendo os níveis de serviço de que os teus utilizadores dependem.
Eis sete práticas SRE que reduzem sistematicamente os custos de Kubernetes.
1. Faz o right-sizing dos resource requests
A maior fonte de desperdício de custos em Kubernetes são resource requests incorretos. Os engenheiros definem os requests de CPU e memória por palpite e nunca mais os revisitam. Um contentor que pede 2 núcleos de CPU mas usa em média 200 milicores desperdiça 90% dos recursos que lhe foram atribuídos.
Como resolver:
Analisa a utilização real de recursos numa janela de 14 dias. Compara a utilização P95 com os requests atuais. Qualquer contentor em que o request seja mais de 2x a utilização P95 é candidato a right-sizing.
A fórmula é simples: define os requests de CPU na utilização P95 mais uma margem de 20%. Define os requests de memória na utilização máxima observada mais uma margem de 15% (a memória é menos elástica do que a CPU — ficar abaixo do necessário causa OOMKills).
Ferramentas como o Vertical Pod Autoscaler (VPA) do Kubernetes em modo de recomendação podem automatizar esta análise em todo o teu cluster. Plataformas como o SRExpert disponibilizam analítica de recursos ao nível da carga de trabalho que apresenta recomendações de otimização em vários clusters em simultâneo — mostrando-te exatamente que deployments estão sobreaprovisionados e em quanto.
Impacto esperado: redução de 30-50% nos recursos pedidos, o que se traduz diretamente em menos nós necessários.
2. Usa o Cluster Autoscaler com nós do tamanho certo
O Cluster Autoscaler acrescenta e remove nós com base nos pods pendentes, mas só funciona bem se os teus node pools tiverem o tamanho certo. Usar um único tipo de nó (p. ex., m5.2xlarge para tudo) garante quase sempre desperdício.
Como resolver:
Cria vários node pools otimizados para diferentes tipos de carga de trabalho. As cargas intensivas em CPU ficam em instâncias otimizadas para computação. As bases de dados com muita memória ficam em instâncias otimizadas para memória. Os jobs batch ficam em instâncias spot ou preemptible.
Configura o Cluster Autoscaler com limiares de redução adequados. Por omissão, reduz os nós que estão abaixo de 50% de utilização durante 10 minutos. Para otimizar custos, podes baixar isto com segurança para 40% de utilização e 5 minutos nas cargas de trabalho não críticas.
Ativa a flag --balance-similar-node-groups para distribuir os pods de forma equilibrada pelas zonas de disponibilidade, evitando que uma zona tenha nós quase vazios.
Impacto esperado: redução de 15-25% nos custos dos nós graças a um melhor bin-packing e a uma melhor correspondência dos tipos de instância.
3. Define e aplica quotas de recursos
Sem quotas de recursos, qualquer namespace pode consumir recursos ilimitados do cluster. Um deployment descontrolado de uma equipa pode inflacionar a tua fatura de cloud em milhares de dólares antes de alguém dar por isso.
Como resolver:
Define ResourceQuotas em todos os namespaces. Estabelece limites para o total de requests de CPU, o total de requests de memória e o número de pods. Baseia estas quotas nas necessidades reais de cada equipa mais uma margem de crescimento de 30%.
Implementa LimitRanges para definir requests e limits por omissão nos pods que não os especificam. Isto evita o padrão comum de implementar pods sem resource requests — o que faz com que o scheduler os trate como pods sem recursos quando, na verdade, consomem recursos significativos.
Usa uma plataforma de gestão unificada que disponibilize dashboards de quotas de recursos entre clusters. Isto dá-te visibilidade sobre que equipas se estão a aproximar das suas quotas e quais têm uma alocação significativa por usar que podia ser recuperada.
Impacto esperado: evita picos de custos descontrolados e cria responsabilização por equipa.
4. Tira partido das instâncias spot e preemptible
As instâncias spot custam 60-90% menos do que as instâncias on-demand. A contrapartida é que o fornecedor de cloud as pode recuperar com um aviso mínimo. Para cargas de trabalho stateless com a redundância adequada, esta contrapartida compensa quase sempre. Vê como cortámos 47% à fatura de Kubernetes de um cliente com instâncias spot.
Como resolver:
Identifica as cargas de trabalho que toleram interrupções: jobs batch, runners de CI/CD, ambientes de desenvolvimento, serviços web stateless com várias réplicas e pipelines de processamento de dados.
Usa node affinity e taints para agendar estas cargas de trabalho exclusivamente em nós spot. Corre as cargas críticas (bases de dados, serviços stateful, deployments com uma única réplica) em nós on-demand.
Implementa pod disruption budgets (PDBs) para garantir que as terminações de spot não deitam abaixo todas as réplicas em simultâneo. Um PDB com maxUnavailable: 1 garante que pelo menos N-1 réplicas continuam disponíveis durante a recuperação de instâncias spot.
Configura vários tipos de instância nos teus node pools de spot. A disponibilidade de spot varia consoante o tipo de instância — usar 5-10 tipos diferentes reduz drasticamente a frequência de interrupções.
Impacto esperado: redução de custos de 40-70% nas cargas de trabalho elegíveis, que tipicamente representam 30-50% do total de recursos do cluster.
5. Implementa políticas de escalamento automático
O Horizontal Pod Autoscaler (HPA) evita tanto o sobreaprovisionamento (réplicas a mais) como o subaprovisionamento (réplicas a menos), mas a maioria das equipas ou não o usa ou configura-o mal.
Como resolver:
Configura o HPA em todos os deployments stateless. Usa a utilização de CPU como métrica principal, com um objetivo de 65-75%. Isto deixa margem suficiente para picos de tráfego e evita réplicas ociosas.
Para um escalamento mais sofisticado, usa métricas personalizadas do Prometheus. Escala com base na taxa de pedidos, na profundidade da fila ou em métricas específicas do negócio, em vez da CPU em bruto. Um deployment que processa mensagens de uma fila deve escalar com base no comprimento da fila, não na utilização de CPU.
Configura janelas de estabilização adequadas. A estabilização por omissão para redução é de 5 minutos — aumenta-a para 10-15 minutos nas cargas de trabalho de produção para evitar oscilações rápidas de escalamento durante flutuações de tráfego.
As plataformas SRE com integração de monitorização podem analisar os teus padrões de escalamento e recomendar configurações ótimas de HPA com base nos padrões históricos de tráfego, eliminando os palpites na afinação do autoscaler.
Impacto esperado: redução de 20-35% no número médio de réplicas, mantendo os SLOs de tempo de resposta.
6. Agenda as cargas não críticas fora das horas de ponta
Os ambientes de desenvolvimento, os clusters de staging, os pipelines de CI/CD e o processamento batch não precisam de correr 24/7. Executá-los apenas em horário de expediente reduz o seu custo em 65%.
Como resolver:
Usa CronJobs ou schedulers externos para escalar para zero réplicas os namespaces que não são de produção fora do horário de expediente. Um CronJob simples que execute kubectl scale deployment --replicas=0 -n staging --all às 7 da tarde e volte a escalar às 8 da manhã poupa 13 horas de computação por dia.
Para os clusters de desenvolvimento, considera usar a capacidade de scale-to-zero do Cluster Autoscaler. Quando todos os deployments de desenvolvimento estão escalados para zero, o autoscaler remove por completo os nós subjacentes — não pagas nada até os programadores começarem o dia de trabalho.
Implementa políticas de agendamento ao nível do namespace que apliquem automaticamente estes padrões. As plataformas de operações podem automatizar isto com agendamento baseado em políticas que respeita as diferenças de fuso horário entre equipas distribuídas.
Impacto esperado: redução de custos de 50-65% nas cargas de trabalho que não são de produção.
7. Monitoriza as métricas de custo como SLIs
A SRE trata tudo como mensurável. O custo não deve ser diferente. Se não acompanhas a eficiência de custos como um Service Level Indicator, não a consegues otimizar de forma sistemática.
Como resolver:
Define SLIs de eficiência de custos: custo por pedido, custo por transação, custo por cliente ou custo por carga de trabalho. Acompanha-os ao longo do tempo, a par dos teus SLIs de fiabilidade.
Constrói dashboards de Grafana que mostrem as tendências de custos a par das métricas de desempenho. Quando o custo por pedido aumentar, investiga se isso se deve a alterações de tráfego, a desperdício de recursos ou a alterações de preço da infraestrutura.
Configura alertas de custos com o teu stack de monitorização. Se o custo de um namespace aumentar mais de 20% de uma semana para a outra sem um aumento correspondente de tráfego, dispara um alerta para investigação.
Usa plataformas que disponibilizem visibilidade de custos integrada a par da saúde das cargas de trabalho. As melhores ferramentas de gestão de Kubernetes correlacionam a utilização de recursos com a despesa real em cloud, para que vejas exatamente que deployments estão a provocar os aumentos de custos e tomes decisões de otimização baseadas em dados.
Impacto esperado: melhoria contínua. As equipas que acompanham as métricas de custos reduzem a despesa em 10-15% de trimestre para trimestre através de otimizações incrementais.
Juntar tudo
Estas sete práticas não são independentes — reforçam-se mutuamente. Fazer o right-sizing dos recursos significa menos nós. Menos nós com instâncias spot significa custos por nó drasticamente mais baixos. O escalamento automático evita o sobreaprovisionamento com pouco tráfego. O agendamento fora das horas de ponta elimina o desperdício durante as noites e os fins de semana. E os SLIs de custo garantem que as melhorias se mantêm.
Um ambiente Kubernetes típico que implementa as sete práticas reduz a despesa em cloud em 40-60% num trimestre.
A ideia-chave da SRE é que a otimização de custos não é um projeto pontual — é uma prática contínua. Os padrões de utilização de recursos mudam à medida que a tua aplicação evolui. São implementados novos serviços. Os padrões de tráfego mudam. Sem monitorização e otimização contínuas, os custos voltam a subir aos poucos.
Integra estas práticas na tua cultura SRE, mede-as de forma consistente e trata a eficiência de custos como uma preocupação de engenharia de primeira linha, a par da fiabilidade, da latência e da disponibilidade. A tua fatura de cloud — e o teu CFO — vão agradecer-te.
Queres ver as tuas oportunidades de otimização de custos em Kubernetes? O SRExpert disponibiliza analítica de recursos ao nível da carga de trabalho, recomendações de otimização e visibilidade de custos em todos os teus clusters. Experimenta grátis ou fala com a nossa equipa sobre uma avaliação de otimização de custos.