Kubernetes Multi-cluster: Quando Um Cluster Não Basta (e o Preço de Ter Vários)

Um cluster de Kubernetes bem operado aguenta uma quantidade surpreendente de carga. Dá para rodar dezenas de times, centenas de aplicações e milhares de Pods num único cluster bem dimensionado, com namespaces, quotas e políticas separando quem é de quem. Por isso, o primeiro conselho honesto sobre multi-cluster é contraintuitivo: na dúvida, não faça. Comece com um cluster, extraia o máximo dele, e só parta para vários quando existir um motivo concreto que um cluster único genuinamente não resolve. Multi-cluster não é um troféu de maturidade; é uma escolha de arquitetura que multiplica o custo operacional e só se paga quando o problema que ele resolve é real.

Dito isso, os motivos concretos existem, e são bons. Chega um ponto em que a resposta certa deixa de ser "um cluster maior" e passa a ser "mais clusters". Este guia percorre quando esse ponto chega, quais são as topologias que fazem sentido, como aplicações em clusters diferentes se encontram e como se distribui configuração por uma frota — e, crucialmente, quanto essa capacidade custa em complexidade operacional, porque essa é a parte que os slides de fornecedor sempre omitem.

Os motivos que realmente justificam vários clusters#

Nem todo motivo é bom, então vale separar o joio do trigo. Estes são os que se sustentam:

• Isolamento de blast radius. Um cluster é um domínio de falha. Um upgrade ruim do control plane, uma configuração de rede quebrada, um Operator descontrolado — qualquer um pode afetar tudo que roda ali. Separar produção de ambientes menos críticos, ou separar cargas de tolerância a risco muito diferente, limita o estrago quando algo dá errado. Se um cluster cair, o outro continua.
• Região e latência. Usuários no Brasil e usuários na Europa merecem baixa latência, e a física não negocia. Rodar clusters próximos a cada população de usuários é uma razão sólida e clássica para multi-cluster geográfico.
• Soberania de dados e conformidade. Regulações que exigem que dados de cidadãos de um país permaneçam naquele país (ou naquele bloco) empurram para clusters por jurisdição. Não é uma escolha de engenharia; é uma obrigação legal que a arquitetura precisa refletir.
• Separação de ambientes. Manter produção e não-produção em clusters fisicamente distintos elimina a chance de um teste em homologação tocar em produção, e permite políticas, acessos e janelas de manutenção radicalmente diferentes.
• Limites de escala do control plane. Existe um teto prático para o tamanho de um único cluster — número de nós, densidade de Pods, volume de objetos no etcd, pressão sobre o API Server. Cargas gigantes acabam esbarrando nesses limites, e dividir em clusters é a saída.

Perceba o que não está na lista: "porque é mais moderno", "porque a outra empresa faz", ou "porque um cluster parece arriscado demais na intuição". Se o seu motivo não é um dos de cima, provavelmente você ainda não precisa.

O fantasma da federação v1#

Quem pesquisa o tema esbarra rápido na palavra "federação", e aqui é preciso contar a história para não repetir o erro. Houve uma tentativa ambiciosa, o KubeFed (Kubernetes Cluster Federation, nas versões v1 e v2), de tratar múltiplos clusters como se fossem um só a partir de um plano de controle central que "empurrava" recursos federados para todos. A ideia era criar um Deployment federado e ele aparecer magicamente em todos os clusters. Na prática, o modelo foi problemático: acoplamento forte, um ponto central de falha, dificuldade de lidar com as diferenças reais entre clusters, e uma abstração que vazava o tempo todo. A comunidade foi esfriando o KubeFed, e a indústria convergiu para um caminho diferente e mais robusto: em vez de uma federação que abstrai os clusters, um modelo hub/spoke com GitOps, em que o estado desejado de cada cluster vive no Git e uma ferramenta de entrega o aplica em cada um. Não se tenta fingir que os clusters são um só; trata-se cada um como o que é, e centraliza-se a fonte da verdade, não o plano de controle. Entender essa virada evita que você procure por uma "federação mágica" que a comunidade já concluiu ser a abordagem errada.

Topologias: escolha a forma do problema#

A topologia certa depende de qual dos motivos acima está te empurrando para multi-cluster.

A separação por ambiente é a mais simples e comum: clusters distintos para produção, homologação e desenvolvimento. Cada um tem seu isolamento, suas políticas e seus acessos. É frequentemente o primeiro passo de qualquer jornada multi-cluster.

A distribuição por região aparece quando latência ou soberania mandam. Você replica a mesma stack em clusters de regiões diferentes, e roteia cada usuário para o mais próximo — tipicamente com DNS geográfico ou um balanceador global na frente. Aqui surge a distinção ativo-ativo versus ativo-passivo: no ativo-ativo, todos os clusters regionais servem tráfego simultaneamente, o que exige lidar com consistência de dados entre regiões; no ativo-passivo, um cluster é primário e o outro fica em espera para assumir num desastre, o que é mais simples mas desperdiça capacidade.

O isolamento por tenant é a topologia de quem oferece um cluster (ou um conjunto) por cliente, por questão de segurança ou contrato. É o extremo do isolamento de blast radius, e o que mais cobra em custo operacional, porque a frota cresce com a base de clientes.

Como aplicações se encontram entre clusters#

Dentro de um cluster, service discovery é trivial: o DNS interno resolve o nome do Service e pronto. Entre clusters, o problema fica genuinamente difícil, porque cada cluster tem seu próprio espaço de rede e seu próprio DNS. Existem algumas abordagens.

