Redes inter-Kubernetes mediante VPC Peering

1. Introducción

A menudo, los clientes empresariales desean tener clústeres de bases de datos en espera para la localización de datos y alto rendimiento, recuperación de desastres y/o para meras copias de seguridad de datos. Couchbase Cross Data Center Replication (XDCR) no requiere presentación ya que los clientes han estado utilizando esta característica durante mucho tiempo para lograr estos objetivos en su entorno.

Sin embargo, con más y más despliegues de Couchbase en la Nube últimamente usando Couchbase Autonomous Operator (CAO) para Kubernetes, los clientes han solicitado alguna orientación en la configuración de redes para su plataforma en la nube.

Este artículo profundiza en la configuración de redes entre Clusters Couchbase en dos regiones diferentes, utilizando un enfoque paso a paso. Hemos utilizado la plataforma Amazon AWS para desplegar el clúster Couchbase en el entorno Amazon EKS, pero creemos que el enfoque de alto nivel sería más o menos el mismo independientemente de la plataforma de su elección.

2. Requisitos previos

Le recomiendo encarecidamente que lea mi anterior blog sobre cómo desplegar Couchbase Cluster en EKS. La mayoría de los pasos detallados sobre el despliegue de Couchbase Autonomous Operator sólo van a ser referenciados en este artículo, por lo que podemos centrarnos en los aspectos de red para configurar la replicación entre centros de datos.

3. Despliegue de clusters EKS en dos regiones

Comencemos desplegando dos Amazon Elastic Container Service para Kubernetes (Amazon EKS) en dos regiones distintas (Virginia y Ohio).

Figura 1: Despliegue del clúster EKS en las regiones de Ohio y Virginia.

Cada clúster de Amazon EKS tendrá un mínimo de tres nodos trabajadores, que se utilizarán para alojar pods de Couchbase como se describe en la sección 4. Nuestro objetivo al final de este artículo es que tengas dos clústeres de Couchbase desplegados en estos dos clústeres de Amazon EKS, la red configurada y XDCR activo establecido desde el origen al clúster de destino.

3.1. Despliegue del EKS en la región de Virginia

Utilizaremos eksctl para desplegar Amazon EKS, donde crearemos un nuevo nodegroup llamado grupo azul con un mínimo de tres m5.grande instancias y un máximo de seis.

$ eksctl crear clúster \ --nombre blueEKS \ --versión 1.14 \ --región us-east-1 \ --zonas us-east-1a,us-east-1b,us-east-1c \
--nodegroup-name bluegroup \ --node-type m5.large \ --nodes 3 \ --nodes-min 3 \ --nodes-max 6 \ --node-ami auto \ --vpc-cidr 172.16.0.0/24

[ℹ] utilizando la región us-east-1 ... [✔] El clúster EKS "blueEKS" en la región "us-east-1" está listo

Una vez eksctl termina de desplegar el clúster Kubernestes (K8s), inicia sesión en la consola de AWS para anotar el VPC-ID y el bloque CIDR. Aquí están los pasos para averiguar estos detalles, que más tarde se utilizará en la configuración de VPC peer.

Figura 2: La consola EKS muestra el panel de recursos por región.

1. Seleccione Virginia región en el menú desplegable.
2. Si ve el panel de control de la VPC, haga clic en Sus VPC del panel izquierdo. Si tiene otra página abierta, busque primero el servicio VPC y haga clic en Sus VPC opción.

Figura 3: Página de detalles de la VPC.

1. Como se puede ver arriba, es necesario seleccionar la VPC que se acaba de crear y luego copiar el archivo ID DE VPC en la tabla siguiente:

Tabla 1. Atributos del clúster Blue EKS

Atributos	Racimo azul	Grupo Verde
Región	Virginia	Ohio
Bloque CIDR	172.16.0.0/24
VPC-ID	vpc-0c8d3d5919e79659d

3.2. Despliegue del EKS en la región de Ohio

A continuación, despliegue el clúster Kubernetes en la región de Ohio con 3 nodos trabajadores de m5.grande tipo. El número y tipo de estos nodos trabajadores puede ser diferente dependiendo del tamaño del cluster pero en esta configuración, vamos a desplegar un cluster Couchbase de 3 nodos en estos 3 nodos trabajadores.

