Retour aux microservices avec Istio. Partie 2

Note de traduction.: Première partie Ce cycle a été consacré à la découverte des capacités d'Istio et à leur démonstration en pratique. Maintenant, nous allons aborder des aspects plus complexes de la configuration et de l'utilisation de ce service mesh, notamment la routage finement configurable et la gestion du trafic réseau.

Nous rappelons également que l'article utilise des configurations (manifests pour Kubernetes et Istio) provenant du dépôt istio-mastery.

Gestion du trafic

Avec Istio, de nouvelles possibilités apparaissent dans le cluster, permettant d'assurer :

• Une routage dynamique des requêtes: déploiements canary, tests A/B ;
• Un équilibrage de charge: simple et cohérent, basé sur des hashes ;
• Une reprise après échec: timeouts, réessais, disjoncteurs ;
• L'injection de fautes: latences, interruptions de requêtes, etc.

Dans la suite de l'article, ces capacités seront illustrées par l'exemple d'une application choisie et de nouveaux concepts seront présentés en parallèle. Le premier de ces concepts sera DestinationRules (c'est-à-dire des règles concernant le destinataire du trafic/requêtes — note du traducteur), à l'aide desquelles nous activons les tests A/B.

Tests A/B :  DestinationRules en pratique

Les tests A/B sont appliqués lorsque deux versions d'une application existent (elles diffèrent généralement visuellement) et que nous ne sommes pas totalement sûrs de celle qui améliorera l'interaction avec l'utilisateur. Nous lançons donc simultanément les deux versions et collectons des métriques.

Pour déployer la seconde version du frontend, nécessaire à la démonstration des tests A/B, exécutez la commande suivante :

$ kubectl apply -f resource-manifests/kube/ab-testing/sa-frontend-green-deployment.yaml
deployment.extensions/sa-frontend-green créé

Le manifest du déploiement pour la « version verte » diffère à deux endroits :

1. L'image est basée sur un autre tag — istio-green,
2. Les Pods ont un label version : green.

Comme les deux déploiements ont le label app : sa-frontend, les requêtes, routées par le service virtuel sa-external-services vers le service sa-frontend, seront redirigées vers tous ses instances et la charge sera répartie selon l'algorithme round-robin, ce qui aboutira à la situation suivante :

Les fichiers demandés sont introuvables

Ces fichiers n'ont pas été trouvés car ils sont nommés différemment dans les différentes versions de l'application. Vérifions cela :

$ curl --silent http://$EXTERNAL_IP/ | tr '"' 'n' | grep main
/static/css/main.c7071b22.css
/static/js/main.059f8e9c.js
$ curl --silent http://$EXTERNAL_IP/ | tr '"' 'n' | grep main
/static/css/main.f87cd8c9.css
/static/js/main.f7659dbb.js

Cela signifie que index.html, demandant une version des fichiers statiques, peut être envoyé par le répartiteur de charge vers des pods ayant une autre version, où, pour des raisons évidentes, ces fichiers n'existent pas. Par conséquent, pour que l'application fonctionne, nous devons mettre en place une restriction : «la même version de l'application qui a renvoyé index.html doit servir également les requêtes suivantes».

Nous atteindrons notre objectif grâce à une répartition de charge cohérente basée sur des hachages (Répartition de charge par hachage cohérent). Dans ce cas les requêtes d'un même client sont envoyées au même instance de backend, pour cela, une propriété prédéfinie est utilisée — par exemple, un en-tête HTTP. Cela s'implémente avec DestinationRules.

DestinationRules

Après que VirtualService a dirigé la requête vers le service approprié, à l'aide de DestinationRules nous pouvons définir des politiques qui seront appliquées au trafic destiné aux instances de ce service :

Gestion du trafic avec les ressources Istio

Remarque: L'impact des ressources Istio sur le trafic réseau est présenté ici de manière simplifiée. Pour être précis, la décision sur quelle instance envoyer la requête est prise par Envoy dans le Ingress Gateway, configuré dans le CRD.

Avec les Destination Rules, nous pouvons configurer la répartition de charge pour utiliser des hachages cohérents et garantir que les réponses de la même instance de service vont à un même utilisateur. La configuration suivante permet d'atteindre cet objectif (destinationrule-sa-frontend.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: sa-frontend
spec:
  host: sa-frontend
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpHeaderName: version   # 1