A mais direta é expor o serviço de um cluster através de um Ingress ou balanceador e consumi-lo do outro como se fosse um serviço externo — simples, mas você perde a naturalidade do discovery interno e assume a latência e a segurança de tráfego que sai e volta pela borda. A mais sofisticada é um service mesh multi-cluster, que estende a malha para além de um cluster e permite que um serviço no cluster A chame um serviço no cluster B pelo nome, com mTLS e políticas de tráfego, como se estivessem no mesmo lugar. Há ainda soluções de conectividade de rede dedicadas, que criam um plano de rede plano entre clusters para que Pods de um alcancem Services de outro diretamente. Qualquer que seja o caminho, a lição é: comunicação entre clusters é uma decisão de arquitetura séria, com implicações de latência, segurança e complexidade — não é algo que "simplesmente funciona" como o DNS interno de um cluster único.

GitOps é o que torna a frota gerenciável#

A peça que transforma "gerir vários clusters" de pesadelo em processo é o GitOps aplicado à frota. Em vez de fazer kubectl apply cluster por cluster (imagine isso com vinte clusters), você declara o estado desejado no Git e uma ferramenta como o Argo CD o reconcilia em cada cluster registrado. O recurso que brilha aqui é o ApplicationSet, que gera automaticamente uma aplicação para cada cluster de uma lista, a partir de um único template. Você descreve uma vez "esta stack, com estas variações por cluster", e ela é implantada consistentemente na frota inteira:

```yaml apiVersion: argoproj.io/v1alpha1 kind: ApplicationSet metadata: name: plataforma-base spec: generators:

• clusters: {} # gera uma app para cada cluster registrado no Argo CD

template: metadata: name: 'base-{{name}}' spec: project: default source: repoURL: https://git.exemplo.io/infra/base.git targetRevision: main path: 'base' destination: server: '{{server}}' namespace: plataforma syncPolicy: automated: prune: true selfHeal: true ```

Com selfHeal: true, qualquer alteração manual num cluster é revertida para o que o Git diz — o que ataca diretamente a doença mais crônica das frotas, o drift. Para o provisionamento dos próprios clusters (e não só do que roda dentro deles), o Cluster API leva a mesma filosofia declarativa um nível abaixo: você descreve o cluster desejado como um recurso do Kubernetes, e um controlador o cria e mantém. Cluster vira, ele mesmo, gado gerenciável por Git.

Onde ficam os dados — o problema que ninguém resolve de graça#

Distribuir aplicações stateless por vários clusters é relativamente tratável. Distribuir dados é o problema difícil que multi-cluster não faz desaparecer — apenas explicita. Se dois clusters regionais precisam da mesma informação atualizada, você caiu no teorema fundamental dos sistemas distribuídos: replicação síncrona custa latência, replicação assíncrona custa consistência, e não existe almoço grátis. A maioria das arquiteturas multi-cluster bem-sucedidas evita compartilhar estado mutável entre clusters sempre que pode, particionando os dados por região ou tenant, ou elegendo um cluster como dono da escrita. Antes de espalhar clusters pelo mundo, decida onde os dados moram e como (ou se) eles se replicam — porque essa decisão define, mais do que qualquer outra, o quão viável a sua topologia realmente é.

As armadilhas — o custo que os slides omitem#

A primeira e mais universal: o custo operacional é linear, não amortizado. Dobrar o número de clusters tende a dobrar o trabalho de manutenção — upgrades, patches, monitoração, resposta a incidentes, gestão de acesso. Ferramentas de frota ajudam, mas não zeram esse custo. Um time que adota multi-cluster sem crescer sua capacidade operacional simplesmente se afoga mais rápido.

A segunda: drift entre clusters. Sem uma disciplina rígida de GitOps, os clusters divergem. Um recebeu um patch manual, outro não; um está numa versão de Kubernetes, outro em outra. Cada divergência é uma surpresa esperando o pior momento para aparecer. A cura é fazer tudo passar pelo Git e usar self-heal para eliminar alterações manuais.

A terceira: versões de Kubernetes desalinhadas. Manter uma frota na mesma versão, ou em versões controladamente escalonadas, é um trabalho contínuo. Deixar cada cluster envelhecer no seu ritmo cria uma matriz de compatibilidade impossível de raciocinar.

A quarta: complexidade de rede. Conectividade e discovery entre clusters, como vimos, é difícil. Cada canal entre clusters é uma superfície nova de latência, de falha e de segurança que não existia no cluster único.

A quinta, a mais insidiosa: o "cluster de neve" — o cluster configurado à mão, único, que ninguém sabe reproduzir. Num cluster só, já é ruim. Numa frota, é fatal, porque quebra a premissa de que os clusters são gado uniforme. Todo cluster deve nascer de um processo automatizado e reproduzível; o dia em que você tem um cluster que só existe porque alguém digitou comandos que ninguém anotou, você perdeu o controle da frota.

Fechando#

Multi-cluster no Kubernetes é uma resposta legítima para problemas reais — blast radius, latência regional, soberania de dados, separação de ambientes, limites de escala — e não deveria ser adotado por nenhum outro motivo. A abordagem madura abandonou o sonho da federação que abstrai clusters em um só, e abraçou o modelo hub/spoke com GitOps, onde a fonte da verdade é centralizada no Git e ferramentas como Argo CD (com ApplicationSets) e Cluster API mantêm a frota consistente e reproduzível. O que nenhuma ferramenta resolve de graça são os dois problemas duros: onde os dados moram e como as aplicações se encontram entre clusters. E o preço — o custo operacional linear, o drift, o desalinhamento de versões, a complexidade de rede — é real e precisa ser orçado com honestidade. Comece com um cluster. Cresça para vários quando o motivo for concreto. E, ao crescer, trate cada cluster como gado gerado por processo, nunca como bicho de estimação configurado à mão — porque é essa disciplina, mais do que qualquer tecnologia, que separa uma frota sob controle de uma coleção de clusters de neve à beira do caos.