Alibaba Cloud Service Mesh:Configurer la reprise après sinistre multi-cluster avec une architecture de plan de contrôle multi-master ASM

Contexte

L'architecture de plan de contrôle multi-master est un modèle permettant de gérer plusieurs clusters Kubernetes à l'aide d'un maillage de services. Dans cette architecture, chaque instance Service Mesh (ASM) gère les composants du plan de données de son cluster Kubernetes correspondant et distribue les configurations aux proxies du maillage au sein de ce cluster. En partageant un certificat racine commun, ces instances permettent la découverte de services et la communication inter-clusters.

Par rapport à l'ajout de plusieurs clusters à une seule instance ASM, une architecture de plan de contrôle multi-master présente les avantages suivants :

• Latence de distribution des configurations réduite : Les clusters multiples s'étendent souvent sur différentes régions, zones ou VPC. Dans ce scénario, l'utilisation de plusieurs instances ASM géographiquement plus proches de leurs clusters Kubernetes respectifs permet une distribution plus rapide des configurations vers les proxies du maillage.

• Isolation améliorée des configurations et des environnements : Chaque cluster est géré par une instance ASM distincte. Cela vous permet de déployer différentes ressources de plan de contrôle, facilitant ainsi les versions canari ou l'isolation des configurations et des versions. Lors de la mise à niveau des instances ASM, vous pouvez mettre à jour les plans de contrôle par lots, ce qui améliore la disponibilité de votre environnement de production.

• Stabilité accrue : Dans des scénarios extrêmes, tels qu'une panne de zone ou de région, un plan de contrôle unique connecté à tous les clusters peut devenir un point de défaillance unique, empêchant la synchronisation des configurations. Dans une architecture de plan de contrôle multi-master, les proxies du maillage situés dans des régions ou des zones saines peuvent toujours se connecter à leurs plans de contrôle locaux, garantissant que la distribution des configurations et le démarrage des proxies du maillage ne sont pas affectés.

Pour construire une architecture de plan de contrôle multi-master, vous devez créer plusieurs instances ASM qui partagent le même certificat racine ASM. Le plan de contrôle utilise ce certificat racine pour signer les certificats d'identité des proxies du maillage. Grâce à un certificat racine partagé, les proxies du maillage connectés à différentes instances ASM peuvent établir une confiance mutuelle et communiquer entre eux via mTLS.

Prérequis

Deux clusters managés ACK, nommés cluster-1 et cluster-2, sont requis. Les deux clusters doivent avoir l'option Expose API server with EIP activée. Pour plus d'informations, consultez Créer un cluster managé ACK.

Étape 1 : Créer deux instances ASM avec un certificat racine partagé

1. Connectez-vous à la console ASM. Dans le volet de navigation de gauche, accédez à Service Mesh > Mesh Management.

2. Sur la page Mesh Management, cliquez sur Create ASM Instance. Le tableau suivant décrit les paramètres clés.

   Parameter	Value
   Service mesh name	mesh-1.
   Region	Sélectionnez la même région que le cluster cluster-1.
   Istio version	Sélectionnez v1.22.6.71-g7d67a80b-aliyun ou une version ultérieure.
   Kubernetes clusters	Sélectionnez cluster-1. Les paramètres VPC et vSwitch sont renseignés automatiquement.

   Pour plus d'informations sur les autres paramètres, consultez Créer une instance ASM. Une fois l'instance créée, attendez 2 à 3 minutes jusqu'à ce que le statut de l'instance mesh-1 passe à Running.

3. Sur la page Mesh Management, cliquez à nouveau sur Create ASM Instance. Le tableau suivant décrit les paramètres clés.

   Parameter	Value
   Service mesh name	mesh-2.
   Region	Sélectionnez la même région que le cluster cluster-2.
   Istio version	Sélectionnez v1.22.6.71-g7d67a80b-aliyun ou une version ultérieure.
   Kubernetes clusters	Sélectionnez cluster-2. Les paramètres VPC et vSwitch sont renseignés automatiquement.
   ASM root certificate	Cliquez sur Show Advanced Settings, sélectionnez Reuse an Existing Root Certificate of ASM Instance, puis sélectionnez mesh-1 dans la liste déroulante.

   Pour les autres paramètres non spécifiés dans le tableau, utilisez les mêmes valeurs que pour mesh-1. Une fois l'instance créée, attendez 2 à 3 minutes jusqu'à ce que le statut de l'instance mesh-2 passe à Running.

