Implementación multirregional en AKS

En este tema, se explica cómo configurar una implementación multirregional para Apigee Hybrid en Microsoft® Azure Kubernetes Service (AKS).

Las topologías para la implementación multirregión incluyen lo siguiente:

Activa-Activa: Cuando tienes aplicaciones implementadas en varias ubicaciones geográficas y necesitas una respuesta de API con baja latencia para tus implementaciones. Tienes la opción de implementar Hybrid en varias ubicaciones geográficas más cercanas a tus clientes. Por ejemplo, la costa oeste de EE.UU., la costa este de EE.UU., Europa y APAC.
Activo-pasivo: Cuando tienes una región principal y una de conmutación por error o una de recuperación ante desastres.

Las regiones de una implementación híbrida multirregional se comunican a través de Cassandra, como se muestra en la siguiente imagen:

Requisitos previos

Antes de configurar Hybrid para varias regiones, debes completar los siguientes requisitos:

Antes de pasar a los pasos de configuración del clúster, sigue la guía de instalación de híbrido para conocer los requisitos previos, como GCP y la configuración de la organización.

Consulta la documentación de Kubernetes para obtener información detallada.

Crea una red virtual en cada región

Crea una red virtual para la implementación multirregional. Por ejemplo, los siguientes comandos de ejemplo crean redes en las regiones del centro de EE.UU. y del este de EE.UU.

Ejecuta este comando para crear una red virtual en la región este de EE.UU. con el nombre my-hybrid-rg-vnet:

az network vnet create \
 --name my-hybrid-rg-vnet \
 --location eastus \
 --resource-group my-hybrid-rg \
 --address-prefixes 120.38.1.0/24 \
 --subnet-name my-hybrid-rg-vnet-subnet \
 --subnet-prefix 120.38.1.0/26

Ejecuta este comando para crear una red virtual en la región central de EE.UU. con el nombre my-hybrid-rg-vnet-ext01:

az network vnet create \
 --name my-hybrid-rg-vnet-ext01 \
 --location centralus \
 --resource-group my-hybrid-rg \
 --address-prefixes 192.138.0.0/24 \
 --subnet-name my-hybrid-rg-vnet-ext01-subnet \
 --subnet-prefix 192.138.0.0/26

Crea un intercambio de tráfico entre redes

Crea un intercambio de tráfico de redes entre las redes virtuales.

Obtén los ID de redes virtuales

Los intercambios de tráfico se establecen entre los ID de red virtual. Obtén el ID de cada red virtual con el comando az network vnet show y almacena el ID en una variable.

Obtén el ID de la segunda red virtual, que se llama my-hybrid-rg-vnet:

vNet1Id=$(az network vnet show \
 --resource-group my-hybrid-rg \
 --name my-hybrid-rg-vnet \
 --query id --out tsv)

Obtén el ID de la segunda red virtual, que se llama my-hybrid-rg-vnet-ext01:

vNet2Id=$(az network vnet show \
 --resource-group my-hybrid-rg \
 --name my-hybrid-rg-vnet-ext01 \
 --query id \
 --out tsv)

Crea un intercambio de tráfico entre la primera y la segunda red virtual

Con los ID de redes virtuales, puedes crear un intercambio de tráfico desde la primera red virtual (my-hybrid-rg-vnet) hasta la segunda (my-hybrid-rg-vnet-ext01), como se muestra en estos ejemplos:

Si no especificas el parámetro --allow-vnet-access, se establece un intercambio de tráfico, pero ninguna comunicación puede fluir a través de él.

az network vnet peering create \
 --name my-hybrid-rg-vnet1-peering \     # The name of the virtual network peering.
 --resource-group my-hybrid-rg \
 --vnet-name my-hybrid-rg-vnet \         # The virtual network name.
 --remote-vnet $vNet2Id \                # Resource ID of the remote virtual network.
 --allow-vnet-access

En el resultado del comando, ten en cuenta que peeringState es Initiated. El intercambio de tráfico permanecerá en el estado Iniciado hasta que crees el intercambio de tráfico desde la segunda red virtual hasta la primera.

{
  ...
  "peeringState": "Initiated",
  ...
}

Crea un intercambio de tráfico de la segunda red virtual a la primera

Comando de ejemplo:

az network vnet peering create \
 --name my-hybrid-rg-vnet2-peering \        # The name of the virtual network peering.
 --resource-group my-hybrid-rg \
 --vnet-name my-hybrid-rg-vnet-ext01 \      # The virtual network name.
 --remote-vnet $vNet1Id \                   # Resource ID of the remote virtual network.
 --allow-vnet-access

En el resultado del comando, ten en cuenta que peeringState está conectado. Azure también cambia el estado de intercambio de tráfico del intercambio de tráfico de que va desde la primera red virtual a la segunda a Conectado.

{
  ...
  "peeringState": "Connected",
  ...
}

También puedes confirmar que el estado de intercambio de tráfico de my-hybrid-rg-vnet1-peering a my-hybrid-rg-vnet2-peering se cambió a Intercambio de tráfico a conectado con el siguiente comando:

az network vnet peering show \
 --name my-hybrid-rg-vnet1-peering \
 --resource-group my-hybrid-rg \
 --vnet-name my-hybrid-rg-vnet \
 --query peeringState

Resultado esperado:

Connected

Crea clústeres multirregionales

Configura clústeres de Kubernetes en varias regiones con diferentes bloques CIDR. Consulta también el Paso 1: Crea un clúster. Usa las ubicaciones y los nombres de las redes virtuales que creaste antes.

Abre los puertos de Cassandra 7000 y 7001 entre clústeres de Kubernetes en todas las regiones (7000 se puede usar como opción de copia de seguridad durante la solución de problemas)

