Alibaba Cloud Service Mesh:Using a service mesh for availability zone disaster recovery

Haute disponibilité des composants managés

Tous les composants managés des clusters ACK et des instances ASM sont déployés avec plusieurs réplicas répartis uniformément sur plusieurs zones de disponibilité. Cette architecture garantit que le plan de contrôle du cluster et du maillage de services reste opérationnel même en cas de panne d'une seule zone de disponibilité. De la même manière, les nœuds de calcul et les instances de conteneur élastiques au sein du cluster sont également distribués sur différentes zones de disponibilité. En cas de défaillance au niveau d'une zone de disponibilité, telle qu'une coupure d'alimentation ou une interruption réseau, les zones de disponibilité saines continuent de fonctionner normalement.

Configurations haute disponibilité et maillage de services pour les pannes de zones de disponibilité

Pour faire face aux pannes au niveau des zones de disponibilité, la première étape consiste à déployer vos charges de travail applicatives de manière équilibrée entre les différentes zones de disponibilité.

ACK prend en charge les pools de nœuds multi-zones de disponibilité (AZ). Lors de la création et de la gestion d'un pool de nœuds, il est recommandé de sélectionner des vSwitches situés dans différentes zones de disponibilité et de choisir une politique de distribution équilibrée lors de la configuration d'une politique de mise à l'échelle automatique. Cela permet aux instances ECS d'être réparties uniformément sur les multiples zones de disponibilité spécifiées pour le groupe de mise à l'échelle. Par ailleurs, vous pouvez combiner des fonctionnalités telles que la mise à l'échelle automatique des nœuds, les ensembles de déploiement et la distribution multi-AZ avec les contraintes de topologie Kubernetes pour déployer les charges de travail de façon homogène entre les différentes zones de disponibilité. Pour plus de détails, consultez la rubrique Configurations recommandées pour une architecture de cluster hautement disponible.

Une fois votre application déployée sur plusieurs zones de disponibilité, surveillez en temps réel l'état de santé de vos applications Kubernetes et de votre cluster afin de détecter rapidement les pannes de zones de disponibilité et intervenir pour rétablir les services.

• La technologie de maillage de services améliore l'observabilité réseau de votre système. Les proxies du plan de données du maillage de services exposent des métriques clés liées aux requêtes réseau et aux interactions entre les services applicatifs. Ces métriques, qui incluent des données spécifiques à chaque zone de disponibilité, permettent de signaler divers problèmes et d'aider à détecter les pannes de zones de disponibilité.

• En cas de panne au niveau d'une zone de disponibilité, ASM assure la reprise après sinistre en combinant ses capacités de basculement de trafic avec celles de votre équilibreur de charge. Lorsqu'une zone de disponibilité devient indisponible, répondez aux alertes en configurant le basculement de trafic afin de rediriger temporairement le trafic réseau intra-cluster hors de la zone affectée. Lorsque la zone de disponibilité est de nouveau opérationnelle, reprenez l'envoi du trafic vers celle-ci.

Étape 1 : Préparation de l'environnement

1. Créez un cluster managé ACK. Lors de la création du cluster, sélectionnez des vSwitches dans deux zones de disponibilité pour activer la prise en charge multi-AZ. Vous pouvez conserver les valeurs par défaut pour les autres paramètres. Le pool de nœuds utilise par défaut la politique de mise à l'échelle avec distribution équilibrée. Pour plus d'informations, consultez la rubrique Création d'un cluster managé ACK.

2. Créez une instance ASM avec la même configuration de zones de disponibilité que le cluster ACK. Pour plus d'informations, consultez la rubrique Création d'une instance ASM.