Étape 2 : Ajouter des clusters en mode découverte de services uniquement

Une fois l'étape 1 terminée, mesh-1 gère cluster-1 et mesh-2 gère cluster-2. Pour activer la découverte de services entre les clusters, vous devez ajouter l'autre cluster à chaque instance ASM en mode découverte de services uniquement. Cela permet à chaque instance de découvrir les services et les points de terminaison de l'autre cluster.

1. Ajoutez cluster-2 à l'instance mesh-1 en mode découverte de services uniquement.

   1. Connectez-vous à la console ASM. Dans le volet de navigation de gauche, accédez à Service Mesh > Mesh Management.

   2. Sur la page Mesh Management, cliquez sur le nom de l'instance mesh-1. Dans le volet de navigation de gauche, accédez à Cluster & Workload Management (Data Plane) > Kubernetes Clusters puis cliquez sur Add.

   3. Sur la page Add Kubernetes Cluster, localisez cluster-2, puis cliquez sur Add (For Service Discovery Only) dans la colonne Actions pour le cluster. Dans la boîte de dialogue qui s'affiche, cliquez sur OK. Une fois le cluster ajouté, sur la page Instance Information > Basic Information, le statut de l'instance ASM passe à Updating. Après quelques secondes (le temps requis dépend du nombre de clusters ajoutés), cliquez sur l'icône située dans le coin supérieur droit de la page ; le statut de l'instance ASM passe alors à Running. Sur la page Kubernetes Clusters, vous pouvez consulter les informations relatives au cluster ajouté.

2. Ajoutez cluster-1 à l'instance mesh-2 en mode découverte de services uniquement.

   1. Connectez-vous à la console ASM. Dans le volet de navigation de gauche, accédez à Service Mesh > Mesh Management.

   2. Sur la page Mesh Management, cliquez sur le nom de l'instance mesh-2. Dans le volet de navigation de gauche, accédez à Cluster & Workload Management (Data Plane) > Kubernetes Clusters puis cliquez sur Add.

   3. Sur la page Add Kubernetes Cluster, localisez cluster-1 et cliquez sur Add (For Service Discovery Only) dans la colonne Actions. Dans la boîte de dialogue de confirmation qui s'affiche, cliquez sur OK. Une fois le cluster ajouté, accédez à la page Instance Information > Basic Information. Le statut de l'instance ASM passe à Updating. Attendez quelques secondes, puis cliquez sur l'icône d'actualisation située dans le coin supérieur droit. Le statut de l'instance passe à Running. Vous pouvez consulter les informations relatives au cluster ajouté sur la page Kubernetes Clusters.

      Sur la page Kubernetes Clusters, le statut de cluster-1 est For Service Discovery Only, Synced et celui de cluster-2 est Running, Synced. Cela confirme que les deux clusters ont été ajoutés avec succès à l'instance ASM.

Étape 3 (Facultative) : Configurer la mise en réseau multi-cluster

Si les clusters Kubernetes cluster-1 et cluster-2 se trouvent dans des réseaux différents, par exemple sur des VPC ou des régions distincts, et que les réseaux ne sont pas connectés via Cloud Enterprise Network (CEN), vous devez configurer la mise en réseau multi-cluster dans les deux instances ASM. Vous devez également déployer un proxy de maillage inter-cluster pour cluster-1 et cluster-2 afin de garantir la connectivité entre les clusters. Pour plus d'informations sur le proxy de maillage inter-cluster, consultez Reprise après sinistre pour plusieurs clusters ACK dans différents VPC (en utilisant un proxy de maillage inter-cluster ASM).