$ eksctl crear clúster \ --nombre greenEKS \ --versión 1.14 \ --región us-east-2 \ --zonas us-east-2a,us-east-2b,us-east-2c \
--nodegroup-name greengroup \ --node-type m5.large \ --nodes 3 \ --nodes-min 3 \ --nodes-max 6 \ --node-ami auto \ --vpc-cidr 10.0.0.0/24

[ℹ] utilizando la región us-east-2 ... [✔] El clúster EKS "greenEKS" en la región "us-east-2" está listo.

Una vez que el clúster Green esté listo, abre una nueva pestaña del navegador e inicia sesión en la consola de AWS.

Figura 4: Consola AWS conectada a la región de Ohio.

• Cambiar la región a Ohio

Gráfico 5: Página de detalles de la VPC que muestra los detalles del clúster de Ohio.

• En el panel de control de la VPC, seleccione Sus VPC ficha.
• Copie y pegue el ID de VPC del clúster verde en la tabla siguiente para el registro:

Tabla 2. Atributos del clúster EKS verde

Atributos	Racimo azul	Grupo Verde
Región	Virginia	Ohio
Bloque CIDR	172.16.0.0/24	10.0.0.0/24
VPC-ID	vpc-0c8d3d5919e79659d	vpc-08d025c8ae697bf34

En este punto, tenemos el clúster Kubernetes desplegado en las regiones de Virginia y Ohio y tenemos detalles de VPC que se utilizarán en el peering de VPC.

3.3. Cambiar el contexto del clúster

Antes de pasar a desplegar Couchbase Clusters en estas dos regiones, un comando útil para recordar para cambiar los contextos de cluster fácilmente:

$ kubectl config get-contexts

NOMBRE ACTUAL CLÚSTER AUTHINFO NAMESPACE * x.y@domain.com@blueEKS.us-east-1.eksctl.io blueEKS.us-east-1.eksctl.io x.y@domain.com@blueEKS.us-east-1.eksctl.io
          x.y@domain.com@greenEKS.us-east-2.eksctl.io greenEKS.us-east-2.eksctl.io x.y@domain.com@greenEKS.us-east-2.eksctl.io

Como puede verse más arriba, habrá dos clusters diferentes registrados dentro de kubectl config. Actualmente, el contexto está establecido en blueEKS.us-east-1.eksctl.io y si queremos cambiar a greenEKS.us-east-2.eksctl.io racimo podemos simplemente hacer esto:

$ kubectl config use-context x.y@domain.com@greenEKS.us-east-2.eksctl.io Se ha cambiado al contexto "x.y@domain.com@greenEKS.us-east-2.eksctl.io".

$ kubectl get nodes NOMBRE ESTADO FUNCIONES ANTIGÜEDAD VERSIÓN ip-10-0-0-11.us-east-2.compute.internal Listo  20 m v1.14.8-eks-b8860f
ip-10-0-0-61.us-east-2.compute.internal Listo  20 m v1.14.8-eks-b8860f
ip-10-0-0-72.us-east-2.compute.internal Listo  20 m v1.14.8-eks-b8860f

A partir de aquí, cualquier kubectl que ejecutemos, estará en contexto con greenEKS.us-east-2.eksctl.io que se encuentra en este-2 (Ohio) región.

4. Despliegue del clúster Couchbase en dos regiones

En mi último blog sobre cómo desplegar Couchbase Cluster en EKS utilizando volúmenes persistentes...cubrí cada paso en detalle. Así que en lugar de repetir los pasos, aquí de nuevo, sólo voy a seguir para mantener las cosas simples.

4.1 Configuración del Cluster Verde

Empecemos a desplegar nuestro primer clúster Couchbase en este-2 región aka verde en este caso. Así que siguiendo los pasos del último bloglo haremos:

• Despliega Couchbase Autonomous Operator siguiendo los pasos 2.1 a 2.8.
• Cree el secreto y la clase de almacenamiento realizando los pasos 3.1 a 3.2

