Otimização de custos do Kubernetes: 8 etapas, 23 ferramentas e estudos de caso

Os clusters Kubernetes podem parecer totalmente saudáveis enquanto a conta aumenta. O autoscaling está configurado, os dashboards estão verdes e os gastos sobem mesmo assim. Em uma pesquisa, 42% de 455 engenheiros de plataforma apontaram o custo como o principal desafio de Kubernetes, enquanto 88% viram o custo total de propriedade subir ano após ano.¹

Reunimos 68 estudos de caso sobre 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 caso publicado para aquele caso de uso.

Continue rolando para ver o guia de 8 etapas com exemplos reais para reduzir os gastos do cluster e a comparação de ferramentas de otimização de custos do Kubernetes.

1. Meça antes de mudar qualquer coisa

Cada número no restante deste guia é 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 a etapa 1 funcionou, nem como atribuir a economia da etapa 3 à consolidação em vez do rightsizing que a precedeu. Isso importa mais aqui do que na maioria do trabalho de engenharia, porque todas as seis ações reduzem a mesma conta e as economias não se somam. Liberar capacidade na etapa 1 não gera nada na fatura até a etapa 3 remover os nós.

Meça quatro coisas:

• Solicitado versus usado de CPU e memória, por carga de trabalho. A diferença é o trabalho pendente da etapa 1, classificado por tamanho.
• Custo por namespace e por carga de trabalho. É isso que torna as cotas da etapa 2 uma negociação em vez de uma imposição.
• Eficiência de bin packing, alocável versus solicitado por nó. O alvo da etapa 3.
• Custo ocioso por hora do dia e dia da semana em não produção. Dimensiona a etapa 5 antes de você construí-la.

Meça ao longo de pelo menos um ciclo de negócios completo. Sete dias é o mínimo e trinta é melhor. A janela não é cautela processual. A etapa 1 define as solicitações de memória no máximo observado, e um máximo observado só é tão bom quanto a janela que o observou. Um máximo capturado em 48 horas não detecta um job em lote semanal e gera um OOMKill no domingo seguinte.

Ferramentas

• Alocação de custos: OpenCost, o projeto CNCF por trás do modelo de alocação, é o patamar gratuito. O nível gratuito do Kubecost empacota o mesmo motor em uma UI para até 250 núcleos.
• Utilização: Prometheus com kube-state-metrics é o substrato. O Robusta KRR lê diretamente sem instalar nada no cluster.
• Gastos mais amplos: Onde o Kubernetes é uma parte de uma fatura que o financeiro 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 não rotulados são o motivo mais comum pelo qual uma linha de base se torna inútil três semanas depois.

Cada ação abaixo apresenta a recomendação, o método, a configuração e uma empresa que executou essa etapa. Cada estudo de caso e cada estatística possui um link de origem.

2. Defina cotas de namespace como proteções

As economias diminuem à medida que as equipes implantam novas cargas de trabalho sem solicitações especificadas. Um LimitRange fornece solicitações padrão para contêineres que as omitem, e um ResourceQuota limita o que um namespace pode consumir no agregado.

Implante o LimitRange antes do ResourceQuota. Depois que uma cota restringe um recurso, qualquer pod sem solicitação para esse recurso é rejeitado na admissão, então a ordem inversa quebra as implantações.²

Cada load balancer é cobrado separadamente pelo provedor de nuvem, e volumes órfãos continuam a ser cobrados depois que seus pods desaparecem.

2. Faça o rightsizing das solicitações de CPU e memória

As solicitações determinam o número de nós, e o número de nós determina a fatura. A maioria dos clusters opera muito abaixo da capacidade pela qual pagam, porque as solicitações foram estimadas uma vez e nunca revisadas. Uma análise de 23.000 clusters de produção na AWS, Azure e Google Cloud encontrou utilização média de CPU de 8%, de memória de 20% e de GPU de 5%.³

Defina as solicitações de CPU próximas ao percentil 95 do uso observado. Defina as solicitações de memória no máximo observado, em vez de um percentil, e defina o limite de memória igual à solicitação. Um percentil deixa o contêiner sem recursos durante o tráfego restante e, como o limite corresponde à solicitação, essa escassez 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 a solicitação já reserva o que a carga de trabalho precisa.

O Vertical Pod Autoscaler no modo somente recomendação produz esses números sem risco em produção.

Leia as recomendações com kubectl describe vpa payments-api e compare o valor alvo com a solicitação atual.

Estudo de caso real: Tryg Insurance

A Tryg Insurance é a maior seguradora geral da região nórdica e executa Kubernetes na infraestrutura Oracle Cloud. Sua equipe de engenharia combinou o Horizontal Pod Autoscaler e o Vertical Pod Autoscaler para dimensionar dinamicamente as cargas de trabalho, mantendo os níveis de serviço, e reduziu os custos de nuvem do Kubernetes em 50% usando apenas autoscalers open source, sem plataforma comercial de otimização.⁴

4. Consolide nós com Karpenter e dimensione cargas de trabalho ociosas para zero

