Visibilidade de custo no Kubernetes com Kubecost e VPA
Você não pode otimizar o que não consegue ver. Veja como construí visibilidade de custo no Kubernetes com Kubecost, fiz rightsizing dos workloads com o Vertical Pod Autoscaler e consolidei node pools para reduzir a contagem de nodes em cerca de 20%.
A alocação de custo orienta os resource requests e a consolidação; a economia precisa de um baseline de cobrança.
Contribuição em resumo
- Minha responsabilidade
- Implantação do Kubecost, integração de cobrança e visibilidade de alocação por workload.
- Escopo
- Infraestrutura de alocação de custo em sandbox e produção.
- Colaboração & limites
- Tornei o custo e o uso de recursos visíveis para apoiar decisões sobre os workloads; visibilidade é diferente de adoção ou economia verificadas.
- Resultado
- Informação de alocação por namespace/módulo e de rightsizing; a economia resultante exige seu próprio baseline de cobrança.
O custo do Kubernetes é notoriamente opaco. A conta da nuvem chega como um único número, mas está espalhada por namespaces, times e workloads que compartilham os mesmos nodes, e ninguém sabe dizer quanto cada coisa realmente custa. O FinOps começa resolvendo isso: torne o custo visível por workload e, então, aja sobre o que você vê.
Passo 1: visibilidade de custo com Kubecost
Implantei o Kubecost nos clusters de sandbox e produção, conectado ao export de cobrança da nuvem (via BigQuery) para que seus números reconciliem com a fatura real em vez de estimar. Algumas decisões que fizeram isso dar certo:
- Prometheus standalone. Deixei o Kubecost rodar sua própria stack de métricas em vez de acoplá-lo ao Prometheus existente. Mais rápido de implantar e com coleta de métricas garantida, sem ligações frágeis entre serviços.
- Ingress interno com TLS. Acessível pelo time, não pela internet.
- Alocação por módulo. Configurei tags de alocação de custo para que a conta se divida por módulo e time, não apenas por namespace.
O retorno é imediato: custo em tempo real por namespace e deployment, utilização vs. alocação, recomendações de rightsizing e reconciliação de cobrança com a fatura real da nuvem.
Passo 2: rightsizing com o Vertical Pod Autoscaler
A visibilidade mostrou a história de sempre: workloads pedindo muito mais CPU e memória do que jamais usam. Implantei o Vertical Pod Autoscaler (VPA) nos ambientes de não produção para que os requests acompanhem o uso real, em vez de um palpite cauteloso feito por alguém um ano atrás. Uma ressalva que vale compartilhar: o VPA não é livre de casos extremos. Em um serviço faminto por memória, ele interagiu mal com o comportamento de OOM, então removi o VPA daquele workload específico em vez de deixá-lo brigar com o pod. Rightsizing é um padrão, não uma religião.
Passo 3: consolidação
Com dados reais de utilização, muitos nodes acabaram carregando pods quase ociosos. Consolidei os workloads em node pools compartilhados para que o scheduler pudesse fazer o bin-packing corretamente, o que reduziu a contagem de nodes em cerca de 20% nos ambientes sem impacto nos workloads.
Passo 4: faça disso um hábito, não um projeto
Economias pontuais se dissipam. É a prática que mantém a conta baixa:
- Monitoramento diário de custo. O hábito constante de checar os relatórios de custo e investigar qualquer pico no mesmo dia, enquanto a causa ainda está fresca.
- Revisão de committed-use. Analisei a frota de compute em estado estável quanto à cobertura de committed-use discounts, para que o baseline que está sempre rodando também seja o baseline pelo qual você paga menos.
- A análise de custo guia as decisões. Estabeleci o baseline de custo de workloads específicos para que desativar um deles viesse com uma economia medida e validada, não um palpite otimista.
FinOps é um ciclo, não uma faxina
Veja o custo por workload, faça rightsizing para o uso real, consolide o que está ocioso, depois observe o drift e repita. As ferramentas (Kubecost, VPA, export de cobrança) existem para tornar esse ciclo barato de rodar, de modo que a economia se acumule em vez de se corroer.
O que eu diria a quem está começando isso
- Compre visibilidade primeiro. A alocação de custo por namespace reconciliada com a fatura real é a base sobre a qual todo o resto se apoia.
- Faça rightsizing com o VPA, mas fique de olho nele. É o padrão certo; não é certo para todo workload (especialmente serviços sensíveis à memória).
- Consolide com base em evidências. Dados reais de utilização transformam "talvez estejamos superprovisionados" em um corte específico e seguro na contagem de nodes.
- Faça do custo uma olhada diária, não um exercício de emergência trimestral. Picos são mais baratos de corrigir no dia em que acontecem.
Decisões e próximos passos
Uma visão retrospectiva da abordagem e seus limites. A próxima melhoria é uma proposta, não um resultado entregue.
Alternativa e justificativa
Uma stack de métricas dedicada simplifica a coleta inicial; reutilizar uma stack compartilhada pode reduzir a duplicação, mas introduz acoplamento.
Trade-off
A alocação é um modelo de atribuição. Recursos e labels compartilhados afetam como os custos são atribuídos aos times.
O que eu melhoraria em seguida
Próxima melhoria: reconciliar a cobertura de alocação e medir quais recomendações os times adotam antes de afirmar impacto de otimização.