Kubernetes Gerenciado Multi-Região¶
Um cluster Kubernetes não precisa ficar limitado a um datacenter ou a um provedor de nuvem. A InteSys opera clusters gerenciados nos quais os worker nodes podem estar em uma única região, distribuídos entre nossos dois datacenters brasileiros ou espalhados entre provedores diferentes — sempre como um único ambiente Kubernetes.
Para a aplicação, os nós fazem parte do mesmo cluster. Para a infraestrutura, cada grupo de nós pertence a uma região, datacenter ou provedor diferente.
Onde os worker nodes podem ficar¶
| Local | Detalhe |
|---|---|
| br-sp-1 | Cirion SAO1 — Cotia/SP, Brasil |
| br-sp-2 | Equinix SP3 — Tamboré/SP, Brasil |
| Nuvem pública | AWS, Google Cloud, Microsoft Azure, DigitalOcean, OVHcloud, Hetzner |
| Infraestrutura do cliente | Datacenter próprio ou colocation |
| Outros ambientes compatíveis | Avaliados caso a caso |
Não há exigência de usar exclusivamente infraestrutura InteSys. A combinação é definida pelos requisitos da aplicação.
O control plane não entra na sua conta¶
Em ambientes Kubernetes tradicionais, o cliente precisa provisionar servidores dedicados apenas ao control plane — em alta disponibilidade, normalmente três máquinas que não executam nenhuma carga da aplicação.
O control plane não desaparece da arquitetura: ele é abstraído, operado e fornecido pela InteSys como parte da plataforma.
O cliente paga pelos recursos computacionais dos worker nodes. CPU, memória, armazenamento e tráfego variam conforme a região e o provedor escolhidos — o que também permite usar cada provedor onde ele oferece a melhor vantagem técnica ou comercial.
Modelos de implantação¶
| Modelo | Arranjo | Indicado para |
|---|---|---|
| Região única | Workers em uma região | Aplicações regionais, prioridade em simplicidade e custo |
| Multi-DC no Brasil | br-sp-1 + br-sp-2 | Alta disponibilidade com todos os dados no país |
| Híbrido | InteSys + nuvem pública | Capacidade adicional, DR ou alcance internacional |
| Multi-cloud | Dois ou mais provedores | Redução de dependência de um único fornecedor |
→ Detalhamento dos quatro modelos
O que a InteSys opera¶
- Ciclo de vida da plataforma — versões estáveis e suportadas, planejamento de upgrade, atualização progressiva dos workers e substituição controlada de nós.
- Rede com Cilium — políticas L3/L4 baseadas em identidade, segmentação por namespace, observabilidade de rede e criptografia entre nós quando prevista na arquitetura.
- Segurança em camadas — hardening de sistema operacional alinhado a CIS Benchmarks, RBAC de menor privilégio, Pod Security Standards e restrição a contêineres privilegiados.
- Topologia como política — nós rotulados por região e zona, permitindo distribuição automática, anti-affinity, topology spread constraints e PodDisruptionBudgets.
- Sistemas operacionais adequados ao projeto — distribuições mínimas, Cloud Native ou imutáveis, escolhidas por compatibilidade, superfície de ataque e requisitos de conformidade.
O cliente continua dono das suas cargas: namespaces, deployments, services e aplicações. A InteSys opera a plataforma Kubernetes necessária para executá-las.
Gerenciado, não apenas hospedado
O objetivo não é entregar servidores com Kubernetes instalado. A plataforma em si é operada como serviço — incluindo upgrades, rede, políticas de segurança e monitoramento de saúde do cluster.
Escolhendo a arquitetura¶
Não existe uma arquitetura multi-região adequada a toda aplicação. Uma aplicação sem estado distribuída globalmente tem requisitos muito diferentes de um banco transacional que precisa manter todos os dados no Brasil.
| Requisito | Arquitetura típica |
|---|---|
| Menor custo e simplicidade | Região única |
| Alta disponibilidade no Brasil | br-sp-1 + br-sp-2 |
| Recuperação de desastres em outro provedor | InteSys + nuvem pública |
| Menor dependência de fornecedor | Multi-cloud |
| Usuários em continentes diferentes | Kubernetes global |
| Infraestrutura já existente no cliente | InteSys + on-premises |
| Dados restritos ao Brasil | Workers e armazenamento em regiões brasileiras |
A evolução é gradual: começar em br-sp-1, adicionar br-sp-2 para alta disponibilidade e, quando houver requisito real, incorporar nuvem pública ou infraestrutura própria. Não é necessário começar global para poder chegar lá.
Próximos Passos¶
- Modelos de Implantação — Região única, multi-DC, híbrido e multi-cloud
- Multi-Região e Multi-Cloud — Regiões, zonas, agendamento e balanceamento global
- Cargas com Estado — Onde os dados podem — e não podem — se mover
- Segurança da Plataforma — Hardening, Cilium e ciclo de vida gerenciado
- Kubernetes no dia a dia — Deployments, probes, HPA e ingress
- Administração de Banco de Dados — Bancos gerenciados dentro ou fora do cluster
- Fale Conosco — Discuta a arquitetura do seu cluster