O rightsizing libera capacidade, mas essa capacidade fica em nós que continuam em execução até algo removê-los. O Karpenter provisiona instâncias just in time e reorganiza as cargas de trabalho em menos nós. O KEDA escala para zero réplicas as cargas de trabalho orientadas por fila, o 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 interrupção a nós que não possuem nenhum pod de carga de trabalho, e eles raramente ocorrem sem intervenção.⁵

Uma lista restrita de instâncias anula isso, porque o Karpenter não consegue encontrar opções baratas fora da curva 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 executa 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 escalabilidade orientada a eventos, criou automaticamente objetos Vertical Pod Autoscaler por meio de políticas Kyverno e usou o kube-downscaler para ambientes ociosos. Eles reduziram o custo de executar seus clusters Kubernetes na AWS em até 50%, usando uma stack totalmente open source.⁶

5. Prepare-se adequadamente antes de mover cargas de trabalho para spot

Instâncias spot oferecem o maior desconto disponível e a aplicabilidade mais restrita. Nada deve migrar para spot até que PodDisruptionBudgets, diversificação de instâncias, topology spread e tratamento de encerramento estejam todos no lugar.

Um PodDisruptionBudget sem margem bloqueia toda interrupção voluntária, incluindo a consolidação do Karpenter, então os valores precisam de folga.⁷

Estudo de caso real: Delivery Hero

A Delivery Hero opera 390 aplicações em 43 países, com cerca de 90% das cargas de trabalho rodando no AWS EKS. Sua equipe migrou para Spot Instances ao longo de aproximadamente seis meses, incorporando tratamento de encerramento e um descheduler no processo, em vez de trocar os tipos de capacidade diretamente.

• Os custos de infraestrutura caíram cerca de 70%
• Os descontos spot chegaram a até 90% sobre os preços sob demanda
• A plataforma absorve picos de tráfego de 4 a 5 vezes o volume normal.⁸

6. Desligue ambientes de 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 sem controvérsia política, 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 cancelem explicitamente. Uma política que exige ação para entrar alcança menos equipes do que uma que exige ação para sair.

A economia só chega à fatura se a consolidação de nós já estiver em execução, pois 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 executa 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%.⁹

7. Migre cargas de trabalho compatíveis para ARM

Instâncias baseadas em ARM alteram o preço unitário, em vez de competir pela mesma capacidade ociosa das ações acima, portanto essas economias realmente se somam ao restante. Os bloqueadores serão dependências sem builds ARM64.

Os usuários devem dimensionar isso por carga de trabalho, em vez de em todo o parque, e criar imagens multiarquitetura antes de agendar qualquer coisa.

Estudo de caso real: Pinterest

O Pinterest migrou sua carga de trabalho de API web para instâncias AWS Graviton rodando em ARM64, motivado tanto pela 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%.¹⁰

8. Quando o tuning se esgotar, mude a arquitetura

As seis ações acima ajustam cargas de trabalho dentro dos clusters existentes. Depois que se esgotam, mais ganhos exigem mudança de arquitetura em vez de mais ajustes.

Dois resultados publicados marcam o limite prático. A InCred Finance reduziu os gastos em 30% em clusters que sua equipe já considerava otimizados¹¹, e a Yotpo alcançou 30–40% enquanto já rodava 80% das cargas de trabalho em instâncias spot¹². Além dessa faixa, o desperdício restante não fica 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 elimina os dois 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 o bin packing no pool de nós compartilhado, em vez de dentro de conjuntos isolados.

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 carga de trabalho no host. Esse custo é justificado em dois casos: tenants que precisam de seus próprios recursos com escopo de cluster 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 executava um cluster EKS completo por cliente e ultrapassou 100 clusters, um parque caro de rodar 24 horas por dia e difícil de manter. A partir do primeiro trimestre de 2022, avaliou opções de multitenancy e reconstruiu sobre o vCluster, dando a cada cliente um cluster virtual em vez de um físico.

• Clusters EKS físicos caíram de mais de 100 para 20, ainda atendendo mais de 100 clientes
• Os gastos com Kubernetes caíram US$ 600.000.¹⁴

Não perca os nossos benchmarks e insights baseados em dados. O botão abre o Google; selecionar a AIMultiple confirma que deseja ver a AIMultiple com mais frequência nos resultados de pesquisa do Google.

Adicionar como fonte preferencial

Ordem 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 do 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 é uma ramificação, não uma etapa. Execute-a somente quando as seis primeiras estiverem concluídas e o resultado ainda for insuficiente, pois muda quantos clusters executam em vez de quão eficientemente 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 do dataset:

• Horizontal: quantos estudos de caso cada ferramenta tem, contados uma vez cada.
• Vertical: quantas categorias distintas de caso de uso esses casos abrangem, de dez. Uma ferramenta conta uma vez por categoria, não importa quantas vezes apareça nela, então as 12 menções separadas de rightsizing da CAST IA contribuem com 1 para sua pontuação de 10.
• Tamanho da bolha: em quantas das oito etapas da estratégia a ferramenta aparece.

