Multi-cluster management: Federation ou Cluster API

1. Introdução ao Gerenciamento Multi-Cluster

Em ambientes modernos de DevOps, a adoção de múltiplos clusters Kubernetes tornou-se uma necessidade estratégica. As motivações incluem isolamento de ambientes (produção, staging, desenvolvimento), distribuição geográfica para reduzir latência, escalabilidade horizontal e conformidade com regulamentações de dados (GDPR, LGPD). No entanto, gerenciar dezenas ou centenas de clusters manualmente é inviável. Os principais desafios são consistência de configuração (versões de workloads, políticas de rede), observabilidade unificada e custos operacionais crescentes.

Duas abordagens dominam o ecossistema: Kubernetes Federation (KubeFed) e Cluster API (CAPI). Enquanto a Federation foca na replicação de workloads entre clusters, a Cluster API automatiza o provisionamento e ciclo de vida da infraestrutura. Soluções gerenciadas como GKE Multi-Cluster e Amazon EKS Anywhere complementam, mas exigem vendor lock-in. Este artigo explora ambas as estratégias com exemplos práticos, sob a perspectiva de DevOps + Docker + Kubernetes.

2. Kubernetes Federation (KubeFed)

KubeFed adota um modelo de controle centralizado: um Host Cluster gerencia a propagação de recursos para Member Clusters. Os componentes principais incluem:

  • API Types: FederatedDeployment, FederatedService, FederatedConfigMap
  • Propagation: controlador que distribui recursos baseado em políticas de placement
  • Override: permite customizações por cluster (ex: réplicas diferentes por região)

Exemplo prático: FederatedDeployment

Suponha que você queira replicar um deployment Nginx para dois clusters: us-east e eu-west. Primeiro, instale o KubeFed no cluster host:

kubectl apply -f https://github.com/kubernetes-sigs/kubefed/releases/latest/download/kubefed.yaml
kubefedctl join us-east --host-cluster-context=host --cluster-context=us-east
kubefedctl join eu-west --host-cluster-context=host --cluster-context=eu-west

Agora, crie um FederatedDeployment:

apiVersion: types.kubefed.io/v1beta1
kind: FederatedDeployment
metadata:
  name: nginx-federated
  namespace: default
spec:
  template:
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
          - name: nginx
            image: nginx:1.25
            ports:
            - containerPort: 80
  placement:
    clusters:
    - name: us-east
    - name: eu-west
  overrides:
  - clusterName: eu-west
    clusterOverrides:
    - path: /spec/replicas
      value: 5

Aplique o manifesto no cluster host:

kubectl apply -f federated-deployment.yaml

O KubeFed propaga o deployment para ambos os clusters, com 3 réplicas em us-east e 5 em eu-west. A reconciliação contínua garante que alterações no host sejam refletidas nos members, mas conflitos manuais podem exigir override explícito.

3. Cluster API (CAPI)

Cluster API adota uma abordagem declarativa para provisionamento e gerenciamento do ciclo de vida de clusters. Diferente da Federation, CAPI opera na camada de infraestrutura, usando Providers específicos:

  • Infrastructure providers: AWS, Azure, vSphere, GCP
  • Bootstrap providers: Kubeadm, EKS, AKS

Exemplo prático: Criação de cluster worker via Cluster API

Primeiro, instale o Cluster API em um cluster de bootstrap (management cluster):

clusterctl init --infrastructure aws

Crie um manifesto YAML para provisionar um cluster worker na AWS:

apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: capi-worker-cluster
  namespace: default
spec:
  clusterNetwork:
    pods:
      cidrBlocks:
      - 10.96.0.0/12
    services:
      cidrBlocks:
      - 10.32.0.0/16
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
    kind: AWSCluster
    name: capi-worker-cluster
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
kind: AWSCluster
metadata:
  name: capi-worker-cluster
  namespace: default
spec:
  region: us-east-1
  sshKeyName: devops-key
---
apiVersion: cluster.x-k8s.io/v1beta1
kind: MachineDeployment
metadata:
  name: worker-md-0
  namespace: default
spec:
  clusterName: capi-worker-cluster
  replicas: 3
  template:
    spec:
      bootstrap:
        dataSecretName: worker-bootstrap-data
      infrastructureRef:
        apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
        kind: AWSMachineTemplate
        name: worker-machine-template

Aplique o manifesto:

kubectl apply -f capi-worker-cluster.yaml

O Cluster API cria automaticamente instâncias EC2, configura o kubeadm e gera o kubeconfig. Para destruir o cluster:

kubectl delete cluster capi-worker-cluster

CAPI trata o cluster como um recurso Kubernetes, permitindo integração direta com GitOps.

4. Comparação Técnica: Federation vs. Cluster API