No vamos a utilizar el script de despliegue de clúster como se menciona allí, en su lugar, vamos a utilizar couchbase-green-cluster.yaml que creará un clúster Couchbase de tres nodos repartidos en tres zonas de disponibilidad diferentes (este-2a/2b/2c).

$ kubectl create -f couchbase-green-cluster.yaml -n emart --save-config couchbasecluster.couchbase.com/green creado

Nota: Es una buena práctica permitir spec.antiAffinity en couchbase-green-cluster.yaml para asegurarse de que cada nodo Kubernetes recibe un único pod. Esto asegura que si un nodo falla, sólo un pod de Couchbase se cae.

$ kubectl logs couchbase-operator-7654d844cb-tz7k5 -n emart -f time="2020-02-22T08:22:02Z" level=info msg="Estado del nodo:" cluster-name=green module=cluster
time="2020-02-22T08:22:02Z" level=info msg="┌────────────┬──────────────────┬──────────────┬────────────────┐" nombre-del-clúster=verde módulo=clúster hora="2020-02-22T08:22:02Z" nivel=información mensaje="│ Servidor │ Versión │ Clase │ Estado │" nombre-del-clúster=verde módulo=clúster
hora="2020-02-22T08:22:02Z" nivel=info msg="├────────────┼──────────────────┼──────────────┼────────────────┤" nombre-del-clúster=verde módulo=clúster hora="2020-02-22T08:22:02Z" nivel=información mensaje="│ verde-0000 │ enterprise-6.0.3 │ datos-este-2a │ administrado+activo │" nombre-del-clúster=verde módulo=clúster
time="2020-02-22T08:22:02Z" level=info msg="└────────────┴──────────────────┴──────────────┴────────────────┘" nombre-del-clúster=verde módulo=clúster hora="2020-02-22T08:22:02Z" nivel=info mensaje="Estado del programador:" nombre-del-clúster=verde módulo=clúster
hora="2020-02-22T08:22:02Z" nivel=info msg="┌──────────────┬────────────┬────────────┐" nombre-del-clúster=verde módulo=clúster
hora="2020-02-22T08:22:02Z" nivel=información mensaje="│ Clase │ Zona │ Servidor │" nombre-del-clúster=verde módulo=clúster
hora="2020-02-22T08:22:02Z" nivel=info mensaje="├──────────────┼────────────┼────────────┤" nombre-del-clúster=verde módulo=clúster
hora="2020-02-22T08:22:02Z" nivel=información mensaje="│ data-east-2a │ us-east-2a │ green-0000 │" nombre-del-clúster=green módulo=clúster
hora="2020-02-22T08:22:02Z" nivel=info msg="└──────────────┴────────────┴────────────┘" nombre-del-clúster=verde módulo=clúster
hora="2020-02-22T08:22:02Z" nivel=info nombre-del-clúster=verde módulo=clúster
hora="2020-02-22T08:22:08Z" nivel=información mensaje="Creando un pod (green-0001) que ejecuta Couchbase enterprise-6.0.3" nombre-del-clúster=verde módulo=clúster
hora="2020-02-22T08:23:21Z" nivel=info mensaje="miembro agregado (verde-0001)" nombre del clúster=verde módulo=clúster
hora="2020-02-22T08:23:21Z" nivel=información mensaje="Creando un pod (green-0002) que ejecuta Couchbase enterprise-6.0.3" nombre-del-clúster=green módulo=clúster
hora="2020-02-22T08:24:31Z" nivel=info mensaje="miembro agregado (green-0002)" nombre-del-clúster=green módulo=cluster
hora="2020-02-22T08:24:39Z" nivel=info mensaje="Progreso del reequilibrio: 0.000000" nombre-del-clúster=verde módulo=clúster
hora="2020-02-22T08:24:43Z" nivel=info mensaje="reconciliación finalizada" nombre-del-clúster=verde módulo=clúster

Ahora podemos hacer un port forward para ver la Couchbase Admin Console:

$ kubectl port-forward green-0000 8092:8091 -n emart Reenvío desde 127.0.0.1:8092 -> 8091 Reenvío desde [::1]:8092 -> 8091

A continuación, abra un navegador y escriba: https://localhost:8092/ para conectarse a la Consola Web de Couchbase de Verde racimo:

