Às vezes não é bug que te acorda às 2h, é a integração entre ferramentas: métricas sumiram no Grafana porque o Prometheus não estava olhando para o Cilium; esse tipo de problema — a chamada "taxa de integração" — é o que consome a maior parte do tempo das equipes de plataforma. Neste artigo eu descrevo por que stacks cloud native bem instalados ainda quebram quando precisam conversar, exemplos reais de colisões entre projetos (cert-manager vs ingress; Prometheus vs kubelet), e o padrão que ajudou a tornar tudo sustentável: GitOps em dois repositórios, geração de monitoramento com Jsonnet, NetworkPolicies embutidas em charts, recuperação de desastres automatizada no bootstrap, segredos criptografados no Git e políticas aplicadas por máquinas.
Lembro bem da primeira vez que perdemos sono por algo que não era um bug.
Era madrugada quando os painéis do Grafana ficaram em branco para métricas de rede do Cilium, enquanto o Hubble exibia DNS, fluxos TCP e latência HTTP normalmente.
O culpado não foi o Cilium nem o Hubble: o Prometheus simplesmente não tinha ServiceMonitors apontando para os pods do agente e do operador do Cilium.
Dois projetos CNCF instalados corretamente, mas invisíveis um ao outro — essa é a tal “taxa de integração”.
Na prática, embora o universo CNCF tenha centenas de projetos, em produção a maioria das plataformas tende a se apoiar em um núcleo de 20–30 ferramentas que precisam se integrar bem para entregar valor.
Instalar cada projeto é só o começo; grande parte do trabalho diário é justamente fazer o “wiring” entre eles para que falem corretamente.
Um exemplo recorrente é o conflito entre cert-manager e controladores de ingress: o desafio ACME HTTP-01 espera servir um token em HTTP, mas se o ingress força redirect para HTTPS a validação é 301 e o solver do cert-manager nunca recebe o token.
A saída adotada foi migrar para DNS-01 com provedores de DNS cloud, o que, por sua vez, exige concessões de IAM específicas que quase nenhum chart resolve automaticamente.
Outro caso interessante envolve Prometheus e kubelet: o kubelet expõe métricas em vários caminhos e alguns deles emitem o mesmo process_start_time_seconds, levando o Prometheus a coletar amostras duplicadas e a gerar alertas barulhentos de timestamps duplicados.
Corrigir isso não foi questão de bug, mas de relabeling: descartamos um endpoint inteiro com uma regra gerada (Jsonnet) e o alerta sumiu — uma solução que só aparece quando se entende o comportamento conjunto das peças.
Para lidar com esses problemas de forma sustentável, adotamos o Cluster API para padronizar provisionamento e operações de nós entre clouds, o que simplificou upgrades e recuperações ao permitir que recursos reconciliassem o estado desejado.
Com CAPI integrado ao fluxo de GitOps, recriar um cluster deixou de ser um procedimento manual por cloud e passou a ser reconstituído automaticamente a partir do estado no repositório e dos backups do Velero.
A arquitetura que finalmente diminuiu a dor foi a divisão GitOps em dois repositórios: um repositório de plataforma com centenas de charts e defaults testados, e um repositório de configuração por cliente ou ambiente contendo apenas o que varia entre clusters.
Assim, correções na plataforma — por exemplo, a regra de relabeling do Prometheus — propagam-se para todos os clusters via atualização de versão, sem necessidade de tocar cada ambiente individualmente.
Algumas práticas se mostraram cruciais em produção: gerar o monitoramento em vez de montá-lo à mão, usando Jsonnet para produzir um kube-prometheus reprodutível, diffável e versionado.
Também passamos a embutir Cilium NetworkPolicies diretamente nos Helm charts, declarando requisitos de egress por serviço, em vez de tentar deduzir regras a partir de logs de fluxo após o deploy.
Automatizar a recuperação de desastres já no bootstrap — criando buckets para Velero durante o provisionamento inicial — transformou DR de uma tarefa esporádica em algo testável e confiável.
Segredos são sempre criptografados antes de entrarem no Git com Sealed Secrets, e a chave de decriptação é armazenada em backup, fazendo do repositório uma fonte auditável do estado completo do cluster.
Ferramentas de política e compliance como Kyverno e scanners como Kubescape, combinadas com a segmentação de rede do Cilium, garantem que a postura de segurança seja verificável tanto no Git quanto no cluster vivo.
Por fim, a taxa de integração não é um custo único: ela se acumula a cada upgrade de Kubernetes, de charts ou a cada novo projeto adotado; tratar a integração como código é o que transforma esse débito em algo administrável.
No fim das contas, o ecossistema CNCF é muito poderoso, mas só vira uma plataforma confiável quando o trabalho de conectar suas peças é tratado com prioridade.
