Otimização de Custos do Kubernetes: 8 Passos & 23 Ferramentas
Os clusters Kubernetes podem parecer completamente saudáveis enquanto a fatura sobe. O autoscaling está configurado, os painéis estão verdes e os gastos aumentam mesmo assim. Em uma pesquisa, 42% de 455 engenheiros de plataforma apontaram o custo como seu principal desafio de Kubernetes, enquanto 88% viram o custo total de propriedade aumentar ano após ano.1
Reunimos 68 estudos de caso de otimização de custos do Kubernetes e mapeamos cada caso de uso mencionado para cada fornecedor que o publicou:
Células mais escuras significam mais menções. Células em branco significam que a ferramenta não tem nenhum caso publicado para aquele caso de uso.
Continue rolando para ver o guia de 8 passos com exemplos reais para reduzir os gastos do cluster e a comparação da ferramenta de otimização de custos do Kubernetes.
1. Meça antes de mudar qualquer coisa
Todos os números no restante deste guia são um delta, e um delta precisa de um ponto de partida. Sem uma linha de base capturada antes da primeira mudança, não há como saber se o passo 1 funcionou, nem como atribuir as economias do passo 3 à consolidação e não ao rightsizing que a precedeu. Isso importa mais aqui do que na maioria dos trabalhos de engenharia, porque as seis ações reduzem a mesma fatura e suas economias não se somam. Liberar capacidade no passo 1 não gera nada na fatura até que o passo 3 remova os nós.
Meça quatro coisas:
- Solicitado versus utilizado de CPU e memória, por workload. A diferença é o seu backlog do passo 1, ordenado por tamanho.
- Custo por namespace e por workload. É isso que faz das cotas do passo 2 uma negociação em vez de uma imposição.
- Eficiência de bin packing, alocável versus solicitado por nó. O alvo do passo 3.
- Custo ocioso por hora do dia e dia da semana em não produção. Dimensiona o passo 5 antes de você construí-lo.
Meça ao longo de pelo menos um ciclo completo de negócios. Sete dias é o mínimo e trinta é melhor. A janela não é cautela processual. O passo 1 define os requests de memória no máximo observado, e um máximo observado é tão bom quanto a janela que o observou. Um máximo obtido em 48 horas perde um job em lote semanal e produz um OOMKill no domingo seguinte.
Ferramentas
- Alocação de custos: OpenCost, o projeto CNCF por trás do modelo de alocação, é o piso gratuito. O tier gratuito do Kubecost envolve o mesmo mecanismo em uma UI para até 250 núcleos.
- Utilização: O Prometheus com kube-state-metrics é o substrato. O Robusta KRR lê isso diretamente sem instalar nada no cluster.
- Gastos mais amplos: Onde o Kubernetes é uma parte de uma fatura que finanças também precisa explicar, CloudZero, Vantage e Finout ficam acima dessa camada em vez de substituí-la.
Ambas as ferramentas de custo atribuem por rótulo, então a rotulagem vem primeiro. Gastos sem rótulo são o motivo mais comum de uma linha de base se mostrar inútil três semanas depois.
Cada ação abaixo indica a recomendação, o método, a configuração e uma empresa que executou esse passo. Cada estudo de caso e cada estatística traz um link de fonte.
2. Defina cotas de namespace como barreiras de proteção
As economias diminuem à medida que as equipes implantam novos workloads sem requests especificados. Um LimitRange fornece requests padrão para contêineres que os omitem, e um ResourceQuota limita o que um namespace pode consumir em agregado.
Implante o LimitRange antes do ResourceQuota. Uma vez que uma quota restringe um recurso, qualquer pod sem um request para esse recurso é rejeitado na admissão, portanto a ordem inversa quebra as implantações.2
Cada load balancer é cobrado separadamente pelo provedor de nuvem, e volumes órfãos continuam a ser cobrados depois que seus pods desaparecem.
2. Dimensione corretamente requests de CPU e memória
Os requests determinam a contagem de nós, e a contagem de nós determina a fatura. A maioria dos clusters roda muito abaixo da capacidade pela qual paga, porque os requests foram estimados uma vez e nunca revisados. Uma análise de 23.000 clusters de produção na AWS, Azure e Google Cloud encontrou utilização média de CPU em 8%, memória em 20% e GPU em 5%. 3
Defina os requests de CPU próximos ao percentil 95 do uso observado. Defina os requests de memória no máximo observado em vez de um percentil, e defina o limite de memória igual ao request. Um percentil deixa o contêiner sem recursos durante o tráfego restante e, como o limite é igual ao request, essa falta chega como um OOMKill em vez de uma lentidão.
Omita o limite de CPU. O throttling de CPU degrada a latência sem matar o pod, e o request reserva o que o workload precisa.
O Vertical Pod Autoscaler no modo somente recomendação produz esses valores sem risco de produção.
Leia as recomendações com kubectl describe vpa payments-api e compare o valor alvo com o request atual.
Estudo de caso real: Tryg Insurance
A Tryg Insurance é a maior seguradora geral da região nórdica e roda Kubernetes na infraestrutura Oracle Cloud. Sua equipe de engenharia combinou o Horizontal Pod Autoscaler e o Vertical Pod Autoscaler para dimensionar corretamente workloads dinamicamente, mantendo os níveis de serviço, e reduziu os custos de nuvem do Kubernetes em 50% usando apenas autoscalers open-source, sem nenhuma plataforma de otimização comercial.4
4. Consolide nós com o Karpenter e escale workloads ociosos para zero
O rightsizing libera capacidade, mas essa capacidade fica em nós que continuam rodando até que algo os remova. O Karpenter provisiona instâncias em tempo e reempacota workloads em menos nós. O KEDA escala workloads orientados por fila até zero réplicas, algo que um Horizontal Pod Autoscaler padrão não consegue fazer.
Defina a política de consolidação como WhenEmptyOrUnderutilized. A alternativa, WhenEmpty, restringe a disrupção a nós que não possuem nenhum pod de workload, e esses raramente ocorrem sem intervenção. 5
Uma lista restrita de instâncias inviabiliza isso, porque o Karpenter não consegue encontrar outliers baratos e sua resiliência a spot cai. Você deve deixá-lo escolher entre famílias inteiras de instâncias.
Estudo de caso real: Adidas
A Adidas roda vários clusters Kubernetes no AWS EKS. Sua equipe de engenharia de plataforma adotou o Karpenter para provisionamento de nós, adicionou o KEDA para escalonamento orientado a eventos, criou automaticamente objetos do Vertical Pod Autoscaler por meio de políticas do Kyverno e usou o kube-downscaler para ambientes ociosos. Eles reduziram o custo de operação de seus clusters Kubernetes na AWS em até 50%, usando uma stack totalmente open-source.6
5. Prepare-se adequadamente antes de mover workloads para spot
As instâncias spot oferecem o maior desconto disponível e a aplicabilidade mais restrita. Nada deve ir para spot até que PodDisruptionBudgets, diversificação de instâncias, topology spread e tratamento de terminação estejam todos implementados.
Um PodDisruptionBudget que não deixa folga bloqueia toda disrupção voluntária, incluindo a consolidação do Karpenter, por isso os valores precisam de margem. 7
Estudo de caso real: Delivery Hero
A Delivery Hero opera 390 aplicações em 43 países, com cerca de 90% dos workloads rodando no AWS EKS. Sua equipe migrou para Spot Instances ao longo de aproximadamente seis meses, incorporando tratamento de terminação e um descheduler ao processo em vez de trocar os tipos de capacidade diretamente.
- Os custos de infraestrutura caíram cerca de 70%
- Os descontos de spot chegaram a até 90% em relação à precificação sob demanda
- A plataforma absorve picos de tráfego de 4 a 5 vezes o volume normal.8
6. Desligue a não produção em um cronograma
Os ambientes de desenvolvimento e staging carregam pouca ou nenhuma carga durante a noite e nos fins de semana. O desligamento programado é tecnicamente simples e politicamente incontestado, o que o torna a economia mais rápida de entregar e uma primeira ação útil onde mudanças mais difíceis precisarão de apoio depois.
Aplique o cronograma por padrão em namespaces de não produção e exija que as equipes optem explicitamente por sair. Uma política que exige ação para entrar alcança menos equipes do que uma que exige ação para sair.
A economia chega à fatura se a consolidação de nós estiver em execução, já que implantações reduzidas deixam nós vazios para trás.
Estudo de caso real: Bud Financial
A Bud Financial enriquece dados de transações financeiras para o setor de serviços financeiros e roda cerca de 25 clusters no Google Kubernetes Engine. Sua equipe usou pausa e retomada programadas para reduzir os nós do cluster durante a noite e nos fins de semana, juntamente com rebalanceamento diário.
- Os custos caíram 47% apenas com a mudança de cronograma
- O cronograma removeu 80 horas de operação do cluster por semana
- A utilização de recursos subiu acima de 90%.9
7. Migre workloads compatíveis para ARM
As instâncias baseadas em ARM alteram o preço unitário em vez de competir pela mesma capacidade ociosa das ações acima, então essas economias realmente se acumulam com as demais. Os bloqueadores serão dependências sem builds ARM64.
Os usuários devem escopar isso por workload e não em todo o parque, e criar imagens multiarquitetura antes de agendar qualquer coisa.
Estudo de caso real: Pinterest
O Pinterest migrou seu workload de web API para instâncias AWS Graviton rodando em ARM64, motivado tanto por redução de custos quanto de carbono.
- Os custos caíram 47%
- O consumo de computação caiu 38%
- As emissões de carbono caíram 62%.10
8. Quando o ajuste se esgotar, mude a arquitetura
As seis ações acima ajustam workloads dentro de clusters existentes. Uma vez esgotadas, ganhos adicionais exigem mudança arquitetural em vez de mais ajustes.
Dois resultados publicados marcam o limite prático. A InCred Finance reduziu gastos em 30% em clusters que sua equipe considerava otimizados11, e a Yotpo alcançou 30–40% executando 80% dos workloads em instâncias spot12. Além desse intervalo, o desperdício restante não está mais dentro dos clusters, mas no número de clusters. Cada um carrega uma cobrança de control plane e forma uma ilha de agendamento que o bin packing não consegue atravessar.
A multitenancy remove ambos os custos. Em vez de dedicar um cluster a cada cliente, equipe ou ambiente, clusters virtuais rodam em infraestrutura física compartilhada. Cada tenant recebe seu próprio servidor de API e control plane virtual enquanto os nós são agrupados. Isso elimina a cobrança de control plane por cluster e permite bin packing pelo pool de nós compartilhado em vez de dentro de propriedades isoladas.
yaml
bash
Dois mecanismos estão disponíveis. Namespaces são sempre mais baratos, então a escolha é feita pela separação que os tenants exigem, não pelo custo.
- Namespaces particionam um único cluster e não adicionam control plane próprio. São suficientes quando os tenants confiam uns nos outros e podem compartilhar um servidor de API e um conjunto de CRDs.
- Clusters virtuais dão a cada tenant seu próprio servidor de API, rodando como um workload no host. Esse custo se justifica em dois casos: tenants que precisam de recursos com escopo de cluster próprios e requisitos de isolamento que um servidor de API compartilhado não consegue atender.
Estudo de caso real: Atlan
A Atlan é uma empresa de catálogo de dados que hospeda a plataforma para cerca de 95% de seus clientes, muitos em saúde e finanças, onde o isolamento de dados é contratual. Ela rodava um cluster EKS completo por cliente e passou de 100 clusters, um parque caro de operar 24 horas por dia e difícil de manter. A partir do primeiro trimestre de 2022, avaliou opções de multitenancy e reconstruiu tudo no vCluster, dando a cada cliente um cluster virtual em vez de um físico.
- Os clusters EKS físicos caíram de mais de 100 para 20, ainda atendendo mais de 100 clientes
- Os gastos com Kubernetes caíram em US$ 600.000.13
Adicionar como fonte preferencialOrdem de execução
Os compromissos ficam por último, apesar de serem a ação mais fácil. Comprá-los antes do rightsizing prende de um a três anos o desperdício que o rightsizing estava prestes a remover. É o erro de sequenciamento mais caro disponível e é comum porque exige uma compra em vez de trabalho de engenharia.
A ação 7 é um desvio, não um passo. Execute-a quando as seis primeiras estiverem concluídas e o resultado ainda for insuficiente, pois ela muda quantos clusters rodam, e não a eficiência com que cada um roda.
Ferramentas de otimização de custos do Kubernetes
Plotamos ferramentas com três ou mais estudos de caso publicados cobrindo 47 dos 68 estudos de caso no dataset:
- Horizontal: quantos estudos de caso cada ferramenta tem, contados uma vez cada.
- Vertical: quantas categorias distintas de casos de uso esses casos abrangem, de dez. Uma ferramenta conta uma vez por categoria, independentemente de quantas vezes aparece lá, então as 12 menções separadas de rightsizing do CAST IA contribuem com 1 para a pontuação de 10.
- Tamanho da bolha: em quantos dos oito estágios da estratégia a ferramenta aparece.
Frameworks open-source
Frameworks open-source podem ser implantados para estágios de 0 a 6. Os usuários são responsáveis pelas atualizações, pela rotatividade de versões, pela fatura de retenção do Prometheus e pelas decisões de julgamento que um recomendador comercial faria por eles.
Cada uma delas domina um campo diferente, e é por isso que várias rodam ao mesmo tempo.
- Robusta KRR ou VPA em
updateMode: "Off"produz o backlog do passo 1. Não escreve nada. - Karpenter cuida dos nós: provisionamento, consolidação, seleção de instâncias, diversificação de spot, arquitetura. Carrega os passos 3, 4 e 6.
- KEDA cuida da contagem de réplicas, incluindo escala a zero, o que o HPA sozinho não consegue fazer.
- py-kube-downscaler ou kube-green cuida do cronograma de não produção. A economia mais barata da lista.
- OpenCost mede o tempo todo e não participa de nada.
Plataformas comerciais
Cada ferramenta comercial assume uma de três posições na camada de nós. Essa é a decisão, e ela importa mais do que preço ou quantidade de recursos, porque o manifesto NodePool do passo 3 ou sobrevive ou não.
- Deixe como está: StormForge, PerfectScale, Sedai e Kubex fazem rightsizing de workloads. Eles precisam do Karpenter ou Cluster Autoscaler por baixo e nunca mexem nele. A adição mais segura a uma configuração existente.
- Trabalhe com ele: ScaleOps adiciona bin packing por cima do Karpenter. nOps ajusta um Cluster Autoscaler ou Karpenter existente em vez de substituí-lo por um próprio. Mais cobertura, provisioner ainda seu.
- Substitua-o: CAST IA e Spot Ocean instalam seu próprio provisioner e descartam o manifesto. Cobertura mais ampla, menos controle.
- Ferramentas de visibilidade ficam do lado de fora: OpenCost, Kubecost, CloudZero, Vantage e Finout apenas leem, então não conflitam com nada e podem ser empilhadas livremente. Rode uma, independentemente do que mais for adotado.
Como combinar essas ferramentas
A fatura se baseia nos nós em execução, não nos requests declarados. O rightsizing reduz os requests, o que libera espaço nos nós existentes, mas não remove nenhum deles, então a fatura não muda até que uma ferramenta de nós consolide esse espaço. Ferramentas de nós sozinhas falham pelo motivo oposto: elas empacotam quaisquer requests que recebem, então requests superdimensionados são empacotados com mais densidade.
Duas formas de cobrir ambas as camadas:
- Duas ferramentas: VPA, StormForge ou PerfectScale para requests, mais Karpenter para nós. Mais barato, e a camada de nós permanece sob controle direto.
- Uma plataforma: CAST IA, Zesty ou Spot Ocean fazem ambos em um único produto. Mais caro, e o provisioner deles substitui o Karpenter.
Cinco combinações de ferramentas que quebram tudo:
- Dois rightsizers mutantes em uma implantação: VPA em
Autojunto com StormForge, ScaleOps, PerfectScale ou Zesty significa dois controllers escrevendo números diferentes no mesmo campo. Um admission controller mutante por workload. - Karpenter e Cluster Autoscaler em um grupo de nós: Ambos provisionam para os mesmos pods não agendáveis, então o cluster acaba com praticamente o dobro dos nós de que precisa.
- VPA e HPA na mesma métrica: O uso sobe, o VPA aumenta o request, a utilização medida cai porque é uso sobre request, o HPA remove réplicas, a carga por pod aumenta, repita. Seguro quando o HPA escala em algo que o VPA não toca, como profundidade de fila via KEDA.
- Duas ferramentas de compromisso em uma conta pagadora: Ambas compram contra o mesmo gasto não coberto, travando comprometimento excessivo por um a três anos.
- Duas plataformas completas: CAST IA, Zesty e Spot Ocean instalam cada uma seu próprio provisioner e cada uma espera ser dona dele.
Exiba todos os estudos de caso que reunimos:
Leitura adicional sobre custos de nuvem
Leia mais para dominar o posicionamento de pods e reduzir seus gastos com computação em nuvem:
- Compare as principais ferramentas de orquestração de contêineres
- Compare mais de 20 orquestradores de nuvem
- Principais agendadores de jobs de nuvem híbrida
Cite esta pesquisa
Escolha o formato adequado ao local onde você vai publicar. Colar a versão com link no seu CMS preserva o backlink.
@misc{simsek2026,
author = {Şimşek, Hazal},
title = {{Otimização de Custos do Kubernetes: 8 Passos & 23 Ferramentas}},
year = {2026},
month = sep,
howpublished = {\url{https://aimultiple.com/kubernetes-cost-optimization}},
note = {AIMultiple. Acessado em 18 setembro 2026}
}Resultados e carimbos de data/hora de 249 pontos de dados. Baixe os dados resumidos exibidos nos gráficos e tabelas deste artigo como um arquivo ZIP contendo 6 arquivos CSV.
Quer os dados granulares por trás disso? Assine o Premium
Links de referência
Seja o primeiro a comentar
Seu endereço de e-mail não será publicado. Todos os campos são obrigatórios. Os comentários são deixados em seu idioma original.