Multi-Região e Multi-Cloud¶
Distribuir um cluster entre regiões só entrega disponibilidade se três decisões estiverem alinhadas: onde o usuário entra, onde a carga executa e onde o dado está. Esta página trata das duas primeiras — a terceira está em Cargas com Estado.
Nós identificados por região e zona¶
Cada worker node carrega informação de topologia que identifica sua localização física ou lógica. O Kubernetes usa esses rótulos para decidir onde cada carga pode executar.
A topologia da infraestrutura passa a fazer parte da política de agendamento da aplicação.
Com isso, uma aplicação pode exigir três réplicas com uma em br-sp-1, uma em br-sp-2 e uma na nuvem pública — ou restringir explicitamente uma carga:
Os mecanismos usados são os do próprio Kubernetes:
- Topology Spread Constraints — distribuição equilibrada entre zonas;
- Pod Anti-Affinity — réplicas do mesmo serviço em nós ou zonas diferentes;
- PodDisruptionBudget — piso de disponibilidade durante manutenção e upgrades;
- Node Affinity / seletores por zona — fixação de cargas que dependem de dados locais;
- Réplicas mínimas por região — garantia de presença em cada domínio de falha.
Balanceamento global com Cloudflare¶
Em arquiteturas multi-região, o tráfego externo é distribuído pelo Cloudflare Global Load Balancing, que leva em conta a disponibilidade dos endpoints e a estratégia geográfica da aplicação. Se uma região deixa de responder corretamente, o tráfego é direcionado para as regiões saudáveis.
Redirecionar tráfego não significa que o dado da aplicação esteja disponível na região de destino.
Útil para: failover regional, aplicações distribuídas globalmente, recuperação de desastres, redução de latência para o usuário final, distribuição de carga e manutenção regional programada.
Balanceador global não transforma uma aplicação em multi-região
O balanceamento decide para onde mandar o usuário. O Kubernetes decide onde executar. A arquitetura de dados garante onde o dado está disponível. As três camadas são complementares — colocar um balanceador global na frente de uma aplicação que só tem dados em uma região apenas encaminha usuários para um lugar que não consegue atendê-los.
Partição de rede entre regiões¶
Uma arquitetura multi-região precisa considerar não só a perda completa de um datacenter, mas também a partição de rede: os dois lados continuam funcionando, sem conseguir se comunicar entre si.
Para cargas sem estado, isso é tratado com réplicas, health checks e balanceamento — cada lado atende com o que tem.
Para cargas com estado, a arquitetura precisa prever quórum, eleição de líder, fencing, replicação, prevenção de split-brain e consistência de dados. Esses mecanismos são definidos por tecnologia, caso a caso — o que vale para o PostgreSQL não é o que vale para o Kafka. A InteSys avalia esse requisito junto com o desenho do cluster.
Se uma região perde conectividade¶
Cargas já em execução nos worker nodes não dependem continuamente do control plane para continuar rodando. Se um grupo de nós perde comunicação com a camada de gerenciamento:
- os contêineres existentes continuam executando e podem ser reiniciados localmente quando aplicável;
- novas decisões de agendamento e mudanças de estado que dependem da comunicação com o cluster ficam temporariamente limitadas;
- quando a conectividade volta, o Kubernetes retoma a reconciliação com o estado desejado.
Para cargas com estado, valem os mecanismos adicionais de quórum, replicação e proteção contra split-brain citados acima.
Custo não é igual em toda região¶
Capacidade computacional não tem o mesmo preço em todo lugar. Um worker na infraestrutura InteSys pode custar diferente de um worker equivalente em AWS, Azure, Google Cloud, DigitalOcean, OVHcloud ou Hetzner — e as diferenças aparecem em CPU, memória, armazenamento, IOPS, tráfego de saída, IPs públicos, balanceadores, snapshots, backups e tráfego entre regiões.
Essa diferença é usada como ferramenta de arquitetura:
| Carga | Onde costuma ficar |
|---|---|
| Carga crítica e sensível a latência | Região premium, com alta disponibilidade |
| Processamento assíncrono | Região de menor custo |
| Usuários europeus | Região europeia |
| Dados sob exigência de residência | Regiões brasileiras |
O preço é definido conforme a região e o provedor escolhidos para cada grupo de nós.
Sem lock-in de infraestrutura¶
Um cluster que não está preso a um único hyperscaler pode evoluir sem reconstruir a plataforma da aplicação em torno de serviços proprietários. Serviços específicos de um provedor continuam disponíveis quando trazem vantagem técnica — mas passam a ser uma escolha de arquitetura, não um requisito da plataforma Kubernetes.
Páginas Relacionadas¶
- Modelos de Implantação — Região única, multi-DC, híbrido e multi-cloud
- Cargas com Estado — Topologia de armazenamento e replicação
- Segurança da Plataforma — Cilium, hardening e ciclo de vida
- MySQL Multi-Região · PostgreSQL Multi-Região
- Recuperação de Desastres — RPO, RTO e failover entre regiões