Configuración de XDCR entre VPCs en clústeres de Amazon EKS

En los sistemas distribuidos modernos, la capacidad de replicar datos entre entornos separados es crucial para garantizar alta disponibilidad, recuperación ante desastres y optimización del rendimiento. La función XDCR (Replicación entre Centros de Datos) de Couchbase permite una replicación fluida de datos entre clústeres, lo que posibilita compartir datos de manera sólida entre entornos aislados geográfica o lógicamente.

Esta guía lo guiará a través de la configuración de XDCR entre dos clústeres de Couchbase alojados en clústeres separados de Amazon EKS (Elastic Kubernetes Service) dentro de diferentes VPC. Profundizaremos en cada paso, desde la configuración de la infraestructura hasta la configuración de DNS para la comunicación entre clústeres y el despliegue de Couchbase para la replicación en tiempo real. Al finalizar este recorrido, tendrá una configuración lista para producción con las habilidades necesarias para replicarla en su entorno.

Prerrequisitos

Para seguir esta guía, asegúrate de tener:

• AWS CLI instalado y configurado
• Una cuenta de AWS con permisos para crear VPCs, clústeres de EKS y grupos de seguridad
• Familiaridad con Kubernetes y herramientas como kubectl y Helm
• Helm instalado para desplegar Couchbase
• Conocimientos básicos de conceptos de redes, incluidos bloques CIDR, tablas de enrutamiento y DNS

---

Paso 1: Implementar clústeres de EKS en VPC separadas

¿Qué estamos haciendo?

Crearemos dos clústeres de Kubernetes, Cluster1 y Cluster2, en VPCs separadas utilizando eksctl. Cada clúster operará de forma independiente y tendrá su propio bloque CIDR para evitar conflictos de IP.

¿Por qué es esto importante?

Esta separación garantiza:

1. Aislamiento para una mejor seguridad y gestión
2. Escalabilidad y flexibilidad para gestionar cargas de trabajo
3. Reglas de enrutamiento claras entre clústeres

Comandos para crear clústeres

Desplegar el clúster1

Desplegar cluster2

Resultado esperado

• El Clúster1 reside en la VPC 10.0.0.0/16
• El clúster 2 reside en la VPC 10.1.0.0/16

---

Paso 2: Conectar las VPC mediante emparejamiento para la comunicación entre clústeres

¿Qué estamos haciendo?

Estamos creando una conexión de emparejamiento de VPC (VPC Peering) entre las dos VPC y configurando las reglas de enrutamiento y seguridad para habilitar la comunicación entre clústeres.

Pasos

2.1 Crear una conexión de emparejamiento

• Vaya a la Consola de AWS > VPC > Conexiones de emparejamiento
• Hacer clic Crear conexión de emparejamiento
• Seleccione VPC solicitante (VPC del Clúster 1) y Aceptar VPC (VPC del clúster 2)
• Nombra la conexión experto
• Hacer clic Crear conexión de emparejamiento

2.2 Aceptar la solicitud de emparejamiento

• Seleccione la conexión de emparejamiento
• Hacer clic Acciones > Aceptar solicitud

2.3 Actualizar las tablas de rutas

• Para la VPC de Cluster1, agregue una ruta para 10.1.0.0/16 que apunte a la conexión de emparejamiento
• Para la VPC de Cluster2, agregue una ruta para 10.0.0.0/16, dirigida a la conexión de emparejamiento

2.4 Modificar los grupos de seguridad

¿Por qué es esto necesario?

Los grupos de seguridad actúan como firewalls y debemos permitir el tráfico entre los clústeres explícitamente.

Cómo modificar

1. Navegar a EC2 > Grupos de seguridad en la consola de AWS
2. Identifique los grupos de seguridad asociados con Cluster1 y Cluster2
3. Para el grupo de seguridad del Clúster 1:
   • Hacer clic Editar reglas de entrada
   • Agregar una regla:
     • Escribir: Todo el tráfico
     • Fuente: ID de grupo de seguridad de Cluster2
