Déploiement multirégional sur AKS

Cet article explique comment configurer un déploiement multirégional pour Apigee hybrid sur Microsoft® Azure Kubernetes Service (AKS).

Voici quelques exemple de topologies pour le déploiement multirégional :

Actif/Actif : lorsque des applications sont déployées dans plusieurs emplacements géographiques et que vous avez besoin d'une réponse d'API à faible latence pour vos déploiements. Vous avez la possibilité de déployer un environnement hybride dans plusieurs emplacements géographiques les plus proches de vos clients. Par exemple : la côte ouest des États-Unis, la côte est des États-Unis, l'Europe, l'Asie-Pacifique.
Actif/Passif : lorsque vous disposez d'une région principale et d'une région de basculement ou de reprise après sinistre.

Les régions d'un déploiement hybride multirégional communiquent via Cassandra, comme le montre l'image suivante :

Prérequis

Avant de configurer un environnement hybride pour plusieurs régions, vous devez remplir les conditions préalables suivantes :

Suivez le guide d'installation de la solution hybride pour connaître les conditions préalables relatives à GCP et la configuration d'organisation avant de passer aux étapes de configuration du cluster.

Pour en savoir plus, consultez la documentation concernant Kubernetes.

Créer un réseau virtuel dans chaque région

Créez un réseau virtuel pour le déploiement multirégional. Par exemple, les commandes suivantes créent des réseaux dans les régions du centre et de l'est des États-Unis.

Exécutez cette commande pour créer un réseau virtuel dans la région de l'est des États-Unis, portant le nom 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

Exécutez cette commande pour créer un réseau virtuel dans la région du centre des États-Unis, portant le nom 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

Créer un appairage de réseaux

Créez un appairage de réseaux entre les réseaux virtuels.

Obtenir les identifiants de réseaux virtuels

Les appairages sont établis entre les identifiants de réseaux virtuels. Obtenez l'ID de chaque réseau virtuel à l'aide de la commande az network vnet show et stockez l'ID dans une variable.

Obtenez l'ID du premier réseau virtuel, celui nommé my-hybrid-rg-vnet :

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

Récupérez l'ID du deuxième réseau virtuel, appelé 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)

Créer un appairage à partir du premier réseau virtuel vers le deuxième

Avec les ID de réseaux virtuels, vous pouvez créer un appairage du premier réseau virtuel (my-hybrid-rg-vnet) vers le deuxième (my-hybrid-rg-vnet-ext01), comme illustré dans les exemples suivants :

Si vous ne spécifiez pas le paramètre --allow-vnet-access, un appairage est établi, mais aucune communication ne peut y circuler.

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

Dans le résultat de la commande, notez que peeringState est Lancé. L'appairage reste à l'état "Lancé" jusqu'à ce que vous créiez l'appairage du second réseau virtuel vers le premier.

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

Créer un appairage à partir du deuxième réseau virtuel vers le premier

Exemple de commande :

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

Dans le résultat de la commande, notez que peeringState est Connecté. Azure fait également passer l'état d'appairage du premier réseau virtuel vers le second à Connecté.

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

Vous pouvez également vérifier que l'état d'appairage pour my-hybrid-rg-vnet1-peering est défini sur my-hybrid-rg-vnet2-peering : l'appairage est passé à "Connecté" à l'aide de la commande suivante :

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

Résultat attendu :

Connected

Créer des clusters multirégionaux

Configurez des clusters Kubernetes dans plusieurs régions avec des blocs CIDR différents. Consultez également l'étape 1 : Créer un cluster. Utilisez les emplacements et les noms de réseaux virtuels que vous avez créés précédemment.

Ouvrez les ports Cassandra 7 000 et 7 001 entre les clusters Kubernetes dans toutes les régions (les ports 7 000 peuvent être utilisées comme option de sauvegarde lors du dépannage).

Configurer l'hôte source multirégional

Cette section décrit comment étendre le cluster Cassandra existant à une nouvelle région. Cette configuration permet à la nouvelle région d'amorcer le cluster et de rejoindre le centre de données existant. Sans cette configuration, les clusters Kubernetes multirégionaux ne se connaîtraient pas les uns les autres.

Définissez le contexte kubectl sur le cluster d'origine avant de récupérer le nom source :
```
kubectl config use-context original-cluster-name
```
Exécutez la commande kubectl suivante pour identifier une adresse d'hôte source pour Cassandra dans la région actuelle.

