Custos & Cloud Billing

O Tear.ia aloca o custo real de infraestrutura Kubernetes por workload, time e namespace, cruzando o billing da sua cloud com os workloads descobertos pelo operator. O resultado aparece na página Custos: total do período, variação, custo diário, quanto cada time consome e o custo de cada workload.

O rateio é proporcional aos recursos de cada workload (CPU + memória, com 1 GiB ≈ 0,5 vCPU), o mesmo modelo usado por ferramentas de Cloud Cost Management. Nenhum agente adicional é instalado no cluster — a fonte é o billing export da cloud.

Provider suportado hoje: Google Cloud (GKE). AWS e Azure estão no roadmap.

Pré-requisito: Billing Export do GCP para BigQuery

O custo vem do billing export nativo do GCP. Para habilitar (uma vez por billing account):

1. No GCP Console, acesse Billing → Billing export
2. Habilite o Standard usage cost export para BigQuery, escolhendo (ou criando) um dataset — por exemplo, billing_export
3. Anote três valores: o Billing Account ID, o Project ID do projeto que hospeda o dataset e o nome do dataset

O export cria tabelas gcp_billing_export_v1_* no dataset. Clusters GKE já chegam identificados pela label gke_cluster_name — nenhuma configuração extra no cluster.

Latência: o billing export do GCP tem atraso de 24–48h. O custo exibido é sempre do dia anterior (D-1), e a primeira coleta só encontra dados após o primeiro dia completo de export.

Criar a Service Account (indispensável)

Crie uma service account dedicada para o Tear.ia — não reutilize uma existente. E atenção ao projeto certo:

Tenho vários projetos com clusters — preciso de uma service account por projeto? Não. O billing export é por billing account e consolida o custo de todos os projetos vinculados a ela num único dataset. A service account deve ser criada no projeto que hospeda o dataset de billing (o mesmo Project ID informado no Tear.ia), e com isso os clusters de qualquer projeto da billing account já aparecem na coleta — sem nenhuma permissão nos projetos dos clusters.

Passo a passo, no projeto que hospeda o dataset:

1. Acesse IAM & Admin → Service Accounts → Create service account (sugestão de nome: tear-ia-billing-reader)
2. Conceda exatamente duas roles, nesse projeto:
   • BigQuery Data Viewer (roles/bigquery.dataViewer)
   • BigQuery Job User (roles/bigquery.jobUser)

A service account só precisa ler o dataset de billing — nenhum acesso de escrita, nenhum acesso aos clusters e nenhuma permissão nos demais projetos.

Se você tiver mais de uma billing account (cenário raro), aí sim são necessários um export e uma configuração por billing account — hoje o Tear.ia suporta uma configuração de billing por conta.

Autorizar o Tear.ia (sem chave — recomendado)

Nenhuma chave JSON é gerada, colada ou armazenada. O Tear.ia acessa o billing impersonando a service account que você criou — mesmo modelo usado por integrações como a do Datadog. Para autorizar:

1. Em Configurações → Integrações → Cloud Billing no Tear.ia, copie o principal do Tear.ia exibido no passo 1 do formulário
2. No GCP Console, abra a service account criada → aba Permissions → Grant Access
3. Cole o principal do Tear.ia e atribua a role Service Account Token Creator (roles/iam.serviceAccountTokenCreator)
4. Clique em Save

Pronto: você concedeu ao Tear.ia apenas o direito de agir como essa service account — que por sua vez só lê o dataset de billing. Para revogar o acesso a qualquer momento, basta remover o principal do Tear.ia da service account.

Configurar no Tear.ia

Em Configurações → Integrações → Cloud Billing (requer perfil admin):

Após salvar, a coleta roda automaticamente uma vez por dia. O card mostra o modo de autenticação, a última coleta e quantos workloads foram cobertos.

Modo legado por chave JSON: se a sua organização não permitir impersonation, o formulário aceita alternativamente a chave JSON da service account (opção "legado" no passo 3). Nesse modo a chave fica criptografada, é write-only e precisa ser recolada para qualquer atualização — recomendamos migrar para o modo sem chave assim que possível.

Lendo a página Custos

• Total no período — soma do custo alocado nos últimos 7, 30 ou 90 dias
• Variação — comparação com o período imediatamente anterior (subir é vermelho, cair é verde)
• Custo diário — série dia a dia; dias sem coleta aparecem como zero
• Custo por time — o rateio agregado pelo time dono de cada workload (via .titlis/service.yaml ou annotation); workloads sem dono aparecem em (sem time)
• Workloads — tabela com busca e filtro por time, com total do período e média diária

Workloads sem time atribuído continuam com o custo contabilizado — apenas não agrupado. Para atribuir donos, veja o módulo de Configurações.

AWS e Azure

O card de Integrações já indica os próximos providers. A arquitetura de coleta é agnóstica de cloud — quando AWS Cost Explorer e Azure Cost Management entrarem, a configuração seguirá o mesmo fluxo de credenciais write-only, sem mudanças na página Custos.