Use the ASM fallback mechanism - Alibaba Cloud Service Mesh - Centre de documentation Alibaba Cloud

Un mécanisme de secours définit une action alternative en cas d'échec d'un appel de service. Si un microservice tombe en panne ou devient indisponible, ce mécanisme sollicite un service de secours pour traiter les requêtes, garantissant ainsi la stabilité et la disponibilité du système. Par exemple, si un endpoint de service est indisponible, utilisez un mécanisme de secours pour rediriger les requêtes vers une version de secours du service. Cela permet de traiter les requêtes client sans erreur ni interruption. ASM prend en charge ce mécanisme via le paramètre fallback dans un VirtualService. Cette rubrique explique comment utiliser le mécanisme de secours dans ASM.

Prérequis

Vous disposez d'une instance ASM Enterprise Edition ou Ultimate Edition, version 1.17.2.22 ou ultérieure. Pour plus d'informations, consultez la page Créer une instance ASM.

Remarque
Si votre instance ASM est antérieure à la version 1.17, mettez-la à jour vers la version 1.17.2.22 ou ultérieure, ou soumettez un ticket pour obtenir une assistance technique. Pour savoir comment mettre à jour une instance, consultez la page Mettre à niveau une instance ASM.
Un cluster ACK est associé à l'instance ASM. Pour plus d'informations, consultez la page Ajouter un cluster à une instance ASM.
L'exemple Bookinfo est déployé. Pour plus d'informations, consultez la page Déployer une application dans un cluster associé à une instance ASM.
La version du sidecar sur le plan de données est 1.17 ou ultérieure.

Remarque
Consultez la version du sidecar de chaque pod métier sur la page Instances Status de la console ASM. Pour plus d'informations, consultez la page Gestion des mises à niveau.

Configuration

Cette rubrique utilise le service reviews de l'application exemple Bookinfo. Lorsque le service productpage accède aux versions v1, v2 et v3 du service reviews, si la version v3 est indisponible, le mécanisme de secours redirige les requêtes vers la version v2. Cela empêche le service de renvoyer une erreur 503.

Cliquez sur Fichier de configuration pour télécharger les fichiers YAML utilisés dans cette rubrique.

Étape 1 : Accéder à l'exemple Bookinfo

Créez un fichier nommé reviews.yaml avec le contenu suivant pour déclarer les versions v1, v2 et v3 du service reviews.

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
  - name: v3
    labels:
      version: v3

Dans votre environnement KubeConfig, exécutez la commande suivante pour déployer la DestinationRule.
```
kubectl apply -f reviews.yaml
```
Obtenez l'adresse IP de la passerelle d'entrée à l'aide de l'une des méthodes suivantes.
- Méthode 1 : Exécutez la commande suivante.
```
kubectl get svc -n istio-system  istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}'
```
- Méthode 2 : Obtenez l'adresse IP de la passerelle d'entrée depuis la page Ingress Gateway de la console ASM. Pour plus d'informations, consultez la page Obtenir l'endpoint d'une passerelle ASM.
Dans un navigateur, accédez à l'URL http://${YourGatewayIp}/productpage.

${YourGatewayIp} correspond à l'IP de la passerelle obtenue à l'étape précédente. Identifiez la version par la valeur de Reviews served by ou par les étoiles. La version v1 n'affiche aucune étoile, la version v2 affiche des étoiles noires et la version v3 affiche des étoiles rouges.

Par exemple, la valeur reviews-v2 indique la version v2, qui affiche des étoiles noires.

Actualisez la page plusieurs fois. Les requêtes sont désormais réparties entre les versions v1, v2 et v3 du service reviews.

Étape 2 : Définir une règle de routage et de secours

Créez un fichier nommé reviews-route-fallback-sample1.yaml avec le contenu suivant.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews-route
  namespace: default
spec:
  hosts:
    - reviews
  http:
    - route:
        - destination:
            host: reviews
            subset: v3
          fallback:
            target:
              host: reviews
              subset: v2

Dans votre environnement KubeConfig pour l'instance ASM, exécutez la commande suivante pour déployer la règle de routage et de secours pour le service reviews.
```
kubectl apply -f reviews-route-fallback-sample1.yaml
```
Dans un navigateur web, accédez à l'URL http://${YourGatewayIp}/productpage et actualisez régulièrement la page.

