Ejecutar bases de datos en Kubernetes se ha convertido en una práctica habitual en entornos cloud-native. Sin embargo, garantizar que una base de datos sobreviva a un fallo regional completo, a una corrupción del plano de control o a una partición de red requiere una arquitectura resistente a fallos que va más allá de un único clúster. En este artículo exploramos cómo construir un despliegue multi-clúster de MongoDB sobre Kubernetes, extrayendo principios que pueden aplicarse a cualquier base de datos relacional o NoSQL. Abordaremos la arquitectura, el diseño para alta disponibilidad, el flujo de despliegue y el comportamiento ante fallos, todo ello desde una perspectiva técnica y empresarial que ayuda a tomar decisiones informadas.
La necesidad de una arquitectura multi-clúster surge de las limitaciones inherentes a un único clúster de Kubernetes. Kubernetes es excelente para la auto-recuperación dentro de un mismo clúster: reinicia pods fallidos, reemplaza nodos dañados y mantiene el estado deseado. Pero no tiene mecanismos nativos para manejar fallos a nivel de clúster: una interrupción regional, un plano de control corrupto o una red seccionada pueden dejar toda la base de datos fuera de servicio sin una ruta de recuperación automática. Distribuir los nodos de MongoDB entre varios clústeres Kubernetes independientes soluciona esta carencia y habilita tres escenarios críticos: recuperación ante desastres (DR), migraciones en caliente y mantenimiento sin tiempo de inactividad programado. Cada uno de estos escenarios tiene implicaciones directas en la continuidad del negocio y los costes operativos.
En nuestra experiencia como empresa de desarrollo de software, hemos visto cómo organizaciones que migran a la nube o adoptan estrategias multicloud necesitan este nivel de resiliencia. Por ejemplo, durante una migración entre proveedores cloud, poder mantener la base de datos operativa mientras se traslada el tráfico gradualmente evita ventanas de corte que pueden traducirse en pérdidas de ingresos. Del mismo modo, actualizar un clúster completo sin detener los servicios de la aplicación es un factor diferencial en entornos de alta disponibilidad. Para lograrlo, la arquitectura divide los clústeres en dos roles claros: sitio principal y sitio réplica, asegurando que las operaciones a nivel de Kubernetes no interfieran con las operaciones a nivel de la base de datos.
El rol de sitio principal es el clúster gestionado por el operador Kubernetes (por ejemplo, el Percona Operator para MongoDB). Aquí se ejecuta el nodo primario de MongoDB y se manejan las escrituras de la aplicación. El operador en este sitio es responsable de aprovisionar certificados TLS, credenciales de usuario y configuraciones del replica set. Por otro lado, el sitio réplica ejecuta el operador en modo no gestionado (unmanaged): no genera certificados ni credenciales, sino que replica los secretos desde el sitio principal, permitiendo que los nodos secundarios se unan al replica set existente. Esto evita que dos operadores independientes intenten controlar la misma base de datos simultáneamente, un escenario que generaría conflictos de configuración o “split-brain”.
Para conectar los clústeres, se utiliza la API de Servicios Multi-Clúster (MCS API) de Kubernetes. Esta API permite que nodos en diferentes clústeres se descubran y comuniquen mediante una zona DNS compartida (svc.clusterset.local). Requiere una implementación adicional como Submariner, Cilium ClusterMesh o soluciones nativas de proveedores cloud (por ejemplo, GKE Fleet). Al habilitar multiCluster.enabled: true en el Custom Resource del operador, se crean automáticamente recursos ServiceExport y ServiceImport que exponen los servicios de base de datos a través de los límites del clúster. Este descubrimiento entre clústeres es el fundamento que permite que todos los nodos de MongoDB, independientemente de dónde se ejecuten, formen un único replica set lógico.
El diseño para alta disponibilidad se basa en un principio fundamental de MongoDB: el quórum de mayoría estricta. Un replica set necesita más de la mitad de los votos para elegir un primario y aceptar escrituras. Si distribuimos los nodos de voto equitativamente en dos ubicaciones (por ejemplo, 2+2), un corte de red entre ellas dejaría a ambos lados sin mayoría, deteniendo las escrituras aunque todos los servidores estén sanos. La solución es añadir un quinto miembro en una tercera ubicación, siguiendo el patrón 2+2+1. Con cinco votos totales, si una ubicación falla, la otra puede alcanzar tres votos (mayoría) y elegir un nuevo primario. Este patrón es configurable directamente en el YAML del operador, especificando el tamaño del replica set y los nodos externos con sus respectivos votos y prioridad.
El flujo de despliegue típico comienza conectando las redes entre clústeres (prerrequisito MCS). Luego se despliega el sitio principal con el operador en modo completo, asegurando que los pods del replica set se expongan con tipo ClusterIP (requerido por la MCS API). Después se copian los secretos TLS y credenciales desde el sitio principal al réplica. En los sitios réplica se despliega el operador con unmanaged: true, indicando que no debe inicializar un nuevo replica set sino unirse al existente. Finalmente, se actualiza la configuración del replica set añadiendo los nodos del sitio réplica como nodos externos, y viceversa, para que ambos clústeres conozcan la topología completa. Este proceso garantiza que el replica set abarque múltiples clústeres y esté listo para la conmutación automática por error.
Cuando ocurre un fallo —por ejemplo, la pérdida completa del sitio principal— el protocolo de elección de MongoDB se activa. Los nodos restantes detectan la ausencia del primario y, si alcanzan la mayoría necesaria (3 de 5 en el patrón 2+2+1), eligen un nuevo primario automáticamente. En condiciones normales, el tiempo medio de elección no suele superar los 12 segundos, aunque la latencia entre regiones puede alargarlo. Es recomendable que la lógica de conexión de la aplicación implemente escrituras reintentables (retryable writes) para manejar ese breve período sin primario. Tras la conmutación, la base de datos entra en un estado “degradado”: funciona con el mínimo de nodos necesarios para la mayoría, perdiendo redundancia. Si se pierde un nodo adicional, el sistema pasa a modo solo lectura. Por ello es crucial restaurar la capacidad completa lo antes posible, ya sea recuperando el sitio principal o añadiendo nuevos nodos.
Desde una perspectiva empresarial, implementar una arquitectura multi-clúster supone una inversión en herramientas y procesos, pero los beneficios en continuidad de negocio son tangibles: reducción del RTO (tiempo de recuperación objetivo) y del RPO (punto de recuperación objetivo) prácticamente a cero. Muchas organizaciones combinan esta arquitectura con servicios cloud como AWS o Azure para obtener almacenamiento persistente, balanceo de carga global y opciones de replicación geográfica. Al mismo tiempo, la ciberseguridad juega un papel determinante: la gestión de secretos entre clústeres debe realizarse de forma segura, utilizando políticas de red y cifrado en tránsito. Además, la inteligencia artificial y los agentes de IA pueden integrarse en la capa de monitoreo para predecir fallos o recomendar ajustes de configuración basados en patrones de carga, mejorando la eficiencia operativa.
En Q2BSTUDIO, como empresa especializada en aplicaciones a medida, hemos acompañado a clientes en el diseño e implementación de arquitecturas multi-clúster para bases de datos críticas. Nuestra experiencia abarca desde la selección del operador Kubernetes adecuado hasta la configuración de integración continua y despliegue (CI/CD) que automatiza la gestión de secretos entre clústeres. También ofrecemos servicios cloud en AWS y Azure que incluyen la orquestación de Kubernetes multi-clúster y la integración con soluciones de Business Intelligence como Power BI, permitiendo a las empresas extraer valor en tiempo real de sus datos distribuidos. Todo ello con un enfoque en la ciberseguridad y la automatización, dos pilares que garantizan despliegues robustos y escalables.
En conclusión, las bases de datos multi-clúster en Kubernetes representan la evolución natural hacia arquitecturas cloud-native resilientes. Comprender los patrones de diseño, las herramientas de conectividad y el comportamiento ante fallos permite a las organizaciones tomar decisiones informadas que alinean la tecnología con los objetivos de negocio. Ya sea para recuperación ante desastres, migraciones sin interrupción o mantenimiento planificado, esta arquitectura ofrece la fiabilidad que exigen las aplicaciones modernas. En Q2BSTUDIO estamos preparados para guiar este proceso, combinando know-how técnico con una visión estratégica que convierte la complejidad en ventaja competitiva.
