Kubernetes Gestionado Multi-Región¶
Un clúster de Kubernetes no tiene por qué limitarse a un centro de datos o a un proveedor de nube. InteSys opera clústeres gestionados cuyos nodos worker pueden estar en una única región, repartidos entre nuestros dos centros de datos brasileños o distribuidos entre proveedores distintos — siempre como un único entorno Kubernetes.
Desde la perspectiva de la aplicación, los nodos forman parte del mismo clúster. Desde la infraestructura, cada grupo de nodos pertenece a una región, centro de datos o proveedor diferente.
Dónde pueden estar los nodos worker¶
| Ubicación | Detalle |
|---|---|
| br-sp-1 | Cirion SAO1 — Cotia/SP, Brasil |
| br-sp-2 | Equinix SP3 — Tamboré/SP, Brasil |
| Nube pública | AWS, Google Cloud, Microsoft Azure, DigitalOcean, OVHcloud, Hetzner |
| Infraestructura del cliente | Centro de datos propio o colocation |
| Otros entornos compatibles | Evaluados caso por caso |
No hay exigencia de usar exclusivamente infraestructura InteSys. La combinación la definen los requisitos de la aplicación.
El control plane no entra en su factura¶
En entornos Kubernetes tradicionales, el cliente debe provisionar servidores dedicados únicamente al control plane — en alta disponibilidad, normalmente tres máquinas que no ejecutan ninguna carga de la aplicación.
El control plane no desaparece de la arquitectura: es abstraído, operado y provisto por InteSys como parte de la plataforma.
El cliente paga por los recursos de cómputo de sus nodos worker. CPU, memoria, almacenamiento y tráfico varían según la región y el proveedor elegidos — lo que además permite usar cada proveedor donde ofrece la mayor ventaja técnica o comercial.
Modelos de despliegue¶
| Modelo | Arreglo | Indicado para |
|---|---|---|
| Región única | Workers en una región | Aplicaciones regionales, con prioridad en simplicidad y costo |
| Multi-DC en Brasil | br-sp-1 + br-sp-2 | Alta disponibilidad con todos los datos dentro del país |
| Híbrido | InteSys + nube pública | Capacidad adicional, DR o alcance internacional |
| Multi-cloud | Dos o más proveedores | Menor dependencia de un único proveedor |
→ Detalle de los cuatro modelos
Qué opera InteSys¶
- Ciclo de vida de la plataforma — versiones estables y soportadas, planificación de actualizaciones, actualización progresiva de los workers y reemplazo controlado de nodos.
- Red con Cilium — políticas L3/L4 basadas en identidad, segmentación por namespace, observabilidad de red y cifrado entre nodos cuando la arquitectura lo prevé.
- Seguridad en capas — hardening del sistema operativo alineado con CIS Benchmarks, RBAC de mínimo privilegio, Pod Security Standards y restricción de contenedores privilegiados.
- Topología como política — nodos etiquetados por región y zona, habilitando distribución automática, anti-affinity, topology spread constraints y PodDisruptionBudgets.
- Sistemas operativos elegidos por proyecto — distribuciones mínimas, Cloud Native o inmutables, seleccionadas por compatibilidad, superficie de ataque y requisitos de cumplimiento.
El cliente mantiene el control de sus cargas: namespaces, deployments, services y aplicaciones. InteSys opera la plataforma Kubernetes necesaria para ejecutarlas.
Gestionado, no solo alojado
El objetivo no es entregar servidores con Kubernetes instalado. La plataforma misma se opera como servicio — incluyendo actualizaciones, red, políticas de seguridad y monitoreo de salud del clúster.
Elegir la arquitectura¶
No existe una arquitectura multi-región adecuada para toda aplicación. Una aplicación sin estado distribuida globalmente tiene requisitos muy distintos de una base de datos transaccional que debe mantener todos los datos en Brasil.
| Requisito | Arquitectura típica |
|---|---|
| Menor costo y simplicidad | Región única |
| Alta disponibilidad en Brasil | br-sp-1 + br-sp-2 |
| Recuperación ante desastres con otro proveedor | InteSys + nube pública |
| Menor dependencia de proveedor | Multi-cloud |
| Usuarios en distintos continentes | Kubernetes global |
| Infraestructura ya existente del cliente | InteSys + on-premises |
| Datos restringidos a Brasil | Workers y almacenamiento en regiones brasileñas |
La evolución es gradual: empezar en br-sp-1, sumar br-sp-2 para alta disponibilidad y, cuando exista un requisito real, incorporar nube pública o infraestructura propia. No hace falta empezar global para poder llegar allí.
Próximos Pasos¶
- Modelos de Despliegue — Región única, multi-DC, híbrido y multi-cloud
- Multi-Región y Multi-Cloud — Regiones, zonas, planificación y balanceo global
- Cargas con Estado — Dónde pueden — y no pueden — moverse los datos
- Seguridad de la Plataforma — Hardening, Cilium y ciclo de vida gestionado
- Kubernetes en el día a día — Deployments, probes, HPA e ingress
- Administración de Bases de Datos — Bases gestionadas dentro o fuera del clúster
- Contáctenos — Converse sobre la arquitectura de su clúster