Les requêtes sont systématiquement acheminées vers la version v3 du service reviews. Après actualisation, la page indique que le service de critique de livres est fourni par reviews-v3, et la critique inclut des évaluations sous forme d'étoiles rouges.
Simulez une défaillance de la version reviews-v3 en réduisant le nombre de ses réplicas à 0 :
```
kubectl scale deployment reviews-v3 --replicas=0
```

Dans votre navigateur, accédez à l'URL http://${YourGatewayIp}/productpage et actualisez la page à plusieurs reprises.

Les requêtes basculent correctement vers la version v2 du service reviews. Vérifiez qu'un basculement a eu lieu en ajoutant des champs liés au secours au format personnalisé des journaux d'accès, puis en consultant ces journaux.

Vérifier le basculement

Ajoutez les champs suivants au format personnalisé des journaux d'accès. Pour plus d'informations, consultez la page Personnaliser le contenu des journaux d'accès du plan de données.

Champ	Valeur	Description
fallback_path	%DYNAMIC_METADATA(com.aliyun.fallback:fallback-path)%	Le chemin spécifique du basculement. Par exemple, `A:B` indique que les requêtes basculent de A vers B. `A:B:C` indique que les requêtes basculent de A vers B, puis de B vers C si B est également indisponible.
fallback_final_cluster_name	%DYNAMIC_METADATA(com.aliyun.fallback:final-cluster)%	En cas de basculement, il s'agit du cluster de destination. Par exemple, si `service1\|v1` n'existe pas, les requêtes basculent vers `service\|base`.
fallback_result	%DYNAMIC_METADATA(com.aliyun.fallback:fallback-result)%	Le résultat du basculement. Si le basculement échoue, l'échec de la requête est attribué au cluster de destination d'origine.

Consultez les journaux de istio-proxy pour productpage-v1.

Le journal suivant montre un basculement de reviews-v3 vers reviews-v2 :

{
    "authority":"reviews:9080",
    "authority_for":"reviews:9080",
    "bytes_received":"0",
    "bytes_sent":"442",
    "downstream_local_address":"192.168.255.46:9080",
    "downstream_remote_address":"172.16.0.252:57238",
    "duration":"10",
    "fallback_path":"outbound|9080|v3|reviews.default.svc.cluster.local:outbound|9080|v2|reviews.default.svc.cluster.local",
    "fallback_final_cluster_name":"outbound|9080|v2|reviews.default.svc.cluster.local",
    "fallback_result":"fallback successful",
    "istio_policy_status":"-",
    "method":"GET",
    "path":"/reviews/0",
    "protocol":"HTTP/1.1",
    "request_id":"15b2dffc-5f3f-4060-b9fa-898eab08****",
    "requested_server_name":"-",
    "response_code":"200",
    "response_flags":"-",
    "route_name":"-",
    "start_time":"2023-05-30T07:02:26.990Z",
    "trace_id":"18b3aed8af41****",
    "upstream_cluster":"outbound|9080|v2|reviews.default.svc.cluster.local",
    "upstream_host":"172.16.0.11:9080",
    "upstream_local_address":"172.16.0.252:44448",
    "upstream_service_time":"9",
    "upstream_transport_failure_reason":"-",
    "user_agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.X.X Safari/537.36",
    "x_forwarded_for":"-"
}

Vous pouvez trouver les nouveaux champs suivants dans le journal.

"fallback_path":"outbound|9080|v3|reviews.default.svc.cluster.local:outbound|9080|v2|reviews.default.svc.cluster.local"
"fallback_final_cluster_name":"outbound|9080|v2|reviews.default.svc.cluster.local"
"fallback_result":"fallback successful"

Le journal indique que la destination d'origine était v3. Comme l'instance v3 était indisponible, la requête a basculé vers v2.

Étape 3 : Configurer le secours avec un routage pondéré

Exécutez la commande suivante pour rendre à nouveau disponible la version reviews-v3.
```
kubectl scale deployment reviews-v3 --replicas=1
```