Figura 6: Tres nodos Clúster verde distribuidos en tres zonas de disponibilidad (AZ)

Crear un cubo vacío por defectoque se utilizará más adelante como cubo de destino al configurar XDCR.

Gráfico 7: Cubo de destino sin documentos

4.2 Configurar Blue Cluster

Tenemos que cambiar el contexto de kubectl config para poder trabajar con el cluster blueEKS.

$ kubectl config use-context x.y@domain.com@blueEKS.us-east-1.eksctl.io Se ha cambiado al contexto "x.y@domain.com@blueEKS.us-east-1.eksctl.io".

$ kubectl get nodes NOMBRE ESTADO FUNCIONES ANTIGÜEDAD VERSIÓN ip-172-16-0-25.ec2.internal Listo  2 h v1.14.8-eks-b8860f
ip-172-16-0-42.ec2.internal Listo  2 h v1.14.8-eks-b8860f ip-172-16-0-76.ec2.internal Listo  2 h v1.14.8-eks-b8860f

Después de cambiar el contexto, vamos a seguir los mismos pasos descritos anteriormente. Utilizaremos couchbase-cluster-azul.yaml para finalmente desplegar un cluster de tres nodos.

$ kubectl create -f couchbase-blue-cluster.yaml -n emart --save-config couchbasecluster.couchbase.com/green creado

Ahora echemos un vistazo a los registros del operador para comprobar el progreso:

$ kubectl obtener pods -n emart NOMBRE LISTO ESTADO REINICIOS ANTIGÜEDAD couchbase-operator-7654d844cb-58gch 1/1 En ejecución 0 4m22s
couchbase-operator-admission-7ff868f54c-57rhc 1/1 En ejecución 0 5m21s $ kubectl logs couchbase-operator-7654d844cb-58gch -n emart -f

time="2020-02-22T08:52:07Z" level=info msg="┌───────────┬──────────────────┬──────────────┬────────────────┐" cluster-name=blue module=cluster time="2020-02-22T08:52:07Z" level=info msg="│ Servidor │ Versión │ Clase │ Estado │" cluster-name=blue module=cluster
hora="2020-02-22T08:52:07Z" nivel=info msg="├───────────┼──────────────────┼──────────────┼────────────────┤" nombre-del-clúster=azul módulo=clúster hora="2020-02-22T08:52:07Z" nivel=información mensaje="│ azul-0000 │ enterprise-6.0.3 │ datos-este-1a │ administrado+activo │" nombre-del-clúster=azul módulo=clúster
hora="2020-02-22T08:52:07Z" nivel=info mensaje="└───────────┴──────────────────┴──────────────┴────────────────┘" nombre-del-clúster=azul módulo=clúster hora="2020-02-22T08:52:07Z" nivel=info mensaje="Estado del programador:" nombre-del-clúster=azul módulo=clúster
hora="2020-02-22T08:52:07Z" nivel=info mensaje="┌──────────────┬────────────┬───────────┐" nombre-del-clúster=azul módulo=clúster
hora="2020-02-22T08:52:07Z" nivel=info mensaje="│ Clase │ Zona │ Servidor │" nombre-del-clúster=azul módulo=clúster
hora="2020-02-22T08:52:07Z" nivel=info mensaje="├──────────────┼────────────┼───────────┤" nombre-del-clúster=azul módulo=clúster
hora="2020-02-22T08:52:07Z" nivel=info mensaje="│ data-east-1a │ us-east-1a │ azul-0000 │" nombre-del-clúster=azul módulo=clúster
hora="2020-02-22T08:52:07Z" nivel=información mensaje="└──────────────┴────────────┴───────────┘" nombre-del-clúster=azul módulo=clúster
hora="2020-02-22T08:52:07Z" nivel=información nombre-del-clúster=azul módulo=clúster
hora="2020-02-22T08:52:13Z" nivel=información mensaje="Creando un pod (azul-0001) que ejecuta Couchbase enterprise-6.0.3" nombre-del-clúster=azul módulo=clúster
hora="2020-02-22T08:53:27Z" nivel=información mensaje="miembro agregado (azul-0001)" nombre del clúster=azul módulo=clúster
hora="2020-02-22T08:53:27Z" nivel=info mensaje="Creando un pod (blue-0002) que ejecuta Couchbase enterprise-6.0.3" nombre-del-clúster=blue módulo=cluster
hora="2020-02-22T09:00:45Z" nivel=info mensaje="miembro agregado (blue-0002)" nombre-del-clúster=blue módulo=clúster
hora="2020-02-22T09:00:54Z" nivel=info mensaje="Progreso del reequilibrio: 0.000000" nombre-del-clúster=azul módulo=clúster
hora="2020-02-22T09:00:58Z" nivel=info mensaje="reconciliación finalizada" nombre-del-clúster=azul módulo=clúster

