Skip to content
CPPS Docs

ADR-004 — Karmada deferido, Cilium ClusterMesh + ApplicationSet primeiro

Status

Vigente — 2026-05-01.

Contexto

CPPS opera 2 clusters K3s (Franca, SP). Pra workloads multi-site precisa de:

  1. Service discovery cross-cluster — pod em Franca chama service em SP por nome
  2. Deploy do mesmo manifest em N clusters
  3. Failover automático quando cluster cai (opcional)
  4. Scheduling baseado em capacidade/proximidade (opcional)

Opções consideradas:

  • Karmada: control plane federado (próprio API server, etcd, scheduler) que orquestra clusters como um meta-Kubernetes
  • Cilium ClusterMesh + ArgoCD ApplicationSet: ClusterMesh pra service discovery, ApplicationSet pra propagação de manifests
  • Liqo: alternativa open-source mais leve que Karmada
  • Status quo: deploy manual em cada cluster

Decisão

Começar com Cilium ClusterMesh + ArgoCD ApplicationSet. Karmada deferido.

Cobertura:

  • Service discovery cross-cluster: ClusterMesh ✓
  • Deploy multi-cluster: ApplicationSet ✓
  • Failover via DNS/Cloudflare ✓
  • Scheduling dinâmico: NÃO coberto — só com Karmada

Alternativas rejeitadas

  • Karmada agora: introduz control plane crítico (próprio API/etcd/scheduler) que precisa ser HA. Pra time de 1-3 admins com 2 clusters, custo operacional não compensa cobertura adicional.
  • Liqo: mais leve que Karmada mas menor adoção/comunidade; deferido junto com Karmada
  • Manual em cada cluster: viola princípio declarativo do GitOps

Consequências

Positivas:

  • Sem novo control plane crítico
  • ApplicationSet é nativo do ArgoCD que já está em produção
  • ClusterMesh integra com Cilium que será adotado de qualquer forma
  • Curva de aprendizado menor

Negativas:

  • Sem scheduling dinâmico cross-cluster (precisa decidir explicitamente onde rodar)
  • Sem rebalanceamento automático de cargas
  • Failover entre clusters depende de DNS/Cloudflare (não automático no nível K8s)
  • Workloads que exigem placement por capacidade GPU em tempo real ficam limitados (compensa com Kueue)

Critério de revisão

Reabrir adoção de Karmada se aparecerem dois ou mais dos sinais abaixo:

  1. Escala: 5+ clusters em produção (CPPS + cloud + sites institucionais)
  2. Scheduling dinâmico: workload precisa migrar automaticamente baseado em capacidade GPU/CPU
  3. Failover SLA-driven: SLA por cluster que ApplicationSet/DNS não atendam
  4. Bursting cloud automático: GPU lotou em SP → workload vai pra AWS sem intervenção manual
  5. Time dedicado a multi-cluster: alguém com >20% do tempo focado em federação

Pra MVP, nenhum desses sinais existe — Karmada permanece deferido.