Frameworks open source

Frameworks open source podem ser implantados para as etapas de 0 a 6. Os usuários assumem as atualizações, a rotatividade de versões, a conta de retenção do Prometheus e as decisões de julgamento que um recomendador comercial tomaria por eles.

Cada uma dessas é responsável por um campo diferente, por isso várias rodam ao mesmo tempo.

• Robusta KRR ou VPA em updateMode: "Off" produz o backlog da etapa 1. Não grava nada.
• Karpenter é responsável pelos nós: provisionamento, consolidação, seleção de instâncias, diversificação de spot, arquitetura. Carrega as etapas 3, 4 e 6.
• KEDA é responsável pela contagem de réplicas, incluindo escala para zero, o que o HPA sozinho não consegue fazer.
• py-kube-downscaler ou kube-green é responsável pelo cronograma de não produção. A economia mais barata da lista.
• OpenCost mede do início ao fim e não participa de nada.

Plataformas comerciais

Toda 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 número de recursos, porque o manifesto NodePool da etapa 3 sobrevive ou não sobrevive.

• Deixe como está: StormForge, PerfectScale, Sedai e Kubex apenas fazem rightsizing das cargas de trabalho. Eles precisam do Karpenter ou do Cluster Autoscaler por baixo e nunca o tocam. A adição mais segura a uma configuração existente.
• Trabalhe com ele: ScaleOps adiciona bin packing sobre o Karpenter. O nOps ajusta um Cluster Autoscaler ou Karpenter existente em vez de substituir por um próprio. Mais cobertura, o provisioner continua sendo seu.
• Substitua-o: CAST IA e Spot Ocean instalam o próprio provisioner e descartam o manifesto. Maior cobertura, 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 se combinam livremente. Execute uma delas independentemente do que mais for adotado.

Como combinar essas ferramentas

A fatura é baseada nos nós em execução, não nas solicitações declaradas. O rightsizing reduz as solicitações, 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 inverso: elas empacotam qualquer solicitação que recebem, então solicitações superdimensionadas simplesmente são empacotadas com mais força.

Duas maneiras de cobrir ambas as camadas:

• Duas ferramentas: VPA, StormForge ou PerfectScale para solicitações, 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 coisas:

• Dois rightsizers mutantes em uma implantação: VPA em Auto junto com StormForge, ScaleOps, PerfectScale ou Zesty significa dois controllers escrevendo números diferentes no mesmo campo. Um admission controller mutante por carga de trabalho.
• Karpenter e Cluster Autoscaler no mesmo grupo de nós: Ambos provisionam contra os mesmos pods não agendáveis, então o cluster termina com aproximadamente o dobro dos nós de que precisa.
• VPA e HPA na mesma métrica: O uso sobe, o VPA aumenta a solicitação, a utilização medida cai porque é uso sobre solicitação, 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 os mesmos gastos não cobertos, travando sobrecompromisso 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.

Analise todos os estudos de caso que reunimos:

Leitura adicional

Leia mais para dominar a alocação 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 etapas, 23 ferramentas e estudos de caso}},
  year   = {2026},
  month  = sep,
  howpublished    = {\url{https://aimultiple.com/kubernetes-cost-optimization}},
  note   = {AIMultiple. Acessado em 18 setembro 2026}
}

Links de referência

1.

https://hs-20518613.f.hubspotemail.net/hubfs/20518613/Spectro%20Cloud%202025%20State%20of%20Production%20Kubernetes.pdf

2.

Resource Quotas | Kubernetes

3.

2026 Kubernetes Optimization: Data & Best Practices - Cast AI

Cast AI

4.

How Tryg Insurance saved 50% of Kubernetes cloud costs: Patterns for dynamic right-sizing of Kubernetes | cloud-infrastructure

5.

Disruption | Karpenter

6.

https://medium.com/adidoescode/reducing-cloud-costs-of-kubernetes-clusters-c8c1e3bdb669

7.

Disruptions | Kubernetes

8.

Spot Instances at Delivery Hero | Delivery Hero Tech

9.

Bud Achieved 90%+ Utilization and Higher Engineering Productivity – Cast AI

Cast AI

10.

How potential performance upside with AWS Graviton helps reduce your costs further | AWS Compute Blog

11.

InCred Finance Unlocked 30% Cost Savings in Kubernetes Clusters – Cast AI

Cast AI

12.

Yotpo Kubernetes Optimization Case Study - Cast AI

Cast AI

13.

Page restricted | ScienceDirect

14.

How Atlan Reduced Their Infrastructure From 100 Kubernetes Clusters To 1 Using vCluster

vCluster

15.

Save up to 60% on AWS costs with EKS and Karpenter - Qovery Blog

Qovery

Hazal Şimşek

Analista do Setor

Siga-nos

Hazal é analista do setor na AIMultiple, com foco em inteligência de processos (incluindo mineração de processos) e automação empresarial (incluindo automação de TI e automação low-code/no-code).

Ver perfil completo

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.

Nome

Endereço de email

Comentário

0/450

Postar comentário