Créez un fichier nommé reviews-route-fallback-sample2.yaml avec le contenu suivant pour modifier la définition de reviews-route.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews-route
  namespace: default
spec:
  hosts:
    - reviews 
  http:
    - route:
        - destination:
            host: reviews 
            subset: v3
          fallback:
            target:
              host: reviews 
              subset: v2
          weight: 50
        - destination:
            host: reviews 
            subset: v2
          fallback:
            target:
              host: reviews 
              subset: v1
          weight: 50
      retries:
        attempts: 0

Exécutez la commande suivante pour déployer la nouvelle règle de routage et de secours pour le service reviews.
```
kubectl apply -f reviews-route-fallback-sample2.yaml
```
Dans votre navigateur, accédez à l'URL http://${YourGatewayIp}/productpage et actualisez la page à plusieurs reprises.

Les requêtes sont acheminées vers les versions v2 et v3 du service reviews selon un ratio de 50:50. Dans cet exemple, les nouvelles tentatives sont désactivées pour rendre le résultat plus clair.
Exécutez la commande suivante pour réduire le nombre de réplicas de v3 à 0 et vérifier que sa règle de secours fonctionne comme prévu.
```
kubectl scale deployment reviews-v3 --replicas=0
```
Actualisez la page productpage plusieurs fois. Les requêtes sont systématiquement acheminées vers la version v2, ce qui correspond au comportement attendu.
Exécutez la commande suivante pour réduire le nombre de réplicas de v2 à 0.
```
kubectl scale deployment reviews-v2 --replicas=0
```
Si vous actualisez la page productpage à plusieurs reprises, vous constatez qu'environ 50 % des tentatives d'accès au service reviews échouent. Les 50 % restants des requêtes sont envoyés à la version v2. Comme la version v2 est indisponible, ces requêtes basculent vers la version v1. Après avoir exécuté la commande et accédé à la page produit de l'application BookInfo, la section des critiques affiche le titre d'erreur rouge Error fetching product reviews! et le message Sorry, product reviews are currently unavailable for this book.. Cela indique que le service de critiques de produits devient indisponible après la réduction du nombre de réplicas de reviews-v2 à 0.

Exécutez la commande suivante pour afficher les journaux.

kubectl logs -f  deployment/productpage-v1  -c istio-proxy --tail=10

Sortie attendue :

{
    "authority":"reviews:9080",
    "authority_for":"reviews:9080",
    "bytes_received":"0",
    "bytes_sent":"19",
    "downstream_local_address":"192.168.255.46:9080",
    "downstream_remote_address":"172.16.0.252:47738",
    "duration":"0",
    "fallback_path":"outbound|9080|v3|reviews.default.svc.cluster.local:outbound|9080|v2|reviews.default.svc.cluster.local",
    "fallback_final_cluster_name":"-",
    "fallback_result":"fallback cluster is unhealthy",
    "istio_policy_status":"-",
    "method":"GET",
    "path":"/reviews/0",
    "protocol":"HTTP/1.1",
    "request_id":"b207a764-b6d7-4ef8-bc71-59f264c3****",
    "requested_server_name":"-",
    "response_code":"503",
    "response_flags":"UH",
    "route_name":"-",
    "start_time":"2023-05-30T07:32:08.999Z",
    "trace_id":"a40c32a7b2cf****",
    "upstream_cluster":"outbound|9080|v3|reviews.default.svc.cluster.local",
    "upstream_host":"-",
    "upstream_local_address":"-",
    "upstream_service_time":"-",
    "upstream_transport_failure_reason":"-",
    "user_agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.X.X Safari/537.36",
    "x_forwarded_for":"-"
}

Des journaux 503 apparaissent pour productpage-v1. Selon la configuration de routage pondéré de reviews-route, 50 % des requêtes provenant de productpage sont acheminées vers la version v3 du service reviews. Comme la version v3 est indisponible, le sidecar (istio-proxy) tente de basculer de v3 vers la version v2 en fonction d'une règle de secours. Comme la version v2 est également indisponible, la requête est envoyée à la version v3. Confirmez-le en vérifiant le champ "upstream_cluster":"outbound|9080|v3|reviews.default.svc.cluster.local".