1. Dans l'instance mesh-1, configurez les paramètres réseau pour cluster-1 et cluster-2.

   1. Connectez-vous à la console ASM. Dans le volet de navigation de gauche, accédez à Service Mesh > Mesh Management.

   2. Sur la page Mesh Management, cliquez sur le nom de l'instance mesh-1. Dans le volet de navigation de gauche, accédez à Cluster & Workload Management (Data Plane) > Kubernetes Clusters.

   3. Cliquez sur Multi-cluster Network Configurations et configurez les paramètres réseau comme suit :

      1. Pour cluster-1, définissez le réseau logique sur network1 et activez l'accès via le proxy de maillage inter-cluster.

      2. Pour cluster-2, définissez le réseau logique sur network2.

   Les services au sein d'un même réseau logique peuvent communiquer directement. Les services situés dans des réseaux logiques différents doivent communiquer via le proxy de maillage inter-cluster. Lorsque vous activez l'accès via le proxy de maillage inter-cluster, un service LoadBalancer est créé automatiquement, ce qui engendre des frais CLB.

2. Dans l'instance mesh-2, configurez les paramètres réseau pour cluster-1 et cluster-2.

   1. Connectez-vous à la console ASM. Dans le volet de navigation de gauche, accédez à Service Mesh > Mesh Management.

   2. Sur la page Mesh Management, cliquez sur le nom de l'instance mesh-2. Dans le volet de navigation de gauche, accédez à Cluster & Workload Management (Data Plane) > Kubernetes Clusters.

   3. Cliquez sur Multi-cluster Network Configurations et configurez les paramètres réseau comme suit :

      1. Pour cluster-1, définissez le réseau logique sur network1.

      2. Pour cluster-2, définissez le réseau logique sur network2 et activez l'accès via le proxy de maillage inter-cluster.

   Les services au sein d'un même réseau logique peuvent communiquer directement. Les services situés dans des réseaux logiques différents doivent communiquer via le proxy de maillage inter-cluster. Lorsque vous activez l'accès via le proxy de maillage inter-cluster, un service LoadBalancer est créé automatiquement, ce qui engendre des frais CLB.

Étape 4 : Déployer l'application exemple

Cette section explique comment déployer le service sleep et la version v1 du service helloworld dans cluster-1, ainsi que la version v2 du service helloworld dans cluster-2, comme illustré dans la figure suivante. Les services des deux clusters peuvent s'accéder mutuellement via le proxy de maillage inter-cluster.

1. Dans les instances mesh-1 et mesh-2, activez l'injection automatique de sidecar pour le namespace default. Pour plus d'informations, consultez Gérer les namespaces globaux.

2. Utilisez le manifeste YAML suivant pour créer l'application sleep et la version v1 de l'application helloworld.

   YAML

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: sleep
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: sleep
     labels:
       app: sleep
       service: sleep
   spec:
     ports:
     - port: 80
       name: http
     selector:
       app: sleep
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: sleep
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: sleep
     template:
       metadata:
         labels:
           app: sleep
       spec:
         terminationGracePeriodSeconds: 0
         serviceAccountName: sleep
         containers:
         - name: sleep
           image: registry.cn-hangzhou.aliyuncs.com/acs/curl:8.1.2
           command: ["/bin/sleep", "infinity"]
           imagePullPolicy: IfNotPresent
           volumeMounts:
           - mountPath: /etc/sleep/tls
             name: secret-volume
         volumes:
         - name: secret-volume
           secret:
             secretName: sleep-secret
             optional: true
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: helloworld
     labels:
       app: helloworld
   spec:
     ports:
     - port: 5000
       name: http
     selector:
       app: helloworld
   ---
   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: helloworld
     labels:
       account: helloworld
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: helloworld-v1
     labels: 
       apps: helloworld
       version: v1
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: helloworld
         version: v1
     template:
       metadata:
         labels:
           app: helloworld
           version: v1
       spec:
         serviceAccount: helloworld
         serviceAccountName: helloworld
         containers:
         - name: helloworld
           image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/examples-helloworld-v1:1.0
           imagePullPolicy: IfNotPresent 
           ports:
           - containerPort: 5000

3. Déployez ce manifeste dans cluster-1. Pour plus d'informations, consultez Créer un Deployment sans état.

