Multi-Región y Multi-Cloud¶
Distribuir un clúster entre regiones solo entrega disponibilidad si tres decisiones están alineadas: dónde entra el usuario, dónde se ejecuta la carga y dónde está el dato. Esta página cubre las dos primeras — la tercera está en Cargas con Estado.
Nodos identificados por región y zona¶
Cada nodo worker lleva información de topología que identifica su ubicación física o lógica. Kubernetes usa esas etiquetas para decidir dónde puede ejecutarse cada carga.
La topología de la infraestructura pasa a formar parte de la política de planificación de la aplicación.
Una aplicación puede exigir tres réplicas con una en br-sp-1, una en br-sp-2 y una en la nube pública — o restringir explícitamente una carga:
Los mecanismos son los del propio Kubernetes:
- Topology Spread Constraints — distribución equilibrada entre zonas;
- Pod Anti-Affinity — réplicas del mismo servicio en nodos o zonas distintas;
- PodDisruptionBudget — piso de disponibilidad durante mantenimiento y actualizaciones;
- Node Affinity / selectores por zona — fijación de cargas que dependen de datos locales;
- Réplicas mínimas por región — presencia garantizada en cada dominio de fallo.
Balanceo global con Cloudflare¶
En arquitecturas multi-región, el tráfico externo se distribuye mediante Cloudflare Global Load Balancing, que considera la disponibilidad de los endpoints y la estrategia geográfica de la aplicación. Si una región deja de responder correctamente, el tráfico se dirige a las regiones sanas.
Redirigir tráfico no significa que el dato de la aplicación esté disponible en la región de destino.
Útil para: failover regional, aplicaciones distribuidas globalmente, recuperación ante desastres, reducción de latencia para el usuario final, distribución de carga y mantenimiento regional programado.
Un balanceador global no convierte una aplicación en multi-región
El balanceador decide a dónde enviar al usuario. Kubernetes decide dónde ejecutar. La arquitectura de datos garantiza dónde está disponible el dato. Las tres capas son complementarias — poner un balanceador global delante de una aplicación cuyos datos viven en una sola región solo envía usuarios a un lugar que no puede atenderlos.
Partición de red entre regiones¶
Una arquitectura multi-región debe considerar no solo la pérdida completa de un centro de datos, sino también la partición de red: ambos lados siguen operando mientras pierden comunicación entre sí.
Para cargas sin estado, esto se resuelve con réplicas, health checks y balanceo — cada lado atiende con lo que tiene.
Para cargas con estado, la arquitectura debe proveer quórum, elección de líder, fencing, replicación, prevención de split-brain y consistencia de datos. Esos mecanismos se definen por tecnología, caso por caso — lo que vale para PostgreSQL no es lo que vale para Kafka. InteSys evalúa ese requisito junto con el diseño del clúster.
Si una región pierde conectividad¶
Las cargas que ya se ejecutan en los nodos worker no dependen continuamente del control plane para seguir funcionando. Si un grupo de nodos pierde temporalmente la comunicación con la capa de gestión:
- los contenedores existentes siguen ejecutándose y pueden reiniciarse localmente cuando corresponde;
- las nuevas decisiones de planificación y los cambios de estado que dependen de la comunicación con el clúster quedan temporalmente limitados;
- al restablecerse la conectividad, Kubernetes retoma la reconciliación hacia el estado deseado.
Para cargas con estado, se aplican los mecanismos adicionales de quórum, replicación y protección contra split-brain descritos arriba.
El costo no es igual en toda región¶
La capacidad de cómputo no tiene el mismo precio en todos lados. Un worker en infraestructura InteSys puede costar distinto de un worker equivalente en AWS, Azure, Google Cloud, DigitalOcean, OVHcloud o Hetzner — y las diferencias aparecen en CPU, memoria, almacenamiento, IOPS, tráfico de salida, IPs públicas, balanceadores, snapshots, copias de seguridad y tráfico entre regiones.
Esa diferencia se usa como herramienta de arquitectura:
| Carga | Dónde suele ubicarse |
|---|---|
| Carga crítica y sensible a la latencia | Región premium, con alta disponibilidad |
| Procesamiento asíncrono | Región de menor costo |
| Usuarios europeos | Región europea |
| Datos bajo exigencia de residencia | Regiones brasileñas |
El precio se define según la región y el proveedor elegidos para cada grupo de nodos.
Sin lock-in de infraestructura¶
Un clúster que no está atado a un único hyperscaler puede evolucionar sin reconstruir la plataforma de la aplicación alrededor de servicios propietarios. Los servicios específicos de un proveedor siguen disponibles cuando aportan ventaja técnica — pero pasan a ser una elección de arquitectura, no un requisito de la plataforma Kubernetes.
Páginas Relacionadas¶
- Modelos de Despliegue — Región única, multi-DC, híbrido y multi-cloud
- Cargas con Estado — Topología de almacenamiento y replicación
- Seguridad de la Plataforma — Cilium, hardening y ciclo de vida
- MySQL Multi-Región · PostgreSQL Multi-Región
- Recuperación ante Desastres — RPO, RTO y failover entre regiones