Modelos de Despliegue¶
El mismo clúster gestionado puede entregarse en cuatro arreglos distintos. La elección no es ideológica: se deriva de dónde están los usuarios, cuánto cuesta la indisponibilidad y dónde pueden estar los datos.
Cada modelo es un escalón: se puede empezar por el primero y evolucionar sin reconstruir la plataforma.
1. Región única¶
La configuración más simple usa nodos worker en una única región — normalmente br-sp-1.
Indicado para: aplicaciones que atienden principalmente una región geográfica, sin exigencia de continuidad entre centros de datos, con datos que deben permanecer cerca de la aplicación y prioridad en simplicidad y costo. Beneficio: menor costo, menor latencia interna y la menor complejidad operativa posible. Limitación: un único dominio de fallo — perder la región es perder el entorno.
Incluso en este modelo el clúster sigue siendo gestionado: red Cilium, políticas de seguridad, actualizaciones controladas y monitoreo forman parte del servicio.
2. Alta disponibilidad entre centros de datos InteSys¶
Para aplicaciones críticas, los workers se distribuyen entre br-sp-1 (Cirion SAO1, Cotia/SP) y br-sp-2 (Equinix SP3, Tamboré/SP).
Las dos regiones están en la región metropolitana de São Paulo, pero operan desde instalaciones físicas y proveedores de infraestructura diferentes, interconectadas por enlaces Lan2Lan o túneles cifrados. La latencia entre ellas es de pocos milisegundos, lo que mantiene viable incluso la replicación síncrona de base de datos.
Indicado para: producción crítica que debe sobrevivir a la pérdida de un centro de datos manteniendo todos los datos en Brasil. Beneficio: dos dominios de fallo reales, sin salir de la jurisdicción brasileña y sin latencia internacional. Limitación: no protege contra un evento que alcance simultáneamente toda la región metropolitana de São Paulo — para eso, un tercer dominio en otra geografía.
Kubernetes identifica la ubicación de cada nodo mediante regiones y zonas de disponibilidad, lo que permite exigir distribución automática entre zonas, pod anti-affinity, topology spread constraints, PodDisruptionBudgets y un número mínimo de réplicas por región.
3. Híbrido — InteSys + nube pública¶
El mismo clúster combina infraestructura InteSys y capacidad de cómputo de nube pública: AWS, Google Cloud, Microsoft Azure, DigitalOcean, OVHcloud, Hetzner o infraestructura del propio cliente.
Un arreglo habitual:
- InteSys, Brasil — aplicación principal, bases de datos y cargas sensibles a la latencia;
- Nube pública, EE. UU. — procesamiento asíncrono y capacidad adicional;
- Nube pública, Europa — atención a usuarios europeos.
Indicado para: expansión internacional, recuperación ante desastres con otro proveedor o uso de un servicio específico que solo existe en determinada nube. Beneficio: usar cada proveedor donde ofrece la mayor ventaja técnica o comercial, sin fragmentar la plataforma. Limitación: el tráfico entre proveedores tiene latencia y costo de salida — el diseño debe mantener las conversaciones frecuentes dentro de la misma región.
4. Multi-cloud¶
Para entornos que buscan reducir la dependencia de un proveedor, los workers están simultáneamente en más de una nube — InteSys + AWS, InteSys + Azure, InteSys + Hetzner, InteSys + infraestructura del cliente, o varios proveedores a la vez.
Indicado para: requisito explícito de independencia de proveedor, exigencia contractual de múltiples proveedores o estrategia de continuidad que no acepta un único proveedor como punto único de fallo. Beneficio: capacidad, redundancia y alcance geográfico repartidos entre proveedores. Limitación: cada región adicional añade latencia, tráfico entre proveedores, costo de egreso, complejidad de almacenamiento y un dominio de fallo más para operar.
Multi-cloud no es un objetivo en sí mismo
El objetivo no es usar la mayor cantidad posible de nubes, sino la combinación de infraestructura que tiene sentido para los requisitos de disponibilidad, rendimiento, cumplimiento y costo de la aplicación. Cada proveedor adicional cobra en complejidad operativa.
Capacidad flexible por región¶
Los nodos worker no necesitan configuraciones idénticas ni el mismo proveedor. Un mismo clúster puede combinar, por ejemplo, dos nodos de 16 vCPU / 64 GB en br-sp-1, dos equivalentes en br-sp-2 y nodos menores en una nube pública para procesamiento asíncrono.
Esto permite optimizar simultáneamente costo, latencia, disponibilidad, residencia de datos, capacidad, cumplimiento y proximidad a los usuarios — y ubicar deliberadamente en regiones más baratas las cargas que toleran mayor latencia.
Evolución por fases¶
En cada fase lo que cambia es la topología de la infraestructura — no la plataforma ni los manifiestos de la aplicación.
Páginas Relacionadas¶
- Kubernetes Gestionado — Visión general de la plataforma
- Multi-Región y Multi-Cloud — Planificación por topología y balanceo global
- Cargas con Estado — Qué impide que una base cambie de región sin más
- Centros de Datos InteSys — br-sp-1 y br-sp-2