Gestion du trafic avec Istio sur OVHcloud Managed Kubernetes

Istio est une plateforme de service mesh open source qui réduit la complexité du déploiement, de la sécurisation, du contrôle et de l'observation de services distribués. Comme l'explique le site d'Istio, Istio vous aide à :

• Contrôler le flux de trafic entre les services
• Sécuriser les services et gérer l'authentification, l'autorisation et le chiffrement des communications inter-services
• Appliquer et faire respecter des politiques sur des services distribués
• Superviser les services en collectant des métriques, des logs et des traces

Ce tutoriel présente certaines fonctionnalités de gestion du trafic d'Istio et explique comment les utiliser sur votre cluster OVHcloud Managed Kubernetes.

Avant de commencer

Ce tutoriel suppose que vous disposez déjà d'un cluster OVHcloud Managed Kubernetes fonctionnel, ainsi que de connaissances de base sur son fonctionnement. Pour en savoir plus sur ces sujets, consultez la documentation Déployer une application Hello World.

Ce tutoriel suppose également que vous avez des connaissances de base sur Istio et que vous l'avez installé sur votre cluster Kubernetes. Si ce n'est pas le cas, suivez d'abord le tutoriel Installer Istio sur OVHcloud Managed Kubernetes. Ce tutoriel utilise l'application exemple Bookinfo, comme dans le tutoriel précédent. Si vous ne l'avez pas encore installée, faites-le maintenant.

Préparation de l'application Bookinfo

Avant de pouvoir utiliser Istio pour contrôler le routage des versions de Bookinfo, vous devez définir les versions disponibles, appelées subsets, dans les destination rules.

Accédez à votre dossier d'installation d'Istio et appliquez les DestinationRules pour Bookinfo :

kubectl -n istio-apps apply -f samples/bookinfo/networking/destination-rule-all-mtls.yaml

Patientez quelques instants pour laisser les destination rules se propager, puis vérifiez-les :

kubectl -n istio-apps get destinationrules -o yaml

Pour l'exemple de notre cluster :

$ kubectl -n istio-apps apply -f samples/bookinfo/networking/destination-rule-all-mtls.yaml
destinationrule.networking.istio.io/productpage created
destinationrule.networking.istio.io/reviews created
destinationrule.networking.istio.io/ratings created
destinationrule.networking.istio.io/details created

$ kubectl -n istio-apps get destinationrules -o yaml
apiVersion: v1
items:
- apiVersion: networking.istio.io/v1beta1
  kind: DestinationRule
  metadata:
    annotations:
      kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"networking.istio.io/v1beta1","kind":"DestinationRule","metadata":{"annotations":{},"name":"details","namespace":"istio-apps"},"spec":{"host":"details","subsets":[{"labels":{"version":"v1"},"name":"v1"},{"labels":{"version":"v2"},"name":"v2"}],"trafficPolicy":{"tls":{"mode":"ISTIO_MUTUAL"}}}}
    creationTimestamp: "2021-09-21T15:00:57Z"
    generation: 1
    name: details
    namespace: istio-apps
    resourceVersion: "524439454"
    uid: 10b370f0-f1a8-4830-bb9f-458c77b1c03d
  spec:
    host: details
    subsets:
    - labels:
        version: v1
      name: v1
    - labels:
        version: v2
      name: v2
    trafficPolicy:
      tls:
        mode: ISTIO_MUTUAL
[...] 

Tests A/B avec Istio

Les tests A/B sont utilisés lorsque l'on souhaite essayer deux versions différentes d'une application et comparer l'interaction et l'engagement des utilisateurs afin de choisir la meilleure. Cela nécessite de pouvoir déployer les deux versions en production en même temps, de répartir le trafic entre les deux versions et de collecter des métriques permettant de faire un choix éclairé.

Les tests A/B étaient un problème complexe avec les méthodes de déploiement traditionnelles, et il est très difficile de les réaliser directement dans Kubernetes puisqu'il n'existe pas de notion de version, mais Istio simplifie considérablement cette démarche.

Cette section utilise l'application Bookinfo pour montrer comment réaliser facilement des tests A/B sur Kubernetes avec Istio. L'application Bookinfo est composée de quatre microservices distincts :

• productpage : il appelle les services reviews et details et construit la page
• reviews : il contient les avis sur les livres et appelle le service rating
• details : il contient les informations sur le livre
• ratings : il contient les informations de notation du livre

Pour mettre en place des tests A/B sur Bookinfo, cette section utilise le microservice reviews, qui dispose de trois versions :

• v1 : n'appelle pas le service ratings
• v2 : appelle le service ratings et affiche la notation sous forme d'étoiles noires
• v3 : appelle le service ratings et affiche la notation sous forme d'étoiles rouges

Par défaut, l'installation de Bookinfo déploie les trois versions sans définition de routage explicite. Istio route alors les requêtes vers toutes les versions disponibles de reviews selon un principe de répartition circulaire (round robin), si bien que l'affichage des avis sur les livres contient parfois des notations en étoiles, et parfois non.

Supposons que l'on souhaite envoyer 50 % du trafic vers v2, pour obtenir les étoiles noires, et les 50 % restants vers v3, pour ses étoiles rouges. Vous pouvez créer un VirtualService pour définir ce comportement :

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
    - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v2
      weight: 50
    - destination:
        host: reviews
        subset: v3
      weight: 50

