O provedor cobra a máquina, não o workload
A conta de um cluster gerenciado é, quase toda, composta de instâncias, discos, balanceadores e transferência de dados. Nenhum desses itens sabe o que é um namespace. Do ponto de vista do billing, um nó rodando trinta pods de seis equipes diferentes é uma linha só, com um preço só. É por isso que a fatura de uma empresa que roda tudo em Kubernetes tende a ser a mais opaca de todas: quanto mais eficiente o empacotamento, menos a fatura revela sobre quem consumiu.
O que a tag do nó consegue e não consegue dizer
Tags aplicadas aos node groups resolvem uma parte real do problema. Um cluster dedicado a um ambiente ou a um produto pode ser alocado inteiro por tag, sem nenhuma instrumentação adicional, e isso já cobre mais casos do que se costuma supor. Separar produção de não-produção, ou um node group por área, transforma um bloco cego em várias linhas atribuíveis.
O limite aparece no cluster compartilhado. Quando várias equipes dividem os mesmos nós, a tag descreve a infraestrutura, não o consumo. Para chegar ao pod é preciso combinar o custo do nó com métricas de uso do cluster (request, limite e consumo real por namespace), que vivem fora do dado de billing.
Request contra uso: duas contas diferentes
A decisão mais consequente do rateio de Kubernetes é se a equipe paga pelo que pediu ou pelo que usou. Cobrar pelo uso parece justo e premia quem superdimensiona: o request reservado bloqueia capacidade no nó mesmo ocioso, e alguém acaba pagando por ele. Cobrar pelo request cria o incentivo certo (pedir de perto do necessário), mas exige explicar por que a soma dos rateios não fecha com a fatura, já que a capacidade não reservada continua existindo.
Não há resposta universal. Há uma regra: escolha uma, documente e não mude no meio de um trimestre.
O custo ocioso do cluster é o número que importa
A diferença entre a capacidade provisionada e a capacidade requisitada é o desperdício estrutural do cluster, e costuma ser maior que qualquer economia que se consiga negociando preço. Ele não pertence a nenhuma equipe: é resultado de escolhas de tamanho de nó, política de escala e headroom para picos. Tratá-lo como custo compartilhado e mostrá-lo separado é mais honesto do que diluí-lo silenciosamente entre os namespaces, porque só assim ele vira alvo de alguém.
O que dá para fazer sem instalar nada
Sem agente no cluster, o billing ainda sustenta bastante coisa: separar o custo de cada cluster, comparar a evolução entre períodos, alocar node groups por tag, detectar anomalia no gasto do cluster, identificar discos órfãos de volumes persistentes já removidos e avaliar compromisso sobre o piso estável de nós. É menos granular que um rateio por pod, e é o que se pode afirmar com o dado que a nuvem realmente entrega.
Custo e continuidade olham o mesmo cluster
Vale notar quem mais paga a conta do armazenamento: volumes persistentes, snapshots e backups retidos por políticas antigas. Uma política de retenção definida uma vez e nunca revisada aparece na fatura todo mês, e é uma das poucas reduções de custo que não envolve risco de disponibilidade, desde que a decisão seja tomada olhando junto o que a empresa precisa conseguir restaurar.
O que o billing sustenta, com o rigor que ele permite
O Seawise Compass separa o custo por cluster, aloca node groups pelas tags que já existem, compara a evolução entre períodos e trata o gasto sem alocação como um número visível, em vez de escondê-lo num rateio que ninguém consegue explicar.
Conheça alocação no Seawise Compass →