Aspecto Federation (KubeFed) Cluster API (CAPI)
Escopo Workloads (deployments, services) Infraestrutura (VMs, redes, clusters)
Modelo Centralizado (host cluster) Declarativo (management cluster)
Complexidade Média (overrides manuais) Alta (múltiplos providers)
GitOps Integração com ArgoCD via ApplicationSet Nativo (cluster como recurso GitOps)
Casos de uso Aplicações multi-região estáveis Ambientes efêmeros, multi-cloud

Federation é ideal para replicar workloads com consistência, mas não gerencia a infraestrutura subjacente. Cluster API automatiza o provisionamento, mas requer conhecimento profundo de providers. Em cenários híbridos, ambas podem coexistir: CAPI cria clusters, Federation replica aplicações.

5. Integração com DevOps e Docker/Kubernetes

Pipeline CI/CD multi-cluster

Com ArgoCD, é possível fazer deploy simultâneo via Federation ou CAPI. Exemplo de ApplicationSet para Federation:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: multi-cluster-app
spec:
  generators:
  - clusters:
      selector:
        matchLabels:
          type: member
  template:
    spec:
      source:
        repoURL: https://github.com/devops/app-config
        path: overlays/{{name}}
      destination:
        server: '{{server}}'
        namespace: default

Para CAPI, o cluster é um recurso no management cluster, então o ArgoCD pode sincronizar diretamente.

Estratégias de Docker image tagging

Para rollouts canary em múltiplos clusters, use tags semânticas:

# Pipeline CI
docker build -t app:1.2.3-canary .
docker push app:1.2.3-canary

# Deploy canary no cluster us-east
kubefedctl federate deployment app --cluster us-east --image app:1.2.3-canary

Após validação, promova para stable:

kubefedctl federate deployment app --cluster us-east,eu-west --image app:1.2.3

Observabilidade unificada

Prometheus + Thanos permite consultar métricas cross-cluster:

# Configuração Thanos Sidecar no cluster us-east
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: prometheus
spec:
  containers:
  - name: prometheus
    image: prom/prometheus:v2.45
  - name: thanos-sidecar
    image: thanosio/thanos:v0.32
    args:
    - sidecar
    - --tsdb.path=/prometheus
    - --objstore.config-file=/etc/thanos/bucket.yaml

6. Segurança e Governança Multi-Cluster

Políticas de RBAC e Network Policies devem ser replicadas. Com Federation, use FederatedNetworkPolicy:

apiVersion: types.kubefed.io/v1beta1
kind: FederatedNetworkPolicy
metadata:
  name: deny-all
spec:
  template:
    spec:
      podSelector: {}
      policyTypes:
      - Ingress
  placement:
    clusters:
    - name: us-east
    - name: eu-west

Com Cluster API, aplique políticas via OPA/Gatekeeper no management cluster, que serão herdadas pelos workers.

Gerenciamento de secrets: use External Secrets Operator para sincronizar secrets do AWS Secrets Manager ou Azure Key Vault entre clusters. Cert-manager garante certificados TLS unificados.

Para compliance, ferramentas como Polaris e Falco podem ser executadas como DaemonSet em cada cluster, com logs centralizados no management cluster.

7. Custos, Backup e Recuperação

Custo de operação

Federation adiciona overhead de controle no host cluster (CPU/memória para reconciliação). Para 10 clusters, o custo é fixo. Cluster API reduz custos de infraestrutura sob demanda, pois clusters efêmeros são destruídos quando não usados.

Disaster recovery com Velero

Para backup de objetos federados:

velero install --provider aws --bucket backups --backup-location-config region=us-east-1
velero backup create federation-backup --include-namespaces default --include-resources FederatedDeployment,FederatedService

Para clusters gerenciados por CAPI, faça backup do management cluster inteiro:

velero backup create capi-mgmt-backup --include-cluster-scoped-resources

Right-sizing e spot instances

Cluster API permite usar spot instances para workers:

apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
kind: AWSMachineTemplate
spec:
  template:
    spec:
      spotMarketOptions:
        maxPrice: "0.10"

Isso reduz custos em até 70% para cargas de trabalho não críticas.

8. Conclusão e Recomendações Finais

Escolha Federation (KubeFed) quando:
- Workloads são estáveis e precisam de replicação simples entre regiões
- Compliance exige políticas centralizadas (ex: GDPR)
- A infraestrutura já está provisionada e não muda com frequência

Escolha Cluster API (CAPI) quando:
- Ambientes são efêmeros (CI/CD, testes, preview environments)
- Automação de infraestrutura é prioridade (multi-cloud, on-premises)
- Você precisa de escalabilidade dinâmica (auto-scaling de clusters)

Tendências futuras: O GitOps está se consolidando como camada unificadora. Ferramentas como ArgoCD e Flux podem gerenciar tanto recursos federados quanto clusters CAPI. O futuro do multi-cluster management aponta para abstrações ainda mais altas, como o Kuberentes Multi-Cluster SIG e o Open Cluster Management (OCM).

Referências