Enregistrez le VirtualService dans un fichier reviews-50-v2-50-v3.yaml et appliquez-le :

kubectl apply -n istio-apps -f reviews-50-v2-50-v3.yaml

puis confirmez que la règle a bien été créée :

kubectl -n istio-apps get virtualservice reviews -o yaml

Pour l'exemple de notre cluster :

$ kubectl apply -n istio-apps -f ./reviews-50-v2-50-v3.yaml 
virtualservice.networking.istio.io/reviews created

$ kubectl -n istio-apps get virtualservice reviews -o yaml
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
[...]
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v2
      weight: 50
    - destination:
        host: reviews
        subset: v3
      weight: 50

Désormais, sur la page /productpage de l'application Bookinfo (accessible via l'URL http://$GATEWAY_URL/productpage), à chaque actualisation, vous verrez les étoiles alterner entre noires (v2) et rouges (v3).

Tests Canary avec Istio

Comme les tests A/B, les tests Canary consistent à déployer une nouvelle version d'un service auprès d'un petit groupe d'utilisateurs. L'idée est de tester la nouvelle version de façon progressive, sur un nombre réduit d'utilisateurs réels, afin de détecter rapidement d'éventuels bugs tout en limitant le nombre d'utilisateurs impactés.

Cette stratégie est appelée « Canary Testing » car des canaris étaient autrefois utilisés dans les mines de charbon pour alerter les mineurs lorsque le niveau de gaz toxiques devenait dangereux. Comme le canari dans la mine, l'utilisateur final sélectionné pour recevoir la nouvelle version n'a pas conscience de servir à détecter un problème en amont.

La mise en œuvre des tests Canary sur Kubernetes avec Istio est similaire à celle des tests A/B.

Commencez par rediriger tout le trafic de reviews vers v1, qui constituera la version stable :

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
    - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 100

Enregistrez le VirtualService dans un fichier reviews-all-v1.yaml et appliquez-le :

kubectl apply -n istio-apps -f reviews-all-v1.yaml

puis confirmez que la règle a bien été créée :

kubectl -n istio-apps get virtualservice reviews -o yaml

À ce stade, tout le trafic est dirigé vers la version v1 de reviews, sans notation :

Supposons maintenant que l'on souhaite envoyer 5 % du trafic vers v2. Il suffit de définir ce nouveau comportement dans un fichier YAML :

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
    - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 90
    - destination:
        host: reviews
        subset: v2
      weight: 10

Enregistrez le VirtualService dans un fichier reviews-90-v1-10-v2.yaml et appliquez-le :

kubectl -n istio-apps apply -f reviews-90-v1-10-v2.yaml

puis confirmez que la règle a bien été créée :

kubectl -n istio-apps get virtualservice reviews -o yaml

Désormais, sur la page /productpage de l'application Bookinfo, 9 fois sur 10 vous obtiendrez la version v1, sans notation, et 1 fois sur 10 la version v2, avec des étoiles noires.

Déploiements progressifs (Rolling) et déploiements Blue/Green

Les déploiements progressifs (Rolling Deployments) et les déploiements Blue/Green sont des stratégies de déploiement qui garantissent la livraison de nouvelles versions sans interruption de service.

Réaliser un déploiement progressif avec Istio est assez simple : vous pouvez reprendre comme base les exemples des tests Canary et des tests A/B.

Appliquez à nouveau le fichier reviews-all-v1.yaml pour rediriger tout le trafic de reviews vers v1 :

kubectl -n istio-apps apply -f reviews-all-v1.yaml

La version v1 constitue notre version initiale. Supposons que l'on souhaite déployer v2 comme nouvelle version, en utilisant un déploiement progressif pour garantir l'absence d'interruption de service. Le moyen le plus simple consiste à passer par un état intermédiaire où le trafic est réparti à 50 %-50 % entre v1 et v2 :

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
    - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 50
    - destination:
        host: reviews
        subset: v2
      weight: 50

Enregistrez le VirtualService dans un fichier reviews-50-v1-50-v2.yaml et appliquez-le :

kubectl -n istio-apps apply -f reviews-50-v1-50-v2.yaml

À ce stade, le trafic est réparti de façon égale entre les deux versions de reviews.

Si tout est correct, vous pouvez router en toute sécurité l'ensemble du trafic vers v2 :

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
    - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v2
      weight: 100

Enregistrez le VirtualService dans un fichier reviews-all-v2.yaml et appliquez-le :

kubectl -n istio-apps apply -f reviews-all-v2.yaml

Désormais, la version v2 de reviews reçoit tout le trafic, et le déploiement progressif est terminé.

Aller plus loin

Après avoir découvert certaines des capacités de gestion du trafic d'Istio, vous pouvez explorer d'autres exemples de gestion du trafic avec Istio : injection de pannes, circuit breaking, mise en miroir (mirroring)...

• Pour une formation ou une assistance technique sur la mise en œuvre de nos solutions, contactez votre commercial ou consultez la page Professional Services pour obtenir un devis et faire analyser votre projet par nos experts.

• Échangez avec notre communauté d'utilisateurs.