Reenvía la consola de administración de Couchbase al puerto 8091:

$ kubectl port-forward green-0000 8091:8091 -n emart Reenvío desde 127.0.0.1:8091 -> 8091 Reenvío desde [::1]:8091 -> 8091

Abra otra pestaña en su navegador y escriba: https://localhost:8091/ para conectarse a la Consola Web Couchbase de Azul racimo:

Figura 8: Clúster azul de tres nodos distribuidos en tres zonas de disponibilidad (AZ)

4.2.1 Crear un cubo de muestras de viajes

Vamos a utilizar viaje-muestra como los datos de origen, que replicaremos al destino verde cluster. Para crear un cubo de muestras, vaya a Configuración>Cubos de muestras y, a continuación, haga clic en la casilla situada junto a viaje-muestra. Eso creará el bucket requerido y rellenará un montón de documentos en el bucket.

Figura 9: Cubo fuente con algunos datos de muestra

Vamos a replicar este cubo de muestras de viajes en el clúster de destino de la región de Green (también conocida como Ohio).

5. 5. Configuración de la red

La diversión comienza con la sección de configuración de red. Si ya ha utilizado la consola de AWS para configurar la interconexión de VPC entre dos regiones o dos VPC independientes, esta sección le resultará muy sencilla. Y si quieres aprender a configurar VPC peering esta va a ser una gran experiencia de aprendizaje.

5.1 Configurar VPC Peering

El primer paso en el proceso de tres pasos es establecer el peering VPC desde la VPC solicitante a la VPC aceptante. En este paso, vamos a iniciar sesión en la región de Virginia utilizando la consola de AWS e iniciar la solicitud de peering. A continuación, iniciaremos sesión en la región de Ohio para aceptar esta solicitud.

5.1.1 Iniciar la solicitud de VPC desde la región Azul

Comencemos el proceso de iniciación del peering de la VPC conectándonos a la región de Virginia.

Figura 10: La consola de AWS muestra el resumen de recursos en la región de Virginia

1. Asegúrate de que has seleccionado la región solicitante desde la consola de AWS, que en nuestro caso es Virginia.
2. Abra la página del panel de control de la VPC.

Figura 11: Opción VPC peering en el panel de control de VPC

1. Seleccione Conexiones igualitarias del panel izquierdo.
2. Haga clic en Crear conexión paritaria de la página.

Una vez que haga clic en el botón que se va a presentar con una página de diálogo donde tenemos que:

1. Proporcione un nombre único a esta conexión de peering. Vamos a utilizar de azul a verde porque la región de Virginia alberga nuestro clúster Azul y Ohio alberga nuestro clúster Verde.

Gráfico 12: Configuración de VPC peering requester y acceptor.

1. Seleccione el ID de VPC del clúster Blue, ya que es el solicitante.
2. Nuestro clúster de destino se encuentra en una región diferente, por lo que vamos a seleccionar Otra región como opción para Región.
3. Seleccione a continuación la región de destino, que es Ohio.
4. En la tabla 2 hemos anotado los ID de VPC de ambas VPC. Por lo tanto, utilizaremos el ID de VPC del clúster verde.
5. Hit Crear conexión paritaria botón.

Gráfico 13: Solicitud de interconexión establecida.

Aparecerá la página de confirmación. Haga clic en OK y le mostrará que se ha iniciado la solicitud.

5.1.2 Aceptar la solicitud de VPC de la región Verde

Ahora desde la consola de AWS cambia la región a Ohio (aka Green region) y luego selecciona VPC Dashboard.