1 — le hachage sera généré sur la base du contenu de l'en-tête HTTP version.

Appliquez la configuration avec la commande suivante :

$ kubectl apply -f resource-manifests/istio/ab-testing/destinationrule-sa-frontend.yaml
destinationrule.networking.istio.io/sa-frontend créé

Maintenant, exécutez la commande ci-dessous et assurez-vous que vous obtenez les fichiers souhaités lorsque vous spécifiez l'en-tête version:

$ curl --silent -H "version: yogo" http://$EXTERNAL_IP/ | tr '"' 'n' | grep main

Remarque: Pour ajouter différentes valeurs dans l'en-tête et tester les résultats directement dans le navigateur, vous pouvez utiliser cette extension pour Chrome ou celle-ci pour Firefox — note du traducteur.).

En général, les DestinationRules possèdent plus de fonctionnalités en matière de répartition de charge — pour plus de détails, veuillez vous renseigner dans la documentation officielle.

Avant de continuer à étudier VirtualService, supprimons la « version verte » de l'application et la règle associée de redirection du trafic en exécutant les commandes suivantes :

$ kubectl delete -f resource-manifests/kube/ab-testing/sa-frontend-green-deployment.yaml
deployment.extensions “sa-frontend-green” supprimé
$ kubectl delete -f resource-manifests/istio/ab-testing/destinationrule-sa-frontend.yaml
destinationrule.networking.istio.io “sa-frontend” supprimé

Miroir : les Virtual Services en pratique

Shadowing (« masquage ») ou Mirroring (« miroir ») est utilisé dans les cas où nous voulons tester un changement en production sans toucher les utilisateurs finaux : pour cela, nous dupliquons (« miroir ») les requêtes vers une seconde instance, où les modifications nécessaires ont été apportées, et observons les conséquences. En d'autres termes, c'est quand votre collègue choisit le problème le plus critique et fait une demande de tirage sous la forme d'un énorme tas de boue, que personne ne peut réellement réviser.

Pour vérifier ce scénario en action, créons une seconde instance de SA-Logic avec des bogues (buggy), en exécutant la commande suivante :

$ kubectl apply -f resource-manifests/kube/shadowing/sa-logic-service-buggy.yaml
deployment.extensions/sa-logic-buggy créé

Et maintenant, exécutons la commande pour nous assurer que toutes les instances avec app=sa-logic ont également des étiquettes avec les versions correspondantes :

$ kubectl get pods -l app=sa-logic --show-labels
NOM                              PRÊT   ÉTIQUETTES
sa-logic-568498cb4d-2sjwj         2/2     app=sa-logic,version=v1
sa-logic-568498cb4d-p4f8c         2/2     app=sa-logic,version=v1
sa-logic-buggy-76dff55847-2fl66   2/2     app=sa-logic,version=v2
sa-logic-buggy-76dff55847-kx8zz   2/2     app=sa-logic,version=v2

Service sa-logic vise les pods avec l'étiquette app=sa-logic, donc toutes les requêtes seront réparties entre toutes les instances :

… mais nous voulons que les requêtes soient dirigées vers les instances avec la version v1 et soient reflétées sur les instances avec la version v2 :

Nous y parviendrons grâce à VirtualService en combinaison avec DestinationRule, où les règles détermineront les sous-ensembles et les itinéraires de VirtualService vers un sous-ensemble spécifique.

Définition des sous-ensembles dans les règles de destination

