Pular para conteúdo

Modelos de Implantação

O mesmo cluster gerenciado pode ser entregue em quatro arranjos diferentes. A escolha não é ideológica: ela decorre de onde estão os usuários, de quanto a indisponibilidade custa e de onde os dados podem estar.

Os quatro modelos de implantação, do mais simples ao mais distribuído, com evolução por fases

Cada modelo é um degrau: dá para começar no primeiro e evoluir sem reconstruir a plataforma.

1. Região única

A configuração mais simples usa worker nodes em uma única região — normalmente br-sp-1.

Indicado para: aplicações que atendem principalmente uma região geográfica, sem exigência de continuidade entre datacenters, com dados que precisam ficar próximos da aplicação e prioridade em simplicidade e custo. Benefício: menor custo, menor latência interna e a menor complexidade operacional possível. Limitação: um único domínio de falha — a perda da região é a perda do ambiente.

Mesmo nesse modelo o cluster continua sendo gerenciado: rede Cilium, políticas de segurança, atualizações controladas e monitoramento fazem parte do serviço.

2. Alta disponibilidade entre datacenters InteSys

Para aplicações críticas, os workers são distribuídos entre br-sp-1 (Cirion SAO1, Cotia/SP) e br-sp-2 (Equinix SP3, Tamboré/SP).

As duas regiões ficam na região metropolitana de São Paulo, mas operam em instalações físicas e provedores de infraestrutura diferentes, interligadas por links Lan2Lan ou túneis criptografados. A latência entre elas é de poucos milissegundos, o que mantém viável até replicação síncrona de banco.

Indicado para: produção crítica que precisa sobreviver à perda de um datacenter mantendo todos os dados no Brasil. Benefício: dois domínios de falha reais, sem sair da jurisdição brasileira e sem latência internacional. Limitação: não protege contra um evento que atinja simultaneamente a região metropolitana de São Paulo — para isso, um terceiro domínio em outra geografia.

O Kubernetes identifica a localização de cada nó por região e zona de disponibilidade, o que permite exigir distribuição automática entre zonas, pod anti-affinity, topology spread constraints, PodDisruptionBudgets e um número mínimo de réplicas por região.

3. Híbrido — InteSys + nuvem pública

O mesmo cluster combina infraestrutura InteSys e capacidade computacional de nuvem pública: AWS, Google Cloud, Microsoft Azure, DigitalOcean, OVHcloud, Hetzner ou infraestrutura do próprio cliente.

Um arranjo comum:

  • InteSys, Brasil — aplicação principal, bancos de dados e cargas sensíveis a latência;
  • Nuvem pública, EUA — processamento assíncrono e capacidade adicional;
  • Nuvem pública, Europa — atendimento a usuários europeus.

Indicado para: expansão internacional, recuperação de desastres em outro provedor ou uso de um serviço específico que só existe em determinada nuvem. Benefício: usar cada provedor onde ele oferece a melhor vantagem técnica ou comercial, sem fragmentar a plataforma. Limitação: tráfego entre provedores tem latência e custo de saída — o desenho precisa manter as conversas frequentes dentro da mesma região.

4. Multi-cloud

Para ambientes que buscam reduzir dependência de um fornecedor, os workers ficam simultaneamente em mais de uma nuvem — InteSys + AWS, InteSys + Azure, InteSys + Hetzner, InteSys + infraestrutura do cliente ou vários provedores ao mesmo tempo.

Indicado para: requisito explícito de independência de fornecedor, exigência contratual de múltiplos provedores ou estratégia de continuidade que não aceita um único fornecedor como ponto único de falha. Benefício: capacidade, redundância e alcance geográfico distribuídos entre provedores. Limitação: cada região adicional acrescenta latência, tráfego entre provedores, custo de egresso, complexidade de armazenamento e mais um domínio de falha para operar.

Multi-cloud não é objetivo em si

O objetivo não é usar o maior número possível de nuvens, e sim a combinação de infraestrutura que faz sentido para os requisitos de disponibilidade, desempenho, conformidade e custo da aplicação. Cada provedor adicional cobra em complexidade operacional.

Capacidade flexível por região

Os worker nodes não precisam ter configurações idênticas nem usar o mesmo provedor. Um mesmo cluster pode combinar, por exemplo, dois nós de 16 vCPU / 64 GB em br-sp-1, dois iguais em br-sp-2 e nós menores em uma nuvem pública para processamento assíncrono.

Isso permite otimizar simultaneamente custo, latência, disponibilidade, residência de dados, capacidade, conformidade e proximidade dos usuários — e usar deliberadamente regiões mais baratas para cargas que toleram latência maior.

Evolução em fases

FASE 1          FASE 2                    FASE 3
br-sp-1    →    br-sp-1 + br-sp-2    →    br-sp-1 + br-sp-2 + nuvem pública

A cada fase, o que muda é a topologia da infraestrutura — não a plataforma nem os manifestos da aplicação.

Páginas Relacionadas