3. Déployez la passerelle et une application exemple.

   1. Dans l'instance ASM, créez une passerelle ASM et associez-la à un Network Load Balancer (NLB). Sélectionnez les mêmes deux zones de disponibilité pour le NLB que pour l'instance ASM et le cluster ACK (dans cet exemple, cn-hangzhou-k et cn-hangzhou-h). Pour plus d'informations, consultez la rubrique Utilisation d'une instance NLB au niveau d'une passerelle d'entrée ASM.

      Remarque

      Cet exemple utilise une passerelle ASM associée à un NLB comme point d'entrée du trafic. Vous pouvez également utiliser un Application Load Balancer (ALB) comme point d'entrée pour votre application. Les ALB offrent également des capacités de reprise après sinistre multi-zones de disponibilité et de suppression d'enregistrements DNS.

   2. Désactivez la fonctionnalité de transfert inter-zones pour le NLB. Cela garantit que le NLB dans chaque zone de disponibilité ne transfère le trafic qu'aux backends situés dans la même zone de disponibilité.

   3. Activez l'injection automatique de sidecar pour le namespace default. Pour plus d'informations, consultez la rubrique Gestion du namespace global.

   4. Déployez l'application exemple.

      Code

      kubectl apply -f- <<EOF
      apiVersion: v1
      kind: Service
      metadata:
        name: mocka
        labels:
          app: mocka
          service: mocka
      spec:
        ports:
        - port: 8000
          name: http
        selector:
          app: mocka
      ---
      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: mocka-cn-hangzhou-h
        labels:
          app: mocka
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: mocka
        template:
          metadata:
            labels:
              app: mocka
              locality: cn-hangzhou-h
          spec:
            nodeSelector:      
              topology.kubernetes.io/zone: cn-hangzhou-h  
            containers:
            - name: default
              image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing
              imagePullPolicy: IfNotPresent
              env:
              - name: version
                value: cn-hangzhou-h 
              - name: app
                value: mocka
              - name: upstream_url
                value: "http://mockb:8000/"
              ports:
              - containerPort: 8000
      ---
      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: mocka-cn-hangzhou-k
        labels:
          app: mocka
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: mocka
        template:
          metadata:
            labels:
              app: mocka
              locality: cn-hangzhou-k
          spec:
            nodeSelector:      
              topology.kubernetes.io/zone: cn-hangzhou-k
            containers:
            - name: default
              image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing
              imagePullPolicy: IfNotPresent
              env:
              - name: version
                value: cn-hangzhou-k
              - name: app
                value: mocka
              - name: upstream_url
                value: "http://mockb:8000/"
              ports:
              - containerPort: 8000
      ---
      apiVersion: v1
      kind: Service
      metadata:
        name: mockb
        labels:
          app: mockb
          service: mockb
      spec:
        ports:
        - port: 8000
          name: http
        selector:
          app: mockb
      ---
      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: mockb-cn-hangzhou-h
        labels:
          app: mockb
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: mockb
        template:
          metadata:
            labels:
              app: mockb
              locality: cn-hangzhou-h
          spec:
            nodeSelector:      
              topology.kubernetes.io/zone: cn-hangzhou-h
            containers:
            - name: default
              image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing
              imagePullPolicy: IfNotPresent
              env:
              - name: version
                value: cn-hangzhou-h
              - name: app
                value: mockb
              - name: upstream_url
                value: "http://mockc:8000/"
              ports:
              - containerPort: 8000
      ---
      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: mockb-cn-hangzhou-k
        labels:
          app: mockb
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: mockb
        template:
          metadata:
            labels:
              app: mockb
              locality: cn-hangzhou-k
          spec:
            nodeSelector:      
              topology.kubernetes.io/zone: cn-hangzhou-k
            containers:
            - name: default
              image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing
              imagePullPolicy: IfNotPresent
              env:
              - name: version
                value: cn-hangzhou-k
              - name: app
                value: mockb
              - name: upstream_url
                value: "http://mockc:8000/"
              ports:
              - containerPort: 8000
      ---
      apiVersion: v1
      kind: Service
      metadata:
        name: mockc
        labels:
          app: mockc
          service: mockc
      spec:
        ports:
        - port: 8000
          name: http
        selector:
          app: mockc
      ---
      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: mockc-cn-hangzhou-h
        labels:
          app: mockc
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: mockc
        template:
          metadata:
            labels:
              app: mockc
              locality: cn-hangzhou-h
          spec:
            nodeSelector:      
              topology.kubernetes.io/zone: cn-hangzhou-h
            containers:
            - name: default
              image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing
              imagePullPolicy: IfNotPresent
              env:
              - name: version
                value: cn-hangzhou-h
              - name: app
                value: mockc
              ports:
              - containerPort: 8000
      ---
      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: mockc-cn-hangzhou-k
        labels:
          app: mockc
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: mockc
        template:
          metadata:
            labels:
              app: mockc
              locality: cn-hangzhou-k
          spec:
            nodeSelector:      
              topology.kubernetes.io/zone: cn-hangzhou-k
            containers:
            - name: default
              image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing
              imagePullPolicy: IfNotPresent
              env:
              - name: version
                value: cn-hangzhou-k
              - name: app
                value: mockc
              ports:
              - containerPort: 8000
      ---
      apiVersion: networking.istio.io/v1beta1
      kind: Gateway
      metadata:
        name: mocka
        namespace: default
      spec:
        selector:
          istio: ingressgateway
        servers:
          - hosts:
              - '*'
            port:
              name: test
              number: 80
              protocol: HTTP
      ---
      apiVersion: networking.istio.io/v1beta1
      kind: VirtualService
      metadata:
        name: demoapp-vs
        namespace: default
      spec:
        gateways:
          - mocka
        hosts:
          - '*'
        http:
          - name: test
            route:
              - destination:
                  host: mocka
                  port:
                    number: 8000
      EOF

      La commande précédente déploie une application constituée des services mocka, mockb et mockc. Chaque service comprend deux déploiements sans état, chacun avec un seul réplica. Les déploiements sont distribués sur des nœuds situés dans différentes zones de disponibilité en utilisant différents champs nodeSelector et sont configurés avec des variables d'environnement pour renvoyer la zone de disponibilité où ils se trouvent.

      Remarque

      Pour offrir une démonstration claire, cet exemple utilise le champ nodeSelector d'un pod pour sélectionner manuellement la zone de disponibilité du pod. Dans un environnement de production haute disponibilité, vous devez configurer des contraintes de répartition de la topologie pour garantir que les pods sont distribués autant que possible sur différentes zones de disponibilité. Pour plus d'informations, consultez la rubrique Configuration de la haute disponibilité des charges de travail.