Sous-ensembles (sous-ensembles) sont définis par la configuration suivante (sa-logic-subsets-destinationrule.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: sa-logic
spec:
  host: sa-logic    # 1
  subsets:
  - name: v1        # 2
    labels:
      version: v1   # 3
  - name: v2
    labels:
      version: v2

1. L'hôte (host) définit que cette règle s'applique uniquement aux cas où le chemin mène au service sa-logic;
2. Les noms (nom) des sous-ensembles sont utilisés lors de la navigation vers les instances du sous-ensemble ;
3. L'étiquette (label) définit les paires clé-valeur auxquelles les instances doivent correspondre pour faire partie d'un sous-ensemble.

Appliquez la configuration avec la commande suivante :

$ kubectl apply -f resource-manifests/istio/shadowing/sa-logic-subsets-destinationrule.yaml
destinationrule.networking.istio.io/sa-logic créé

Maintenant que les sous-ensembles sont définis, nous pouvons passer à la configuration de VirtualService pour appliquer des règles aux demandes à sa-logic, afin qu'elles :

1. soient routées vers le sous-ensemble v1,
2. soient mises en miroir vers le sous-ensemble v2.

Le manifeste suivant permet d'atteindre l'objectif (sa-logic-subsets-shadowing-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic          
  http:
  - route:
    - destination:
        host: sa-logic  
        subset: v1      
    mirror:             
      host: sa-logic     
      subset: v2

Les explications ne sont pas nécessaires ici, alors regardons juste en action :

$ kubectl apply -f resource-manifests/istio/shadowing/sa-logic-subsets-shadowing-vs.yaml
virtualservice.networking.istio.io/sa-logic créé

Ajoutons de la charge en appelant cette commande :

$ while true; do curl -v http://$EXTERNAL_IP/sentiment 
    -H "Content-type: application/json" 
    -d '{"sentence": "J'adore yogobella"}'; 
    sleep .8; done

Regardons les résultats dans Grafana, où nous pouvons voir que la version avec des bogues (buggy) entraîne un échec pour ~60 % des demandes, mais aucun de ces échecs n'affecte les utilisateurs finaux, car ils reçoivent des réponses du service fonctionnel.

Taux de succès des réponses des différentes versions du service sa-logic

Ici, nous avons vu pour la première fois comment VirtualService s'applique aux Envoys de nos services : lorsque sa-web-app fait une demande à sa-logic, elle passe par le sidecar Envoy, qui — via VirtualService — est configuré pour router la demande vers le sous-ensemble v1 et pour mettre en miroir la demande vers le sous-ensemble v2 du service sa-logic.

Je sais : vous avez déjà pensé que les Virtual Services sont simples. Dans la prochaine section, nous élargirons cet avis en montrant qu'ils sont en fait vraiment formidables.

Déploiements canari

Le déploiement Canary est le processus de déploiement d'une nouvelle version d'une application pour un petit nombre d'utilisateurs. Il est utilisé pour s'assurer qu'il n'y a pas de problèmes dans la version, et seulement après cela, déjà sûr de la qualité suffisante de celle-ci (de la version), la diffuser à undeplus grand public.

Pour illustrer les déploiements canaris, nous continuerons à travailler avec le sous-ensemble buggy au sa-logic.

Nous n'allons pas y aller doucement et diriger immédiatement 20 % des utilisateurs vers la version avec des bogues (qui représentera notre déploiement canari), tandis que les 80 % restants iront vers le service normal. Pour cela, nous appliquerons le VirtualService suivant (sa-logic-subsets-canary-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic    
  http:
  - route: 
    - destination: 
        host: sa-logic
        subset: v1
      weight: 80         # 1
    - destination: 
        host: sa-logic
        subset: v2
      weight: 20 # 1

1 — c'est le poids (poids), qui détermine le pourcentage de requêtes qui seront dirigées vers le destinataire ou le sous-ensemble du destinataire.

Nous allons mettre à jour la configuration du VirtualService précédent avec sa-logic la commande suivante :

$ kubectl apply -f resource-manifests/istio/canary/sa-logic-subsets-canary-vs.yaml
virtualservice.networking.istio.io/sa-logic configuré

… et nous verrons immédiatement que certaines requêtes échouent :

$ while true; do 
   curl -i http://$EXTERNAL_IP/sentiment 
   -H "Content-type: application/json" 
   -d '{"sentence": "I love yogobella"}' 
   --silent -w "Time: %{time_total}s t Status: %{http_code}n" 
   -o /dev/null; sleep .1; done
Time: 0.153075s Status: 200
Time: 0.137581s Status: 200
Time: 0.139345s Status: 200
Time: 30.291806s Status: 500

Les VirtualServices activent les déploiements canary : dans ce cas, nous avons réduit les conséquences potentielles des problèmes à 20 % de la base d'utilisateurs. Parfait ! Maintenant, chaque fois que nous ne sommes pas sûrs de notre code (en d'autres termes - toujours…), nous pouvons utiliser le mirroring et les déploiements canary.

Timeouts et réessais

Mais les bogues ne se trouvent pas toujours dans le code. Dans la liste des «8 idées reçues en informatique distribuée», l'idée fausse selon laquelle « le réseau est fiable » figure en tête. En réalité, le réseau ne est fiable, et c'est pourquoi nous avons besoin de timeouts (timeouts) et de réessais (retries).

Pour la démonstration, nous allons continuer à utiliser la même version du problème sa-logic (buggy), tandis que l'instabilité du réseau sera simulée par des pannes aléatoires.

Supposons que notre service avec des bogues ait 1/3 de chances d'avoir une réponse trop longue, 1/3 de chances de se terminer par une erreur de serveur interne et 1/3 de chances de retourner une page avec succès.

Pour atténuer les conséquences de tels problèmes et améliorer la vie des utilisateurs, nous pouvons :

1. ajouter un timeout si le service met plus de 8 secondes à répondre,
2. effectuer un réessai si une erreur se produit avec la requête.

Pour la mise en œuvre, nous utiliserons la définition de ressource suivante (sa-logic-retries-timeouts-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic
  http:
  - route: 
    - destination: 
        host: sa-logic
        subset: v1
      weight: 50
    - destination: 
        host: sa-logic
        subset: v2
      weight: 50
    timeout: 8s           # 1
    retries:
      attempts: 3         # 2
      perTryTimeout: 3s # 3

1. Le timeout pour la requête est fixé à 8 secondes ;
2. Les réessais des requêtes sont effectués 3 fois ;
3. Et chaque tentative est considérée comme un échec si le temps de réponse dépasse 3 secondes.

Ainsi, nous avons optimisé, car l'utilisateur n'aura pas à attendre plus de 8 secondes et nous effectuerons trois nouvelles tentatives pour obtenir une réponse en cas d'échec, augmentant ainsi les chances d'une réponse réussie.

Appliquez la configuration mise à jour avec la commande suivante :

$ kubectl apply -f resource-manifests/istio/retries/sa-logic-retries-timeouts-vs.yaml
virtualservice.networking.istio.io/sa-logic configuré

Et vérifiez dans les graphiques Grafana que le nombre de réponses réussies a dépassé :

Améliorations dans les statistiques de réponses réussies après l'ajout de délais et de nouvelles tentatives

Avant de passer à la section suivante (plutôt à la prochaine partie de l'article, car il n'y aura plus d'expériences pratiques dans celui-ci - note du traducteur), supprimez sa-logic-buggy et VirtualService en exécutant les commandes suivantes :

$ kubectl delete deployment sa-logic-buggy
deployment.extensions “sa-logic-buggy” supprimé
$ kubectl delete virtualservice sa-logic
virtualservice.networking.istio.io “sa-logic” supprimé

Les patterns Circuit Breaker et Bulkhead

Il s'agit de deux patterns importants en architecture microservices qui permettent l'auto-récupération (self-healing) des services.

Circuit Breaker (« disjoncteur ») est utilisé pour arrêter les requêtes envoyées à une instance de service considérée comme non saine, et pour la rétablir pendant que les requêtes des clients sont redirigées vers des instances saines de ce service (ce qui augmente le pourcentage de réponses réussies). (Note du traducteur : Une description plus détaillée du pattern peut être trouvée, par exemple, ici.)

Bulkhead (« cloison ») isole les pannes dans les services pour empêcher l'ensemble du système d'être affecté. Par exemple, si le service B est en panne, un autre service (client du service B) effectue une demande au service B, ce qui lui fait épuiser son pool de threads et ne peut plus traiter d'autres demandes (même si elles ne concernent pas le service B). (Note du traducteur : Une description plus détaillée du pattern peut être trouvée, par exemple, ici.)

Je vais passer les détails de l'implémentation de ces patterns, car il est facile de les trouver dans la documentation officielle, et j'ai également très envie de montrer l'authentification et l'autorisation, qui seront abordées dans la prochaine partie de l'article.

P.S. de l'auteur

Lisez aussi dans notre blog :

• « Retour aux microservices avec Istio » : partie 1 (introduction aux principales fonctionnalités), partie 3 (authentification et autorisation);
• «Conduit — un service mesh léger pour Kubernetes»;
• «Qu'est-ce qu'un service mesh et pourquoi ai-je besoin de lui [pour une application cloud avec des microservices] ?».

Source : habr.com