4. Repetir para el Cluster2, permitiendo el tráfico desde el grupo de seguridad del Cluster1

---

Paso 3: Probar la conectividad implementando NGINX en Cluster2

¿Qué estamos haciendo?

Estamos implementando un pod de NGINX en el Cluster2 para verificar que el Cluster1 pueda comunicarse con él.

¿Por qué es esto importante?

Este paso garantiza que la conectividad de red entre los clústeres funcione correctamente antes de implementar Couchbase.

Pasos

3.1 Crear un Namespace en Cluster1 y Cluster2

3.2 Desplegar NGINX en Cluster1 y Cluster2

• Crea nginx.yaml:
  

3.3 Aplicar el YAML

3.4 Verificar la conectividad desde Cluster1

• Ejecute el comando exec en el pod en el Cluster1:
  

3.5 Probar la conectividad con Cluster2

Resultado esperado

El curl el comando fallará sin el reenvío de DNS, lo que resalta la necesidad de una mayor configuración de DNS.

---

Paso 4: Configuración del reenvío de DNS

¿Qué estamos haciendo?

Configuraremos el reenvío de DNS para que los servicios del Clúster2 puedan ser resueltos por el Clúster1. Esto es fundamental para permitir que las aplicaciones del Clúster1 interactúen con los servicios del Clúster2 utilizando sus nombres de DNS.

¿Por qué es esto importante?

El descubrimiento de servicios de Kubernetes se basa en DNS y, de forma predeterminada, las consultas de DNS para los servicios de un clúster no se pueden resolver en otro clúster. CoreDNS en el Clúster1 debe reenviar las consultas al solucionador de DNS del Clúster2.

Pasos

4.1 Obtener el extremo del servicio DNS de Cluster2

• Ejecute el siguiente comando en Cluster2 para obtener el extremo del servicio DNS:
  

• Busca el kube-dns o coredns servicio y anote su dirección IP. Por ejemplo:
  

  

4.2 Editar el ConfigMap de CoreDNS en Cluster1

• Abra el ConfigMap de CoreDNS para su edición:
  

   

4.3 Aañada el siguiente bloque a la sección Corefile

0

Reemplace 10.1.20.116 con la IP del extremo de DNS real de Cluster2.

Nota: Solo necesitamos usar uno de los puntos de conexión de CoreDNS para este ConfigMap. La IP de los pods de CoreDNS rara vez cambia, pero puede hacerlo si el nodo se cae. Se puede utilizar el servicio ClusterIP de kube-dns, pero requerirá que la IP y el puerto estén abiertos en los nodos de EKS.

4.4 Reiniciar CoreDNS en Cluster1

• Aplique los cambios reiniciando CoreDNS:
  

  1

  

4.5 Verificar el reenvío de DNS

• Ejecute un comando en cualquier pod en Cluster1:
  

  2

• Probar la resolución de DNS para un servicio NGINX en Cluster2:
  

  3

• Debería ver una respuesta del servicio NGINX
  

Resultado esperado

Las consultas de DNS de Cluster1 a Cluster2 deben resolverse correctamente.

---

Paso 5: Despliegue de Couchbase

¿Qué estamos haciendo?

Desplegaremos clústeres de Couchbase en ambos entornos de Kubernetes usando Helm. Cada clúster administrará sus propios datos de forma independiente antes de conectarse mediante XDCR.

¿Por qué es esto importante?

Los clústeres de Couchbase forman la base de la configuración de XDCR, y proporcionan una plataforma de base de datos NoSQL sólida y escalable.

Pasos

5.1 Agregar el repositorio de Helm de Couchbase

4

5.2 Implementar Couchbase en Cluster1

• Cambiar a Cluster1:
  

  5

• Implementar Couchbase:
  

  6

5.3 Desplegar Couchbase en Cluster2

• Cambiar a Clúster2:
  

  7

• Implementar Couchbase:
  

  8

5.4 Verificar el despliegue

• Revisar los pods de Couchbase:
  

  9

  

• Asegúrese de que todos los pods estén en ejecución.