Étape 2 : Surveillance des métriques de service

Lorsqu'une panne survient, les journaux des charges de travail, les métriques et les alertes vous aident à détecter rapidement l'incident, à en déterminer l'étendue et à comprendre son impact ou sa cause racine.

1. Ajoutez une dimension de zone de disponibilité aux métriques de requête.

   Le proxy du maillage peut détecter automatiquement la zone de disponibilité où une charge de travail est déployée et stocker cette information dans les métadonnées du proxy. Modifiez les dimensions des métriques pour ajouter la dimension locality aux métriques du maillage de services et définissez sa valeur sur xds.node.locality.zone, qui représente la zone de disponibilité de la charge de travail. Pour plus d'informations, consultez la rubrique Configurations d'observabilité.

2. Envoyez des requêtes à l'application exemple pour générer des métriques de requête.

   watch -n 0.1 curl nlb-xxxxxxxxxxxxx.cn-xxxxxxx.nlb.aliyuncsslb.com/mock -v

   Sortie attendue :

   > GET /mock HTTP/1.1
   > Host: nlb-85h289ly4hz9qhaz58.cn-hangzhou.nlb.aliyuncsslb.com
   > User-Agent: curl/8.7.1
   > Accept: */*
   > 
   * Request completely sent off
   < HTTP/1.1 200 OK
   < date: Sun, 08 Dec 2024 11:53:26 GMT
   < content-length: 150
   < content-type: text/plain; charset=utf-8
   < x-envoy-upstream-service-time: 5
   < server: istio-envoy
   < 
   * Connection #0 to host nlb-85h289ly4hz9qhaz58.cn-hangzhou.nlb.aliyuncsslb.com left intact
   -> mocka(version: cn-hangzhou-h, ip: 192.168.122.66)-> mockb(version: cn-hangzhou-k, ip: 192.168.0.47)-> mockc(version: cn-hangzhou-h, ip: 192.168.122.44)%

   La sortie montre que les requêtes sont routées aléatoirement vers les deux zones de disponibilité différentes, ce qui indique que les charges de travail dans les deux zones sont disponibles.

3. Après avoir envoyé des requêtes pendant un certain temps, explorez les métriques dans Managed Service for Prometheus. Pour plus d'informations, consultez la rubrique Explorateur de métriques.

   1. Consultez les informations sur les codes d'état des requêtes pour les charges de travail dans différentes zones de disponibilité.

      Pour vérifier le taux de requêtes pour les charges de travail dans une zone de disponibilité spécifique (groupées par nom de service et code de réponse), utilisez la requête PromQL suivante dans votre instance Prometheus :

      sum by(app, response_code) (rate(istio_requests_total{locality="cn-hangzhou-h", reporter="destination"}[$__rate_interval]))

      Résultat attendu :

      

      Avec un déploiement équilibré, les taux de requêtes reçus par les deux zones de disponibilité sont presque identiques. Vous pouvez modifier la condition de filtre en locality="cn-hangzhou-k" pour afficher le taux de requêtes et les informations sur les codes d'état pour la zone de disponibilité cn-hangzhou-k.

   2. Consultez les informations sur la latence des requêtes pour les charges de travail dans différentes zones de disponibilité.

      Pour vérifier la latence moyenne des requêtes pour les charges de travail dans une zone de disponibilité spécifique (groupées par nom de service et code de réponse), utilisez la requête PromQL suivante dans votre instance Prometheus :

      sum by(app, response_code) (rate(istio_request_duration_milliseconds_sum{locality="cn-hangzhou-h", reporter="destination"}[$__rate_interval]))

      Vous pouvez modifier la condition de filtre en locality="cn-hangzhou-k" pour afficher les informations de latence moyenne pour la zone de disponibilité cn-hangzhou-k.

4. Configurez des règles d'alerte basées sur les métriques.

   Vous pouvez configurer des alertes en utilisant des requêtes PromQL personnalisées. Lorsque la latence du service ou le taux de codes d'état non-200 dépasse un seuil, Prometheus envoie une alerte au contact spécifié. Pour plus d'informations, consultez la rubrique Création d'une règle d'alerte Prometheus.

   1. Créez une règle d'alerte basée sur la latence de l'application.

      Utilisez la requête PromQL suivante pour créer une alerte pour le service mockb.

      sum by(response_code, locality) (rate(istio_request_duration_milliseconds_sum{app="mockb",reporter= "destination"}[1m])) > 3

      La requête ci-dessus déclenche une alerte si la latence moyenne du service mockb sur un intervalle d'une minute dépasse 3 ms. Les alertes sont groupées par code d'état et zone de disponibilité.

   2. Créez une règle d'alerte basée sur le code d'état de la réponse du service.

      Utilisez la requête PromQL suivante pour créer une alerte pour le service mocka.

      sum by (locality, response_code) (rate(istio_requests_total{app="mocka",reporter="destination",response_code!="200"}[1m])) >= 0

   Vous pouvez créer des règles d'alerte pour d'autres applications en modifiant le paramètre app="mockb" dans les règles d'alerte précédentes.

Étape 3 : Exécution d'un exercice de reprise après sinistre

Après avoir reçu une alerte indiquant qu'une zone de disponibilité de votre cluster ACK est défectueuse ou dégradée, isolez les charges de travail de service déployées dans cette zone des autres zones. Cela vous permet d'investiguer la cause de la panne tout en maintenant votre activité en cours de fonctionnement. Une fois la panne résolue, rétablissez le trafic vers la zone de disponibilité.

1. Isolez les nœuds dans la zone de disponibilité affectée.

   Appliquez un « taint » aux nœuds pour empêcher la planification de nouveaux pods sur ceux-ci. Après avoir appliqué le taint, les nœuds deviennent non planifiables. Les pods existants restent sur les nœuds, mais aucun nouveau pod n'est planifié dans cette zone de disponibilité. Pour plus d'informations, consultez la rubrique Définition du statut de planification d'un nœud. L'exemple suivant montre comment isoler la zone de disponibilité cn-hangzhou-h en marquant tous les nœuds qu'elle contient comme non planifiables.

2. Basculez le trafic nord-sud (ingress).

   Étant donné que le NLB est configuré pour le transfert intra-zone, vous devez utiliser la fonctionnalité de suppression d'enregistrement DNS du NLB (ou de l'ALB) pour basculer rapidement le trafic nord-sud au niveau de la couche d'entrée lorsqu'une panne survient. Cela empêche le trafic externe de continuer à circuler vers la zone de disponibilité défaillante.

   1. Connectez-vous à la console NLB et cliquez sur l'instance NLB associée à la passerelle ASM.

   2. Sur la page des détails de l'instance NLB, sous l'onglet Zone, recherchez la zone de disponibilité affectée. Dans la colonne Actions, cliquez sur Remove DNS, puis cliquez sur OK dans la boîte de dialogue qui s'affiche. Après la suppression de l'enregistrement DNS, l'adresse IP publique du NLB dans la zone de disponibilité affectée n'est plus incluse dans les enregistrements de résolution DNS.

3. Basculez le trafic est-ouest.

   Utilisez la fonctionnalité de basculement de trafic par zone de disponibilité d'Alibaba Cloud Service Mesh (ASM) pour rediriger rapidement le trafic est-ouest au sein du cluster, empêchant ainsi qu'il n'atteigne les endpoints dans une zone de disponibilité spécifique.

   1. Connectez-vous à la console Service Mesh et cliquez sur l'instance ASM qui gère le cluster.

   2. Sur la page des détails du maillage, cliquez sur Service Discovery Selectors. Cliquez sur Show Advanced Settings, saisissez les informations sur la région et la zone de disponibilité où se trouvent les pods, puis cliquez sur OK.

   Après cette opération, l'instance passe brièvement dans un état de mise à jour. Lorsque la mise à jour est terminée, les endpoints de la zone de disponibilité spécifiée sont exclus de la portée de la découverte de services.

4. Observez l'effet de l'isolation.

   Continuez à accéder à l'application exemple. Vous constaterez que toutes les réponses proviennent des services de la zone de disponibilité cn-hangzhou-k. Cela indique que le trafic a été complètement basculé hors de la zone de disponibilité cn-hangzhou-h. Sortie attendue :

   > Host: nlb-xxxxxxxxxxxxxxxxxxx8.cn-hangzhou.nlb.aliyuncsslb.com
   > User-Agent: curl/8.7.1q
   > Accept: */*
   > A
   * Request completely sent off
   < HTTP/1.1 200 OKe
   < date: Tue, 10 Dec 2024 04:03:26 GMT
   < content-length: 1500
   < content-type: text/plain; charset=utf-8
   < x-envoy-upstream-service-time: 30
   < server: istio-envoyr
   < s
   { [150 bytes data]
   {100   150  100   150    0     0   2262      0 --:--:-- --:--:-- --:--:--  2238
   * Connection #0 to host nlb-xxxxxxxxxxxxxxxxxxx8.cn-hangzhou.nlb.aliyuncsslb.com left intact
   -> mocka(version: cn-hangzhou-k, ip: 192.168.0.44)-> mockb(version: cn-hangzhou-k, ip: 192.168.0.47)-> mockc(version: cn-hangzhou-k, ip: 192.168.0.46)