Todo platform engineer com quem conversei no último ano tem alguma versão da mesma planilha. Linhas para node groups, colunas para famílias de instância, uma aba para prod, outra para staging e uma célula de comentário otimista dizendo "revisar no próximo trimestre". Ela costuma ficar precisa por umas seis horas. Aí sobe um deployment com novos pod requests, o Karpenter provisiona uma c7i em vez de uma m6i, um nó Spot é reclamado e a planilha silenciosamente vira ficção. Não é falta de disciplina. É um problema de matemática. A topologia de nós do Kubernetes muda mais rápido do que qualquer pessoa consegue acompanhar, e planejamento estático nunca teve como dar conta de autoscalers, rotatividade de Spot e deploys diários. A resposta de verdade não é uma planilha melhor nem um dashboard mais bonito. É rightsizing contínuo e automatizado, que trata pod requests e topologia de nós como um único loop conectado, rodando sem depender de alguém atualizar uma célula.
Por que o acompanhamento manual de node pools no Kubernetes falha?
O acompanhamento manual de node pools falha porque pod requests, comportamento do autoscaler e interrupções de Spot mudam mais rápido do que qualquer planilha consegue ser atualizada. Três forças tornam a conta impossível.
Primeiro, os pod requests mudam. Os times sobem deployments várias vezes por dia. Cada rollout pode alterar os requests de CPU e memória, às vezes de propósito, muitas vezes sem querer, quando uma imagem base é atualizada. Sua planilha assumiu que um pod precisava de 500m de CPU. O release de ontem passou para 750m. Ninguém avisou a planilha.
Segundo, os autoscalers remodelam o cluster em tempo real. Karpenter e Cluster Autoscaler escolhem tipos de instância com base nos pods pendentes do momento, em restrições de bin-packing e na disponibilidade. Um plano que diz "rodamos 12 nós m6i.2xlarge" é o retrato de um instante. Uma hora depois você pode estar com 8 c7i.xlarge e 4 r7i.large, e as duas configurações estão corretas para o workload que existia naquele momento.
Terceiro, as interrupções de Spot quebram premissas toda semana. A AWS reclama um nó, o Karpenter substitui por outra família de instância e a topologia que você planejou deixa de existir. Se seu modelo de custo depende de "estamos com 70% em Spot nessa família", você está no chute.
A FinOps Foundation deixa isso explícito: planejamento iterativo e ágil é preferível ao planejamento estático de longo prazo em uma parcela cada vez maior do parque tecnológico. Topologia de nós está bem no meio dessa parcela.
Qual é a diferença entre rightsizing de nós e rightsizing de pods?
O rightsizing de nós escolhe as famílias e tamanhos de instância certos para o seu cluster. O rightsizing de pods define os requests certos de CPU e memória para cada workload. Costumam ser tratados como problemas separados — e é exatamente por isso que os dois geralmente continuam errados.
Pod requests moldam a escolha do nó
Se seus pod requests estão inflados, o scheduler precisa de nós maiores para acomodá-los. Você acaba pagando por uma folga que nenhum workload vai usar. Ajuste os requests para bater com o uso real e os mesmos workloads passam a caber em nós menores e mais baratos. O node pool não precisava mudar. Os pods sim.
A escolha do nó molda a performance do pod
Rode um serviço Java com uso intenso de memória em uma família de instância otimizada para computação e você vai brigar com OOMKills por mais que ajuste o heap da JVM. Escolha uma instância baseada em ARM sem checar suas imagens de container e metade dos seus pods não vai nem ser agendada. Família de nó é decisão de performance, não só de custo.
Um loop, não dois
Não dá para resolver nenhum dos problemas isoladamente. O PerfectScale analisa o comportamento do workload e a topologia de nós em conjunto e aplica as mudanças sem reiniciar pods. Essa última parte faz diferença. O Vertical Pod Autoscaler reinicia pods para alterar requests, o que tudo bem para workloads stateless, mas dói em quase todo o resto. Rightsizing contínuo, sem reinicializações, fecha o loop que dashboards e revisões manuais deixam aberto.
Para um olhar mais aprofundado sobre como a escolha da família de instância afeta workloads reais, nosso artigo sobre estratégias de seleção de nodepool percorre os trade-offs.
Como platform engineers planejam node pools no Kubernetes sem planilhas?
Platform engineers planejam node pools no Kubernetes automatizando o loop de análise e colocando a responsabilidade nas mãos dos engenheiros que rodam os workloads. É uma mudança da propriedade centralizada em planilhas para tomada de decisão descentralizada, o que reflete o princípio de FinOps de que a responsabilidade por uso e custo deve ficar na ponta.
Algumas ações práticas tornam isso real:
- Instrumente primeiro, decida depois. Você precisa de dados de uso em nível de pod, utilização de nós e histórico de topologia em um só lugar. Se seus dados moram em três ferramentas, você voltou às planilhas com outro nome.
- Vincule recomendações a responsáveis. Recomendação sem nome vira trabalho de ninguém. Times de plataforma que expõem sugestões de rightsizing por workload para os times de dev donos daqueles workloads têm adoção mais rápida.
- Automatize o que é seguro. Rightsizing de workloads estáveis e bem conhecidos não precisa de humano no loop. Reserve a revisão humana para workloads com SLAs apertados ou padrões incomuns.
- Respeite as restrições de SLA. Rightsizing baseado em ML que só olha para médias vai subprovisionar seu p99. Procure análises que modelem o comportamento do workload ao longo do tempo, e não só fotos pontuais.
A Paramount Pictures reduziu problemas de resiliência em 90% depois de adotar o PerfectScale, em grande parte por eliminar as tarefas manuais que consumiam o tempo do time de engenharia de plataforma. Esse é o resultado prático de sair do planejamento em planilhas para um loop contínuo.
Para times ainda desenvolvendo essa musculatura, nosso guia definitivo para manter seus clusters Kubernetes enxutos cobre os hábitos operacionais que fazem isso funcionar.
Como a otimização contínua se compara a dashboards e ao VPA?
Dashboards mostram o que aconteceu. O Vertical Pod Autoscaler altera pod requests, mas reinicia os pods para isso. A otimização contínua faz a análise e aplica as mudanças sem reinicializações — é uma categoria diferente de ferramenta.
A diferença prática é a seguinte. Um dashboard te avisa que o node group X está com 40% de utilização. Ótimo. Agora alguém precisa decidir o que fazer, se alinhar com o time dono dos workloads, agendar uma janela de mudança e atualizar a planilha. Isso é toil, e escala linearmente com o número de workloads que você roda.
O VPA resolve parte disso ajustando pod requests automaticamente, mas não enxerga a topologia de nós e reinicia os pods para aplicar as mudanças. Para um serviço stateful ou um batch job de longa duração, esse custo de reinicialização é real.
O PerfectScale roda continuamente em EKS, GKE, AKS e clusters autogerenciados, sem alterações em helm chart nem mexer no código. Do setup à primeira recomendação leva menos de 5 minutos. A análise considera comportamento dos pods, topologia de nós e restrições de SLA em conjunto, e as mudanças são aplicadas sem reiniciar pods. Em mais de 500 clusters de produção, os times veem cerca de 40% de redução de custo e 60% menos incidentes relacionados a recursos.
Essa é a virada: de "aqui está um dashboard, boa sorte" para "o loop está rodando, revise as mudanças".
Frequently asked
questions
O que é uma estratégia de node pool no Kubernetes?
Uma estratégia de node pool no Kubernetes define em quais tipos de instância, tamanhos e restrições de topologia seus workloads rodam, e como essas escolhas se ajustam conforme os pod requests mudam. Cobre seleção de família de instância, mix de Spot versus on-demand e como os autoscalers devem se comportar sob carga.
Por que o rightsizing manual de nós falha no Kubernetes?
O rightsizing manual de nós falha porque os pod requests mudam a cada deployment, os autoscalers remodelam o cluster continuamente e as interrupções de Spot trocam famílias de instância sem aviso. Qualquer plano estático fica impreciso poucas horas depois de escrito.
Qual é a diferença entre rightsizing de nós e rightsizing de pods?
O rightsizing de nós seleciona tipos e tamanhos de instância para o cluster, enquanto o rightsizing de pods define os requests de CPU e memória para workloads individuais. É o mesmo problema de otimização visto por dois lados, e resolvê-los de forma independente deixa desperdício ou risco de performance na mesa.
Dá para automatizar a seleção de node pools no Kubernetes com segurança?
Sim, desde que a automação analise comportamento do workload, topologia de nós e restrições de SLA em conjunto, e aplique as mudanças sem reiniciar pods. Ferramentas que só ajustam pod requests ou só recomendam tipos de nó resolvem metade do problema.
Quanto tempo leva para ver resultados do rightsizing automatizado?
O PerfectScale gera as primeiras recomendações em até 5 minutos após a instalação. Melhorias relevantes de custo e confiabilidade costumam aparecer nas primeiras semanas, à medida que o sistema constrói um modelo comportamental de cada workload.
Planilha não é estratégia de node pool. É o retrato de um instante em um cluster que não para de se mexer. Rightsizing contínuo e automatizado, tratando pod requests e topologia de nós como um só loop, é a única abordagem que acompanha o comportamento real do Kubernetes. Os engenheiros que rodam os workloads devem ser donos das decisões, apoiados em dados que estejam de fato atualizados.