Automatize a integração CNCF com GitOps e Jsonnet e recupere 80% do tempo da sua equipe de plataforma

Você abriu o Grafana. Os painéis do Cilium estavam em branco. O Prometheus rodava, o Cilium operava, mas nenhuma métrica aparecia. Esse incidente real expõe o “imposto de integração” – o custo invisível de conectar projetos CNCF. Na produção multi-cloud, ele consome até 80% do tempo das equipes de plataforma. Este artigo mostra como automatizar essa fiação e transformar seu stack em uma plataforma confiável.

O que é o imposto de integração? (E por que você já pagou por ele)

O ecossistema CNCF é um paraíso de escolha. Prometheus, cert-manager, Cilium, Kyverno, ArgoCD – cada projeto é maduro e bem documentado. Mas a documentação termina na fronteira de cada ferramenta. Quem ensina como cert-manager negocia com seu ingress controller? Quem configura os ServiceMonitors para que o Cilium apareça no Prometheus? Ninguém. Esse trabalho fica para você.

Falhas comuns que confirmam a regra

• cert-manager + HTTP-01: o Ingress Controller força redirect para HTTPS, quebrando o HTTP-01. Solução? DNS-01 com IAM por nuvem. Nenhum Helm chart faz isso por padrão.
• kubelet + Prometheus: métricas duplicadas em /metrics e /metrics/probes geram alertas falsos. A correção exige regras de relabeling em Jsonnet – código que ninguém escreve de início.
• Cilium + Prometheus: ServiceMonitors inexistentes. O Prometheus coleta métricas do kubelet e do coredns, mas o Cilium fica invisível.

O imposto de integração não é um bug. É um gap de design do ecossistema. Automatizar a fiação entre projetos é o que separa um stack que sobrevive ao segundo ano de um amontoado de ferramentas.

A solução: arquitetura GitOps de dois repositórios

A base para eliminar o imposto de integração é uma arquitetura GitOps de dois níveis:

• Repositório de plataforma: contém os charts genéricos, configurações de monitoramento (Jsonnet), NetworkPolicies, Sealed Secrets e políticas Kyverno. É o “core” da sua plataforma.
• Repositório de configuração: contém valores por ambiente (dev, staging, prod), secrets criptografados e overrides específicos de cada cluster.

O ArgoCD assiste ambos os repositórios. Uma mudança no repositório de plataforma é propagada para todos os clusters via version bump. Uma mudança no repositório de config afeta apenas o ambiente alvo.

Por que dois repositórios? Centraliza a lógica de integração sem misturar dados sensíveis. Permite testar novos charts em staging antes da produção. Facilita disaster recovery: o bootstrap do cluster reaplica tudo a partir do Git, sem estado manual.

Geração de monitoramento com Jsonnet: adeus ao YAML manual

O kube-prometheus stack é poderoso, mas seus manifestos YAML são enormes e cheios de duplicação. Jsonnet resolve isso: você define um único arquivo de variáveis e gera tudo programaticamente.

Exemplo prático: o problema do kubelet com métricas duplicadas. Com Jsonnet, você adiciona uma regra de relabeling em um ponto central:

// main.jsonnet
local kp = (import 'kube-prometheus/main.libsonnet') + {
  kubelet: {
    serviceMonitor: {
      spec: {
        endpoints: [
          {
            port: 'https-metrics',
            scheme: 'https',
            tlsConfig: { insecureSkipVerify: true },
            relabelings: [
              { sourceLabels: ['__metrics_path__'], targetLabel: 'metrics_path' },
              { action: 'drop', sourceLabels: ['__metrics_path__'], regex: '/metrics/probes' }
            ],
          },
        ],
      },
    },
  },
};

Um único diff no Jsonnet já mostra o impacto. E quando você precisa adicionar ServiceMonitors para o Cilium, basta estender a lib:

ciliumServiceMonitor: {
  apiVersion: 'monitoring.coreos.com/v1',
  kind: 'ServiceMonitor',
  ...
}

Reprodutibilidade total. Se um cluster novo nasce, o Jsonnet gera os mesmos manifestos. Sem chance de “esquecer de marcar o checkbox”.

NetworkPolicies no Helm chart: segurança desde a origem

NetworkPolicies são frequentemente adicionadas como “calda” – depois que o deploy já está rodando. Isso gera drift de segurança e retrabalho. A abordagem correta é embutir as NetworkPolicies no próprio Helm chart do projeto.