Nota: Si encuentra un error de implementación, edite el CRD de CouchbaseCluster para utilizar una versión de imagen compatible:

0

Cambiar:

1

Para:

2

Resultado esperado

Los clústeres de Couchbase deben estar ejecutándose y ser accesibles a través de sus respectivas interfaces de usuario.

---

Paso 6: Configuración de XDCR

¿Qué estamos haciendo?

Configuraremos XDCR para habilitar la replicación de datos entre los dos clústeres de Couchbase.

¿Por qué es esto importante?

XDCR garantiza la consistencia de los datos entre clústeres, lo que respalda escenarios de alta disponibilidad y recuperación ante desastres.

Pasos

6.1 Obtener el nombre del servicio de Cluster2

• En el clúster2, ejecute el siguiente comando para recuperar el nombre del servicio de uno de los pods para que podamos hacer el reenvío de puertos (port-forward) hacia él.
  

  3

6.2 Acceda a la interfaz de usuario de Couchbase para Cluster2

• Redirigir el puerto de la IU de Couchbase:
  

  4

• Abrir un navegador y navegar a:
  https://localhost:8091
  

• Inicie sesión con las credenciales configuradas durante el despliegue.

6.3 Ver documentos en Cluster2

• In the Couchbase UI, go to Buckets
• Note that no Documents exist in the default cubeta

 

6.4 Access the Couchbase UI for Cluster1

• Redirigir el puerto de la IU de Couchbase:
  

  5

  

• Abrir un navegador y navegar a:
  https://localhost:8091
• Log in using the credentials configured during the deployment

6.5 Add a Remote Cluster

• In the Couchbase UI, go to XDCR > Add Remote Cluster
• Configure the remote cluster:
  • Cluster Name: Cluster2
  • IP/Hostname: <Cluster2 Service Name>.prod.svc.cluster.local
  • Username: Admin username for Cluster2
  • Password: Admin password for Cluster2
• Hacer clic Guardar
  

6.6 Set Up Replication

• In the Couchbase UI for Cluster1, go to XDCR > Add Replication
• Configure the replication:
  • Replicate From Bucket: Default bucket in Cluster1
  • Replicate To Bucket: Default bucket in Cluster2
  • Remote Cluster: Select Cluster2
• Hacer clic Guardar
  
  

6.7 Test Replication

• Add sample documents to the default bucket in Cluster1:
  • In the Couchbase UI, navigate to Buckets > Documents > Add Document
  • Give the Documento a unique ID and some data in JSON formato
    
  • Verify that the documents appear in the default bucket of Cluster2:
    • Port-forward to Cluster2’s UI and log in:
      

      6

  • Navigate to: https://localhost:8091

Resultado esperado

Data added to Cluster1 should replicate to Cluster2 in real time.

---

Step 7: Cleanup

¿Qué estamos haciendo?

We’ll cleanup our AWS environment and delete all the resources we deployed.

¿Por qué es esto importante?

This will prevent you from incurring unnecessary charges.

Pasos

7.1 Access the AWS Console

• Vaya a la Consola de AWS > VPC > Conexiones de emparejamiento
• Select and delete the peering connection
• Vaya a la Consola de AWS > CloudFormation > Stacks
• Select and delete the two nodegroup stacks
• Once the two nodegroup stacks have finished deleting select and delete the cluster stacks

Resultado esperado

All resources created for this tutorial are deleted from account.

---

Conclusión

Through this guide, we’ve successfully established XDCR between Couchbase clusters running in separate EKS clusters across AWS VPCs. This setup highlights the power of combining AWS networking with Kubernetes for robust, scalable solutions. With cross-cluster replication in place, your applications gain enhanced resilience, reduced latency for distributed users, and a solid disaster recovery mechanism.

By understanding and implementing the steps outlined here, you’re equipped to tackle real-world challenges involving multi-cluster setups, expanding your expertise in both cloud networking and distributed database management.

• Aprende más sobre Couchbase Cross Data Center Replication (XDCR)
• Read the XDCR documentation
• Read how XDCR is essential for globally distributed data, disaster recovery and high availability