4. Utilisez le manifeste YAML suivant pour créer la version v2 de l'application helloworld.

   YAML

   apiVersion: v1
   kind: Service
   metadata:
     name: helloworld
     labels:
       app: helloworld
   spec:
     ports:
     - port: 5000
       name: http
     selector:
       app: helloworld
   ---
   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: helloworld
     labels:
       account: helloworld
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: helloworld-v2
     labels: 
       apps: helloworld
       version: v2
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: helloworld
         version: v2
     template:
       metadata:
         labels:
           app: helloworld
           version: v2
       spec:
         serviceAccount: helloworld
         serviceAccountName: helloworld
         containers:
         - name: helloworld
           image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/examples-helloworld-v2:1.0
           imagePullPolicy: IfNotPresent 
           ports:
           - containerPort: 5000

5. Déployez ce manifeste dans cluster-2. Pour plus d'informations, consultez Créer un Deployment sans état.

Étape 5 : Vérifier la communication inter-cluster

1. Utilisez le fichier kubeconfig de cluster-1 pour exécuter la commande suivante :

    kubectl exec -it deploy/sleep -- sh -c 'for i in $(seq 1 10); do curl helloworld:5000/hello; done;'

   Résultat attendu :

   Hello version: v1, instance: helloworld-v1-7b888xxxxx-xxxxx
   Hello version: v1, instance: helloworld-v1-7b888xxxxx-xxxxx
   Hello version: v2, instance: helloworld-v2-7b949xxxxx-xxxxx
   Hello version: v2, instance: helloworld-v2-7b949xxxxx-xxxxx
   Hello version: v1, instance: helloworld-v1-7b888xxxxx-xxxxx
   Hello version: v2, instance: helloworld-v2-7b949xxxxx-xxxxx
   Hello version: v2, instance: helloworld-v2-7b949xxxxx-xxxxx
   Hello version: v2, instance: helloworld-v2-7b949xxxxx-xxxxx
   Hello version: v2, instance: helloworld-v2-7b949xxxxx-xxxxx
   Hello version: v1, instance: helloworld-v1-7b888xxxxx-xxxxx

   Le résultat montre que les requêtes sont équilibrées entre les versions v1 et v2 du service helloworld.

2. Exécutez la commande suivante pour ramener le nombre de réplicas de l'application sleep dans cluster-1 à 0 :

   kubectl scale deploy sleep --replicas=0

3. Utilisez le manifeste YAML suivant pour créer l'application sleep.

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: sleep
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: sleep
     labels:
       app: sleep
       service: sleep
   spec:
     ports:
     - port: 80
       name: http
     selector:
       app: sleep
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: sleep
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: sleep
     template:
       metadata:
         labels:
           app: sleep
       spec:
         terminationGracePeriodSeconds: 0
         serviceAccountName: sleep
         containers:
         - name: sleep
           image: registry.cn-hangzhou.aliyuncs.com/acs/curl:8.1.2
           command: ["/bin/sleep", "infinity"]
           imagePullPolicy: IfNotPresent

4. Déployez le manifeste précédent dans cluster-2. Pour plus d'informations, consultez Créer un Deployment sans état.

5. Sur cluster-2, exécutez à nouveau la commande suivante :

    kubectl exec -it deploy/sleep -- sh -c 'for i in $(seq 1 10); do curl helloworld:5000/hello; done;'

   Résultat attendu :

   Hello version: v1, instance: helloworld-v1-7b888xxxxx-xxxxx
   Hello version: v2, instance: helloworld-v2-7b949xxxxx-xxxxx
   Hello version: v2, instance: helloworld-v2-7b949xxxxx-xxxxx
   Hello version: v2, instance: helloworld-v2-7b949xxxxx-xxxxx
   Hello version: v2, instance: helloworld-v2-7b949xxxxx-xxxxx
   Hello version: v1, instance: helloworld-v1-7b888xxxxx-xxxxx
   Hello version: v2, instance: helloworld-v2-7b949xxxxx-xxxxx
   Hello version: v1, instance: helloworld-v1-7b888xxxxx-xxxxx
   Hello version: v2, instance: helloworld-v2-7b949xxxxx-xxxxx
   Hello version: v2, instance: helloworld-v2-7b949xxxxx-xxxxx

   Le résultat montre que les requêtes sont toujours équilibrées entre les versions v1 et v2 du service helloworld.