Gráfico 14: Seleccione la región us-east-2 (Ohio)

• Igual que antes de seleccionar el Conexiones igualitarias del panel izquierdo para que podamos completar la solicitud de interconexión aceptándola.

Figura 15: Seleccione Conexiones igualitarias opciones desde VPC Dashboard

• Como se puede ver arriba, hay una solicitud pendiente en la lista. Seleccionaremos la solicitud en primer lugar.

Figura 16: Aceptar solicitud de interconexión VPC

• A continuación, desde el Acciones seleccionaremos Aceptar solicitud.

Figura 17: Confirme la solicitud de VPC peering desde la ventana emergente

• Aparecerá una página de confirmación. Seleccione Sí, aceptar botón.

Figura 18: Se establece la conexión VPC peering de origen-destino

Esto completa el primer paso del peering de la VPC ya que el estado del peering es Activo.

5.2 Actualizar tablas de enrutamiento

El segundo paso consiste en establecer el canal de comunicación añadiendo el bloque CIDR del clúster de destino en las tablas de rutas. Para ello necesitamos averiguar en qué subredes reside cada una de las tres instancias EC2.

Una vez que tenemos la lista de subredes en cada una de las tres AZs (1a, 1b, 1c) donde tenemos nodos trabajadores Kubernetes ejecutándose, necesitamos encontrar la Tabla de Enrutamiento asociada con cada una de las tres subredes. Para estas tablas de enrutamiento, nos gustaría añadir una entrada de tabla de enrutamiento para que permita el tráfico procedente de otra VPC a través de VPC peering. Veámoslo paso a paso.

5.2.1 Subredes utilizadas en Blue Cluster

1. Inicie sesión en la consola de AWS y seleccione la región de Virginia (también conocida como región azul). A continuación, seleccione el servicio EC2 para ver todas las instancias EC2 utilizadas como nodos Kubernetes.

Figura 19: Subred asociada a cada una de las instancias EC2.

1. A continuación, seleccione una de las instancias EC2. En la imagen de arriba he seleccionado instancias en la región us-east-1a y la pestaña de descripción mostrará todos los detalles sobre esta instancia.
2. Anote el nombre de la subred (mencionada entre paréntesis) en la que reside esta instancia. Por ejemplo, la instancia anterior está desplegada en eksctl-blueEKS-cluster/SubnetPublicUSEAST1A subred.
3. Repita el mismo proceso hasta que tenga la lista de todas las subredes utilizadas en su cluster. En nuestro caso tenemos estas tres subredes utilizadas dentro de nuestro cluster:

Atributos	us-este-1a	us-este-1b	us-este-1c
Nombre de subred	eksctl-blueEKS-cluster/SubnetPublicUSEAST1A	eksctl-blueEKS-cluster/SubnetPublicUSEAST1B	eksctl-blueEKS-cluster/SubnetPublicUSEAST1C

5.2.2 Tabla de encaminamiento asociada a subredes

El siguiente paso sería averiguar la tabla de enrutamiento asociada a cada una de las subredes, para poder añadirle la regla de enrutamiento que permita el tráfico desde Green cluster.

Figura 20: Tablas de enrutamiento asociadas a cada subred del cluster

1. Para encontrar la tabla de enrutamiento utilizada, haga clic en Subredes de la izquierda.
2. A continuación, seleccione una de las subredes de la lista eksctl-blueEKS-cluster/SubnetPublicUSEAST1A
3. Tome nota de la tabla de enrutamiento utilizada buscando en el campo Descripción ficha.
4. Repita los tres pasos anteriores para cada una de las subredes y anote la tabla de enrutamiento utilizada:

Atributos	us-este-1a	us-este-1b	us-este-1c
Nombre de subred	eksctl-blueEKS-cluster/SubnetPublicUSEAST1A	eksctl-blueEKS-cluster/SubnetPublicUSEAST1B	eksctl-blueEKS-cluster/SubnetPublicUSEAST1C
Nombre de la tabla de rutas	eksctl-blueEKS-cluster/PublicRouteTable	eksctl-blueEKS-cluster/PublicRouteTable	eksctl-blueEKS-cluster/PublicRouteTable