Configura el host de origen de varias regiones

En esta sección, se describe cómo expandir el clúster existente de Cassandra a una región nueva. Esta configuración permite que la región nueva inicie el clúster y se una al centro de datos existente. Sin esta configuración, los clústeres de Kubernetes multirregionales no se reconocen entre sí.

Configure el contexto de kubectl en el clúster original antes de recuperar el nombre de origen:
```
kubectl config use-context original-cluster-name
```
Ejecuta el siguiente comando kubectl para identificar una dirección de host de origen de Cassandra en la región actual.

Una dirección de host de origen permite que una instancia regional nueva encuentre el clúster original en el primer startup para obtener la topología del clúster. La dirección del host de origen se designa como el punto de contacto en el clúster.
```
kubectl get pods -o wide -n apigee | grep apigee-cassandra

apigee-cassandra-default-0  1/1   Running   0   4d17h   120.38.1.9  aks-agentpool-21207753-vmss000000
```
Decide cuál de las IP que se muestran del comando anterior será el host de origen multirregión. En este ejemplo, en el que solo se ejecuta un clúster de Cassandra de nodo, el host de origen es 120.38.1.9.
En el centro de datos 2, copia tu archivo de anulación a un archivo nuevo cuyo nombre incluya el nombre del clúster. Por ejemplo, overrides_your_cluster_name.yaml
En el centro de datos 2, configura cassandra.multiRegionSeedHost y cassandra.datacenter en overrides_your_cluster_name.yaml, en el que multiRegionSeedHost es una de las IP que muestra el comando anterior:
```
cassandra:
  multiRegionSeedHost: seed_host_IP
  datacenter: data_center_name
  rack: rack_name
```
Por ejemplo:
```
cassandra:
  multiRegionSeedHost: 120.38.1.9
  datacenter: "centralus"
  rack: "ra-1"
```
Antes de instalar Hybrid, en el centro de datos o la región nuevos, configura los mismos certificados TLS y las credenciales en overrides_your_cluster_name.yaml que configuraste en la primera región.
NOTA: Asegúrate de usar los mismos certificados y credenciales TLS de Cassandra en el segundo centro de datos que proporcionaste en el centro de datos original. Las credenciales que establezcas en el archivo de anulación del primer centro de datos deben coincidir con las que especifiques en el archivo de anulación del segundo centro de datos. Si quieres obtener más información, consulta Configura TLS para Cassandra.

Configura la región nueva

Después de configurar el host de origen, puedes configurar la región nueva.

Para configurar la región nueva, haz lo siguiente:

Copia tu certificado del clúster existente en el clúster nuevo. Cassandra y otros componentes híbridos para mTLS usan la raíz de CA nueva. Por lo tanto, es fundamental tener certificados coherentes en todo el clúster.
1. Establece el contexto en el espacio de nombres original:
```
kubectl config use-context original-cluster-name
```
2. Exporta la configuración del espacio de nombres actual a un archivo:
```
$ kubectl get namespace namespace -o yaml > apigee-namespace.yaml
```
3. Exporta el Secret apigee-ca a un archivo:
```
kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
```
4. Establece el contexto en el nombre del clúster de la región nueva:
```
kubectl config use-context new-cluster-name
```
5. Importa la configuración del espacio de nombres al clúster nuevo. Asegúrate de actualizar el “espacio de nombres” en el archivo si usas un espacio de nombres diferente en la región nueva:
```
kubectl apply -f apigee-namespace.yaml
```
6. Importa el secreto al clúster nuevo:
```
kubectl -n cert-manager apply -f apigee-ca.yaml
```
Instala el híbrido en la nueva región. Asegúrate de que el archivo overrides_your_cluster_name.yaml incluya los mismos certificados TLS que se configuraron en la primera región, como se explica en la sección anterior.
Ejecuta los siguientes dos comandos para instalar el servicio híbrido en la región nueva:
```
apigeectl init -f overrides_your_cluster_name.yaml
```
```
apigeectl apply -f overrides_your_cluster_name.yaml
```
Ejecuta nodetool rebuild de manera secuencial en todos los nodos en el nuevo centro de datos. Esto puede llevar unos minutos hasta algunas horas según el tamaño de los datos.
```
kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw JMX_password rebuild -- dc-1
```
En el que JMX_user y JMX_password son el nombre de usuario y la contraseña para el usuario de Cassandra JMX.

Verifica los procesos de recompilación de los registros. Además, verifica el tamaño de los datos mediante el comando nodetool status:

kubectl logs apigee-cassandra-default-0 -f -n apigee

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw JMX_password status

El siguiente ejemplo muestra entradas de registro de ejemplo:

INFO  01:42:24 rebuild from dc: dc-1, (All keyspaces), (All tokens)
INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Executing streaming plan for Rebuild
INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.1.45
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.1.45
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.4.36
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.432KiB), sending 0 files(0.000KiB)
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.1.45 is complete
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.4.36
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.5.22
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.693KiB), sending 0 files(0.000KiB)
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.4.36 is complete
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.5.22
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 3 files(0.720KiB), sending 0 files(0.000KiB)
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.5.22 is complete
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] All sessions completed

Actualiza los hosts de origen. Quita multiRegionSeedHost: 10.0.0.11 de overrides-DC_name.yaml y vuelve a enviar la solicitud.
Los hosts de origen son miembros del clúster local. Para iniciar una nueva región, se requiere un host de origen externo. Una vez que se inicia una región, debes cambiar los hosts de origen a sus clústeres locales en overrides.yaml y, luego, volver a aplicar la configuración.
```
apigeectl apply -f overrides-DC_name.yaml
```