Por exemplo, um chart do Cilium que já vem com regras de tráfego entre seus componentes:

# cilium/templates/networkpolicy.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: cilium-allow-prometheus
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: cilium-agent
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: monitoring
      podSelector:
        matchLabels:
          app.kubernetes.io/name: prometheus
    ports:
    - port: 9090
      protocol: TCP

Dessa forma, todo deploy já nasce seguro. O drift entre o que está no Git e o que está no cluster é zero.

Automação de disaster recovery no bootstrap

Recuperar um cluster do zero não pode ser um roteiro manual. A armadilha: backup do Velero + storage cloud, mas sem automação de restore. Solução?

• Sealed Secrets criptografa os secrets no repositório Git. A chave de decriptação (private key) é restaurada no bootstrap via secret externo (ex: AWS Secrets Manager ou GCP Secret Manager).
• Bootstrap script que instala ArgoCD, Velero, Sealed Secrets e restaura o último backup.

# bootstrap-example.sh
velero restore create --from-backup latest --wait
kubectl apply -f sealed-secrets-custom-resources.yaml
argocd app sync --all --prune

A chave do Sealed Secrets é o ponto único de falha. Se ela for perdida, todos os secrets criptografados no Git se tornam lixo. Gerencie-a com rotação e cópia off-line.

Políticas com Kyverno: governança sem intrusão

Kyverno permite validar, mutar ou gerar recursos Kubernetes sem modificar os charts originais. Exemplos de políticas que eliminam o imposto de integração:

• Gerar ServiceMonitor automaticamente para todo Pod que tenha label monitoring: cilium.
• Exigir que todo Deployment tenha NetworkPolicy associada (ou mutar para adicionar uma default).
• Bloquear uso de ServiceAccount default em namespaces críticos.

Mas cuidado: políticas mal ajustadas geram falsos positivos ou podem ser contornadas. Teste em staging antes de aplicar em produção.

Riscos e limitações (ninguém falou que era fácil)

• DNS-01 é específico de cada nuvem. cert-manager com DNS-01 exige IAM scoping (ex: route53 IAM role) que Helm charts não configuram por padrão. Isso cai de volta no imposto de integração – você precisa criar um Chart wrapper ou um Job de pós-instalação.
• Sealed Secrets key management: backup e rotação da chave de decriptação são críticos. Sem ele, você perde acesso ao cluster.
• Disciplina GitOps: erros no repositório de plataforma afetam todos os clusters. A revisão de PR e testes automatizados são obrigatórios.
• Upgrades: a cada nova versão de K8s, cada upgrade de Helm chart ou novo projeto CNCF, o imposto de integração acumula-se exponencialmente. A automação não elimina o custo, mas o transforma de manual em programático.

Impacto no mercado e no time de plataforma

Para equipes SRE e Platform Engineering, investir em automação de integração não é opcional – é o que separa plataformas que escalam de “brinquedos de laboratório”.

Oportunidades de mercado

• Consultorias e fornecedores de K8s gerenciado podem oferecer plataformas de integração pré-construídas (ex: um “ArgoCD + Jsonnet + Sealed Secrets + Kyverno” já com fiação pronta).
• Ferramentas como Jsonnet, ArgoCD, Sealed Secrets e Kyverno ganham relevância como parte de um stack de integração, não apenas como ferramentas isoladas.
• Empresas menores, sem equipes dedicadas, podem se beneficiar de soluções comerciais que abstraem o wiring – reduzindo a barreira de adoção CNCF.

Visão Metatron: o futuro da integração cloud native

O imposto de integração não desaparecerá. Mas ele pode ser automatizado e abstraído por camadas de plataforma. A evolução natural é que os próprios projetos CNCF comecem a gerar manifests de integração padrão – talvez via OpenAPI ou CRDs que descrevem dependências. Enquanto isso não acontece, a arquitetura GitOps com geração programática (Jsonnet) é o melhor antídoto.

No futuro, o time de plataforma não será o “time que instala ferramentas”, mas o time que projeta a fiação – e essa fiação estará codificada em um único repositório, versionada, testada e auto-recuperável. O monitoramento do Cilium nunca mais ficará em branco.

A pergunta que resta: sua equipe está pagando o imposto de integração em retrabalho manual ou investindo na automação que o elimina?

Comece hoje: revise seu repositório GitOps. Se você ainda roda kubectl apply manual para ServiceMonitors ou NetworkPolicies, está pagando juros sobre o imposto. Automatize a fiação e recupere 80% do tempo da sua equipe.