Como puede observarse, en nuestro caso tenemos una tabla de rutas eksctl-blueEKS-cluster/PublicRouteTable asociadas a las tres subredes, por lo que vamos a actualizar sólo una Tabla de Rutas.

5.2.3 Añadir regla de enrutamiento

Ahora vamos a añadir 10.0.0.0/24 bloque CIDR de la región de destino en el enrutamiento permitido Rutas de la tabla de enrutamiento de origen.

Figura 21: Pestaña de Tablas de Ruta que muestra la lista de Tablas de Ruta existentes en la región Azul

1. Haga clic en el botón Tablas de encaminamiento del menú izquierdo de la consola de AWS.
2. Seleccione la tabla de rutas a la que desea añadir la entrada de ruta, por ejemplo eksctl-blueEKS-cluster/PublicRouteTable.
3. A continuación, haga clic en el botón Rutas junto a la pestaña de resumen, donde sólo vería dos entradas de ruta.
4. Para permitir 10.0.0.0/24 CIDR haga clic en el botón Editar rutas botón.

Figura 22: Página de diálogo Editar rutas.

1. En el cuadro de diálogo anterior, añada el bloque CIDR del clúster VERDE y seleccione VPC-Peering como destino. A continuación, pulse guardar rutas botón.
2. Verá el bloque CIDR de destino 10.0.0.0/24 forma parte ahora del Rutas disponibles para la tabla de rutas seleccionada: eksctl-blueEKS-cluster/PublicRouteTable

Figura 23: Tabla de rutas que muestra el bloque CIDR de destino como ruta permitida.

Nota: Repite el mismo proceso para el cluster de Ohio (alias Verde) y añade el bloque CIDR de Virginia (alias Azul) en la Tabla de Rutas.

Figura 24: Tabla de rutas que muestra el bloque CIDR del cluster azul en la tabla de rutas del cluster verde.

5.3 Actualizar el Grupo de Seguridad

El último paso para configurar la red tanto en el clúster de origen como en el de destino es abrir una serie de puertos a través de los cuales los nodos de trabajo K8s se comunicarán entre sí. Estos puertos se utilizarán para Comunicación XDCR por lo que o bien abrimos el puerto 30000-32767 o lo restringimos a un único puerto que se utilizará para la red de superposición como se describe en la sección 6.0.

5.3.1 Configuración de las reglas de entrada

Para mantener las cosas simples vamos a permitir que el rango de puertos esté abierto en el NodeGroup usado como nodos trabajadores K8s. Para cambiar la configuración del firewall siga estos pasos:

Figura 25: Configure un grupo de seguridad en el clúster Virginia (también conocido como Blue).

1. Haga clic en el botón Grupos de seguridad en el panel izquierdo de la consola de AWS para la región de Virginia.
2. A continuación, localice el grupo de seguridad (SG) con -nodegrupo-grupo-azul como cadena. Este SG se utiliza como la configuración del cortafuegos para todos los nodos trabajadores de su nodegroup de Kubernetes.
3. Haga clic en Normas de entrada que muestra un rango de puertos abiertos para el recurso respectivo.
4. Siguiente clic Editar reglas para añadir la nueva regla a la lista.

Figura 26: Añada una regla de cortafuegos para que los clústeres de origen y destino puedan comunicarse entre sí.

1. Como se describe en la imagen anterior, añada una nueva regla TCP para el rango de puertos 30000-32767 y utilice el bloque CIDR 10.0.0.0/24 del clúster de destino, es decir, el clúster Ohio (también conocido como Verde). Esto completa la configuración para el tráfico entrante.

5.3.2 Configuración de reglas de salida

1. Ahora vamos a crear una regla similar para las comunicaciones salientes. Para ello, haga clic en el botón Normas de salida como se describe a continuación.

Figura 27: Configuración de reglas de salida para el grupo de seguridad seleccionado.

1. Haga clic en el botón Editar reglas para añadir una nueva regla.

Figura 28: Ruta de salida actualizada con regla adicional.

1. Al igual que antes, añadiremos un nuevo Regla TCP personalizada y permiten puertos que van desde 30000-32767 para poder comunicarse con el bloque CIDR de destino 10.0.0.0/24.

