Rightsizing de pods no EKS: por que seus containers pedem demais
Seus containers provavelmente pedem mais CPU e memória do que usam, e no AWS EKS você paga pela capacidade reservada. Neste artigo, você vai entender como requests e limits viram custo, fazer o profiling das aplicações com métricas reais e usar VPA, Kubecost e outras ferramentas para o rightsizing de pods no EKS sem colocar a estabilidade em risco.
Series: Otimização de custos com AWS EKS (5 articles)
- …
- 3Rightsizing de pods no EKS: por que seus containers pedem demais This article
Num cluster AWS EKS , quase todo o custo vem das instâncias AWS EC2 que rodam os containers. E o tamanho dessa conta depende menos do que as aplicações usam e mais do que elas pedem. No post sobre visibilidade de custos , vimos como enxergar o custo ocioso de cada namespace. Agora é hora de reduzi-lo com o rightsizing de pods no EKS.
Um post da série "Otimização de custos com AWS EKS".
Neste post, você vai entender como requests e limits viram custo e como medir o consumo real das aplicações. Também vai conhecer as ferramentas que recomendam o tamanho certo e as boas práticas para ajustar sem colocar a estabilidade em risco.
Requests e limits: o que o Kubernetes reserva
Para CPU e memória, cada container pode declarar dois valores: o request e o limit. Eles agem em momentos diferentes: o request no agendamento, o limit na execução.
- Request é a quantidade reservada para o container. O kube-scheduler usa esse valor para escolher um nó com capacidade livre. Depois, o kubelet garante que essa quantidade fique disponível para ele.
- Limit é o teto. O container pode usar mais do que o request se houver sobra no nó, mas nunca mais do que o limit.
Os dois limites são aplicados de formas diferentes:
- CPU: ao chegar no limit, o container sofre throttling, ou seja, o kernel restringe o uso de CPU. A aplicação fica mais lenta, mas não para.
- Memória: se o container passar do limit, o kernel pode encerrá-lo com um OOM kill (out of memory). Por isso, errar na memória costuma ser mais grave do que errar na CPU.
Um detalhe que pega muita gente: se você define só o limit e nenhum request, o Kubernetes copia o limit para o request. Na prática, o container passa a reservar o teto inteiro.
A documentação do Kubernetes sobre gerenciamento de recursos detalha esse comportamento e as unidades usadas.
Classes de QoS: quem sai primeiro quando falta recurso
A combinação de requests e limits também define a classe de QoS do pod, que decide a ordem de despejo (eviction) quando o nó fica sem memória:
| Classe | Quando acontece | Prioridade em caso de falta de recurso |
|---|---|---|
| Guaranteed | Todos os containers têm request igual ao limit, de CPU e de memória | A última a ser despejada |
| Burstable | Pelo menos um container tem request ou limit, mas sem atender à regra acima | Intermediária |
| BestEffort | Nenhum container tem request nem limit | A primeira a ser despejada |
Assim, ao reduzir requests, você também pode estar mudando a classe de QoS do pod. Veja os detalhes na documentação sobre classes de QoS .
Como o superdimensionamento vira custo
No EC2, você paga pelo nó, e não pelo pod. Como o scheduler reserva capacidade pelo request, um container que pede 1 vCPU e usa 200 milicores ocupa 1 vCPU inteiro. Os 800 milicores restantes ficam parados, mas continuam na conta.
Um exemplo da AWS mostra o tamanho do efeito. Um pod pedia 800m de CPU e 3 GiB de memória, mas usava cerca de 200m e 1 GiB. Com isso, o nó tinha só cerca de 20% da CPU e 33% da memória efetivamente usadas. Mesmo assim, ele não aceitava novos pods, porque a capacidade estava quase toda reservada.
Depois de ajustar os requests para 200m e 1 GiB, o mesmo nó passou a comportar o triplo de pods. Ou seja, o mesmo workload passou a precisar de cerca de um terço das instâncias.
Além do custo direto, requests superdimensionados atrapalham a elasticidade:
- O HPA calcula a utilização de CPU como porcentagem do request. Com requests altos, a utilização parece baixa e o autoscaling demora a reagir.
- O Karpenter e o Cluster Autoscaler provisionam nós pelos requests pendentes. Com requests inflados, eles sobem mais capacidade do que o necessário.
Application profiling: medir antes de ajustar
O rightsizing de pods no EKS começa por dados, e não por palpites. Por isso, o primeiro passo é o application profiling : observar como cada aplicação consome CPU e memória ao longo do tempo. Raramente a alocação estará certa na primeira vez. A própria AWS, no EKS Best Practices Guide , diz que ajustar continuamente é mais importante do que acertar de primeira.
O que observar
Para cada workload, compare o que é pedido com o que é usado:
- Uso médio de CPU e memória, para entender o consumo típico;
- Picos e percentis altos. O p95 é o valor que cobre 95% das amostras: só 5% dos momentos ficam acima dele. A média sozinha engana, porque esconde os picos;
- Variação no tempo, como horário comercial, fim de semana e fechamento de mês;
- Sinais de sofrimento: eventos de OOM kill, throttling de CPU e reinícios.
Use uma janela que inclua os picos reais do negócio. Uma semana tranquila pode esconder o pico do fim do mês.
Uma referência prática: o guia de rightsizing da AWS recomenda coletar o uso por sete dias, com o VPA em modo
Off, e definir o request pelo p95 mais 20% de folga, deixando o HPA escalar quando a utilização passa de 70%. Assim o pod fica enxuto no dia a dia, e os picos raros ficam por conta do autoscaling, não de capacidade reservada o tempo todo.
Onde buscar os dados
- AWS CloudWatch Container Insights : métricas de CPU e memória por cluster, nó, pod e container, já integradas à AWS.
- AWS Managed Service for Prometheus : métricas do Prometheus, inclusive as do kube-state-metrics, consultadas com PromQL e visualizadas no Grafana.
- Kubecost: a visão de eficiência que vimos no post sobre visibilidade de custos, com a relação entre uso e request por namespace, workload e container.
Testes de carga e de falha
Dados de produção mostram o passado. Para saber como a aplicação se comporta em escala, gere carga de forma controlada:
- A solução Distributed Load Testing on AWS simula de centenas a milhões de usuários contra um endpoint, sem provisionar servidores.
- O AWS Fault Injection Service tem ações específicas para pods do EKS, como estresse de CPU e de memória. Com elas, você valida se os novos requests e limits aguentam situações adversas antes de ir para produção.
Ferramentas que recomendam o tamanho certo
Com os dados em mãos, você pode calcular os valores manualmente. No entanto, em clusters com dezenas ou centenas de workloads, o rightsizing de pods no EKS fica mais simples com ferramentas que fazem esse cálculo por você.
Vertical Pod Autoscaler em modo de recomendação
O Vertical Pod Autoscaler (VPA) analisa o histórico de uso de cada workload e calcula três recomendações: o target (valor ideal para o uso típico), o lower bound (mínimo viável) e o upper bound (máximo razoável).
O comportamento do VPA depende do campo
updateMode:| Modo | O que faz |
|---|---|
| Off | Só calcula e guarda as recomendações. Não altera nenhum pod. |
| Initial | Aplica as recomendações apenas quando um pod é criado. |
| Recreate | Despeja os pods cujos requests estão muito longe da recomendação, para recriá-los com os novos valores. |
| InPlaceOrRecreate | Tenta ajustar os recursos com o pod rodando e, se não conseguir, recria o pod. |
| InPlace | Só ajusta com o pod rodando, sem nunca recriá-lo. É um recurso alfa na versão 1.7.0 do VPA. |
O EKS Best Practices Guide recomenda começar com o VPA em modo de auditoria (
Off). Assim, ele sugere valores sem reiniciar pods, e você revisa e testa as mudanças fora de produção antes de aplicá-las.Exemplo: VPA só para recomendação
1
2
3
4
5
6
7
8
9
10
11
12
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
name: checkout-vpa
namespace: ecommerce
spec:
targetRef:
apiVersion: apps/v1
kind: Deployment
name: checkout
updatePolicy:
updateMode: "Off" # só recomenda, não altera os pods
Depois de alguns dias de coleta, consulte as recomendações:
1
kubectl describe vpa checkout-vpa -n ecommerce
Para instalar, siga o guia Adjust pod resources with Vertical Pod Autoscaler da documentação do EKS. O VPA precisa do Metrics Server no cluster.
Redimensionamento sem reiniciar o pod
Até pouco tempo atrás, mudar os recursos de um pod exigia recriá-lo. Desde o Kubernetes 1.35, o redimensionamento in-place é estável: você altera CPU e memória de um container sem recriar o pod, o que pode evitar a interrupção da aplicação. É esse recurso que os modos
InPlaceOrRecreate e InPlace do VPA usam. Os detalhes estão na documentação do Kubernetes sobre resize de recursos .Outras opções
- Goldilocks e KRR (Robusta): ferramentas open source citadas pelo EKS Best Practices Guide . O Goldilocks cria um VPA em modo de recomendação para cada workload de um namespace e mostra os resultados num painel. O KRR roda como linha de comando e calcula recomendações a partir de percentis do Prometheus.
- Kubecost: o add-on do EKS tem um painel de Container Request Right Sizing com a economia estimada por container. Ele aceita perfis de recomendação, como produção ou alta disponibilidade, e aplica o ajuste uma vez ou de forma agendada. Segundo o blog da AWS com a Kubecost , quem usa o recurso relata de 20% a 60% de redução no custo de computação em ambientes não produtivos.
- Recomendações via GitOps: se a configuração vive no Git, mudar direto no cluster gera drift. Um blog da AWS mostra a alternativa : calcular as recomendações a partir do Prometheus, fora do cluster, e abrir pull requests com os novos valores. Nesse padrão, o AWS Bedrock descreve cada mudança.
💰 Preços de referência: outubro de 2026. A faixa de 20% a 60% foi relatada no blog da AWS com a Kubecost, publicado em setembro de 2025, e a economia real depende do seu ambiente. Para calcular o impacto no seu caso, use os valores atuais da página de preços do AWS EC2 , que podem ter mudado.
⚠️ O AWS Compute Optimizer não recomenda tamanhos para pods. Ele cobre instâncias EC2, Auto Scaling groups e volumes AWS EBS , entre outros recursos. Por isso, ajuda no rightsizing dos nós, mas não dos pods.
Boas práticas de rightsizing de pods no EKS
Ferramentas sugerem números, mas o contexto é seu:
- Faça os requests refletirem o uso real. O request deve cobrir o consumo da aplicação em carga normal, com uma folga para os picos.
- Comece pela memória. Falta de memória gera OOM kill, enquanto falta de CPU gera lentidão. Por isso, corrija primeiro os casos de memória subdimensionada.
- Use memory request igual ao memory limit em workloads com picos, como recomenda o blog da AWS sobre análise de workloads. Isso evita disputa de memória no nó.
- Tenha cuidado com limits de CPU. Eles causam throttling mesmo quando há CPU sobrando no nó. Por isso, avalie se a aplicação realmente precisa deles.
- Configure requests em todos os containers, inclusive nos sidecars. O request do pod é a soma dos requests de cada container.
- Considere o SLA. Desenvolvimento tolera algum throttling; um serviço com meta de 99,99% de disponibilidade precisa de mais folga.
- Cuidado ao usar HPA e VPA na mesma métrica. Se o HPA escala por CPU, lembre que ele a mede como porcentagem do request — justamente o que o VPA altera —, então os dois se desestabilizam. Prefira o HPA numa métrica de negócio, como requisições por segundo ou tamanho de fila, e deixe o VPA cuidar dos recursos do pod. Voltamos a esse ponto no post sobre escalabilidade de aplicações.
- Revise continuamente, porque novas versões e mais tráfego mudam o perfil da aplicação.
Além dos requests: réplicas e restrições
O mesmo blog da AWS aponta outros dois padrões de desperdício. O primeiro são réplicas em excesso, criadas por topology spread constraints rígidas demais. O segundo são PodDisruptionBudgets e a anotação
karpenter.sh/do-not-disrupt, que impedem a consolidação de nós. Vamos tratar desses pontos no post sobre Cluster Autoscaler x Karpenter.Por onde começar
Para colocar o rightsizing de pods no EKS em prática sem correr riscos, siga uma sequência simples:
- Escolha os workloads mais caros, usando a visibilidade de custos por namespace e por workload.
- Instale o VPA em modo
Offnesses workloads, ou use o painel de rightsizing do Kubecost. - Compare as recomendações com o uso real no Container Insights ou no Prometheus, em uma janela que inclua os picos.
- Teste os novos valores fora de produção, com carga e com injeção de falhas.
- Aplique de forma gradual e acompanhe OOM kills, throttling e latência.
Checklist do post
- Todos os containers, inclusive sidecars, têm requests de CPU e memória
- Nenhum workload crítico está na classe BestEffort
- O uso real foi medido numa janela que inclui os picos do negócio
- O VPA está rodando em modo
Off(ou outra ferramenta gera recomendações) - As mudanças passam por teste de carga antes de produção
- Os limits de CPU foram revisados
- Os eventos de OOM kill e de throttling são monitorados
- Existe uma rotina recorrente de revisão de requests
Perguntas frequentes
O que é rightsizing de pods?
É ajustar os requests e limits de CPU e memória de cada container ao consumo real da aplicação. O objetivo é parar de reservar capacidade que nunca é usada, sem causar lentidão ou falhas.
Qual a diferença entre request e limit no Kubernetes?
O request é a quantidade reservada para o container e é usada pelo scheduler para escolher o nó. O limit é o teto de uso: na CPU, gera throttling; na memória, pode encerrar o container por OOM.
O VPA reinicia os pods?
Depende do modo. No modo
Off, ele só recomenda. Nos modos Recreate e InPlaceOrRecreate, pode recriar pods para aplicar os novos valores. O modo InPlace só ajusta com o pod rodando e ainda é alfa.O AWS Compute Optimizer faz rightsizing de pods do EKS?
Não. Ele recomenda tamanhos para instâncias EC2, Auto Scaling groups e volumes EBS, entre outros recursos, mas não para pods. Para os pods, use o VPA, o Kubecost ou ferramentas como Goldilocks e KRR.
Devo remover os limits de CPU?
Não existe resposta única. Limits de CPU evitam que um container monopolize o nó, mas causam throttling mesmo com CPU sobrando. Por isso, avalie cada caso e teste antes de mudar.
Próximo post
Com os pods do tamanho certo, a próxima pergunta é: quantos pods você precisa a cada momento? No próximo post da série, vamos falar de escalabilidade de aplicações com HPA e VPA, e de como fazer o número de réplicas acompanhar a demanda.
Series: Otimização de custos com AWS EKS (5 articles)
- …
- 3Rightsizing de pods no EKS: por que seus containers pedem demais This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article