Une adresse hôte source permet à une nouvelle instance régionale de trouver le cluster d'origine lors du premier démarrage pour apprendre la topologie du cluster. L'adresse hôte source est désignée comme point de contact dans le cluster.
```
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
```
Déterminez quelles adresses IP renvoyées par la commande précédente seront les hôtes sources multirégionaux. Dans cet exemple, où un cluster Cassandra à nœud unique est exécuté, l'hôte source est 120.38.1.9.
Dans le centre de données 2, copiez votre fichier de remplacement dans un nouveau fichier dont le nom inclut le nom du cluster. Par exemple, overrides_your_cluster_name.yaml.
Dans le centre de données 2, configurez cassandra.multiRegionSeedHost et cassandra.datacenter dans overrides_your_cluster_name.yaml, où multiRegionSeedHost est l'une des adresses IP renvoyées par la commande précédente :
```
cassandra:
  multiRegionSeedHost: seed_host_IP
  datacenter: data_center_name
  rack: rack_name
```
Exemple :
```
cassandra:
  multiRegionSeedHost: 120.38.1.9
  datacenter: "centralus"
  rack: "ra-1"
```
Dans le nouveau centre de données/région, avant d'installer un environnement hybride, définissez les mêmes certificats et identifiants TLS dans overrides_your_cluster_name.yaml que ceux définis dans la première région.
REMARQUE : Veillez à utiliser les mêmes certificats et identifiants TLS Cassandra que dans le centre de données d'origine dans le deuxième centre de données. Les identifiants que vous avez définis dans le fichier de remplacement du premier centre de données doivent correspondre à ceux que vous avez spécifiés dans le fichier de remplacement du deuxième centre de données. Pour en savoir plus, consultez la section Configurer TLS pour Cassandra.

Configurer la nouvelle région

Après avoir configuré l'hôte source, vous pouvez configurer la nouvelle région.

Pour configurer la nouvelle région, procédez comme suit :

Copiez votre certificat à partir du cluster existant vers le nouveau cluster. Le nouveau certificat racine CA est utilisé par Cassandra et d'autres composants hybrides pour mTLS. Par conséquent, il est essentiel de disposer de certificats cohérents dans l'ensemble du cluster.
1. Définissez le contexte sur l'espace de noms d'origine :
```
kubectl config use-context original-cluster-name
```
2. Exportez la configuration actuelle de l'espace de noms dans un fichier :
```
$ kubectl get namespace namespace -o yaml > apigee-namespace.yaml
```
3. Exportez le secret apigee-ca vers un fichier :
```
kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
```
4. Définissez le contexte sur le nom du cluster de la nouvelle région :
```
kubectl config use-context new-cluster-name
```
5. Importez la configuration de l'espace de noms dans le nouveau cluster. Veillez à mettre à jour l'espace de noms dans le fichier si vous utilisez un autre espace de noms dans la nouvelle région :
```
kubectl apply -f apigee-namespace.yaml
```
6. Importez le secret dans le nouveau cluster :
```
kubectl -n cert-manager apply -f apigee-ca.yaml
```
Installez la version hybride dans la nouvelle région. Assurez-vous que le fichier overrides_your_cluster_name.yaml inclut les mêmes certificats TLS que ceux configurés dans la première région, comme expliqué dans la section précédente.
Exécutez les deux commandes suivantes pour installer un environnement hybride dans la nouvelle région :
```
apigeectl init -f overrides_your_cluster_name.yaml
```
```
apigeectl apply -f overrides_your_cluster_name.yaml
```
Exécutez nodetool rebuild de manière séquentielle sur tous les nœuds du nouveau centre de données. Cette opération peut prendre de quelques minutes à quelques heures en fonction de la taille de vos données.
```
kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw JMX_password rebuild -- dc-1
```
Où JMX_user et JMX_password sont le nom d'utilisateur et le mot de passe de l'utilisateur Cassandra JMX.

Vérifiez les processus de recompilation des journaux. Vérifiez également la taille des données à l'aide de la commande 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

L'exemple suivant montre des entrées de journal :

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

Mettez à jour les hôtes sources. Supprimez multiRegionSeedHost: 10.0.0.11 de overrides-DC_name.yaml, puis recommencez la même opération.
Les hôtes sources sont des membres de clusters locaux. Pour démarrer une nouvelle région, un hôte source externe est requis. Une fois qu'une région démarre, vous devez faire revenir les hôtes sources à leurs clusters locaux dans overrides.yaml, puis appliquer à nouveau la configuration.
```
apigeectl apply -f overrides-DC_name.yaml
```