Nota: Al igual que hemos añadido una regla de firewall en el Nodegroup del Cluster Azul, tenemos que hacer lo mismo en el Nodegroup del Cluster Verde.

Después de terminar la configuración de red tanto de origen como de destino, los clusters deberían ser capaces de comunicarse en los rangos de puertos que hemos utilizado y estamos listos para ir al siguiente paso de configurar realmente el XDCR para que los datos puedan ser replicados desde el cubo de origen al de destino a través de la región.

6.0 Replicación XDCR con red superpuesta

Echa un vistazo al siguiente diagrama, que supone que dos nodos en clústeres Kubernetes separados pueden comunicarse entre sí. El enrutador representado podría ser un conmutador, un router, una conexión VPN o cualquier otra infraestructura que permita la comunicación de capa 3.

Figura 29: XDCR a un clúster Kubernetes diferente mediante redes superpuestas.

En el diagrama, el pod del Cluster 1 sólo puede conectarse al puerto del nodo (31202) expuesto en el Cluster 2. Además, ese puerto sólo está expuesto al nodo en el que se ejecuta el pod. Además, ese puerto sólo está expuesto al nodo en el que se está ejecutando el pod. Para determinar la cadena de conexión correcta en el cluster de destino XDCR siga el procedimiento:

• Lista los pods de Couchbase desplegados en el cluster de destino. Si queremos configurar la replicación XDCR en el cluster Blue entonces ejecuta este comando desde la consola Verde racimo:

$ kubectl obtener pods -n emart

NAME READY STATUS RESTARTS AGE green-0000 1/1 Running 0 7m39s green-0001 1/1 Running 0 6m19s green-0002 1/1 Running 0 5m8s

• Elija uno de los pods de Couchbase y obtenga la dirección IP de su nodo GKE subyacente:

$ kubectl obtener pod green-0000 -o yaml -n emart | grep hostIP hostIP: 10.0.0.5

• Obtén el número de puerto que corresponde al puerto admin (8091).

$ kubectl obtener servicio green-0000-exposed-ports -n emart NOMBRE TIPO CLUSTER-IP EXTERNAL-IP PUERTO(S) EDAD
green-0000-exposed-ports NodePort 172.20.55.204  11210:32262/TCP,11207:31500/TCP,8093:32209/TCP,18093:31965/TCP,8091:30964/TCP,18091:30093/TCP,8092:31555/TCP,18092:30041/TCP 7m3s

Si estuvieras conectado a la Consola Web de Couchbase Server en el cluster Azul, y establecieras la conexión XDCR con el cluster Verde, utilizarías la cadena de conexión 10.0.0.5:30964 basándose en el ejemplo anterior.

6.1. XDCR del clúster Azul al Verde

Vamos a configurar una replicación unidireccional desde el directorio Azul a la Verde racimo. Encontrará más información en Documentación XDCR.

Conectémonos primero a la Consola Web de Couchbase de la plataforma Azul clúster utilizando el método de reenvío de puertos.

Nota: Ya tenemos la redirección de puertos en ejecución para ambos clústeres verdes utilizando el puerto 8092 y Blue cluster utilizando un puerto 8091.

En el grupo Azul https://localhost:8091:

• Añadir referencia de clúster del verde racimo.

Gráfico 30: Conexión XDCR del grupo Azul al Verde.

• Se ha añadido la referencia al clúster remoto.

Figura 31: Replicación establecida.

• Añadir replicación de cubos desde viaje-muestra cubo a por defecto en el clúster Verde.

Figura 32: Configuración de la replicación de cubos de origen a destino.

• Su cubo se está replicando desde Azul a Verde racimo.

Figura 33: Replicación activa de cubos de Virginia al clúster de Ohio.

7. Conclusión

En este artículo, hemos desentrañado los detalles de la red para mostrarte lo fácil que es configurar VPC peering entre regiones en el contexto de Couchbase Autonomous Operator. Hemos utilizado una de las plataformas en la nube para impulsar el despliegue de los clústeres de Couchbase geodistribuidos, pero lo que queremos destacar es que una vez que entiendas los conceptos, aplicarlos en cualquier otra plataforma en la nube será una progresión sencilla.