Présentation

Cloud Service Mesh est une architecture qui permet une communication gérée, observable et sécurisée entre vos services. Elle vous aide ainsi à créer plus facilement des applications d'entreprise fiables dotées de nombreux microservices sur l'infrastructure de votre choix. Cette solution répond aux exigences courantes liées à l'exécution d'un service, telles que la surveillance, la mise en réseau et la sécurité, à l'aide d'outils performants et cohérents. Cela permet aux développeurs et aux opérateurs de services de se concentrer plus facilement sur la création et la gestion d'applications de qualité pour leurs utilisateurs.

Le modèle de gestion du trafic de Cloud Service Mesh repose sur ces deux composants :

• Plan de contrôle : il gère et configure les proxys Envoy pour acheminer le trafic et appliquer les règles.
• Plan de données : il englobe toutes les communications réseau entre microservices établies au moment de l'exécution par les proxys Envoy.

Ces composants permettent d'activer des fonctionnalités de gestion du trafic de maillage, y compris les suivantes :

• Découverte des services
• Équilibrage de charge
• Routage et contrôle du trafic

Objectifs

Dans cet atelier, vous allez apprendre à effectuer les tâches suivantes :

• Configurer et utiliser des passerelles Istio
• Appliquer les règles de destination par défaut pour toutes les versions disponibles
• Appliquer des services virtuels pour acheminer par défaut le trafic vers une seule version
• Acheminer le trafic vers une version spécifique d'un service selon l'identité de l'utilisateur
• Déplacer progressivement le trafic d'une version d'un microservice à une autre
• Afficher le routage vers plusieurs versions à l'aide du tableau de bord Cloud Service Mesh
• Mettre en place des bonnes pratiques de mise en réseau, telles que des nouvelles tentatives, des disjoncteurs et des délais avant expiration

Préparation

Dans cette tâche, vous allez initialiser votre atelier.

Pour chaque atelier, nous vous attribuons un nouveau projet Google Cloud et un nouvel ensemble de ressources pour une durée déterminée, sans frais.

1. Connectez-vous à Google Skills dans une fenêtre de navigation privée.

2. Vérifiez le temps imparti pour l'atelier (par exemple : 01:15:00) : vous devez pouvoir le terminer dans ce délai. Une fois l'atelier lancé, vous ne pourrez pas le mettre sur pause. Si nécessaire, vous pourrez le redémarrer, mais vous devrez tout reprendre depuis le début.

3. Lorsque vous êtes prêt, cliquez sur Démarrer l'atelier.

4. Notez vos identifiants pour l'atelier (Nom d'utilisateur et Mot de passe). Ils vous serviront à vous connecter à la console Google Cloud.

5. Cliquez sur Ouvrir la console Google.

6. Cliquez sur Utiliser un autre compte, puis copiez-collez les identifiants de cet atelier lorsque vous y êtes invité. Si vous utilisez d'autres identifiants, des messages d'erreur s'afficheront ou des frais seront facturés.

7. Acceptez les conditions d'utilisation et ignorez la page concernant les ressources de récupération des données.

Une fois la connexion initiale effectuée, le tableau de bord du projet s'affiche.

8. Cliquez sur Sélectionner un projet, puis sélectionnez l'ID de votre projet GCP. Cliquez ensuite sur OUVRIR.

Activer Google Cloud Shell

Google Cloud Shell est une machine virtuelle qui contient de nombreux outils pour les développeurs. Elle comprend un répertoire d'accueil persistant de 5 Go et s'exécute sur Google Cloud.

Google Cloud Shell vous permet d'accéder à vos ressources Google Cloud grâce à une ligne de commande.

1. Dans la barre d'outils située en haut à droite dans la console Cloud, cliquez sur le bouton "Ouvrir Cloud Shell".

   

2. Cliquez sur Continuer.

Le provisionnement et la connexion à l'environnement prennent quelques instants. Une fois connecté, vous êtes en principe authentifié et le projet est défini sur votre ID_PROJET. Par exemple :

gcloud est l'outil de ligne de commande pour Google Cloud. Il est préinstallé sur Cloud Shell et permet la complétion par tabulation.

• Vous pouvez lister les noms des comptes actifs à l'aide de cette commande :

gcloud auth list

Résultat :

Credentialed accounts: - @.com (active)

Exemple de résultat :

Credentialed accounts: - google1623327_student@qwiklabs.net

• Vous pouvez lister les ID de projet à l'aide de cette commande :

gcloud config list project

Résultat :

[core] project =

Exemple de résultat :

[core] project = qwiklabs-gcp-44776a13dea667a6 Remarque : Pour consulter la documentation complète sur gcloud, accédez au guide de présentation de la gcloud CLI.

Tâche 1. Examiner des cas d'utilisation de la gestion du trafic

Vous pouvez activer les diverses fonctionnalités de gestion du trafic à l'aide des différentes options de configuration.

Exemple : répartition du trafic

Routez le trafic vers plusieurs versions d'un service.

Exemple : délais avant expiration

Fixez un délai avant expiration, c'est-à-dire la durée pendant laquelle Istio attend une réponse à une requête. Le délai avant expiration des requêtes HTTP est de 15 secondes, mais il peut être modifié.

Exemple : nouvelles tentatives

En cas d'échec d'une opération, de nouvelles tentatives sont effectuées. Ajustez le nombre maximum de nouvelles tentatives ou le nombre de tentatives possibles pendant le délai avant expiration par défaut ou redéfini.

Exemple : injection de pannes avec insertion de délais

L'injection de pannes est une méthode de test qui introduit des erreurs dans un système pour s'assurer qu'il peut résister à des conditions d'erreur et effectuer une récupération.

Cet exemple introduit un retard de 5 secondes dans 10 % des requêtes à la version v1 du microservice "ratings".

Exemple : injection de pannes avec insertion d'abandons

L'exemple ci-dessus renvoie un code d'erreur HTTP 400 pour 10 % des requêtes à la version v1 du microservice "ratings".

Exemple : routage conditionnel en fonction des étiquettes sources

Une règle peut indiquer qu'elle ne s'applique qu'aux appels provenant de charges de travail (pods) implémentant la version v2 du service "reviews".

Exemple : routage conditionnel en fonction des en-têtes de requête

La règle ci-dessus ne s'applique qu'aux requêtes entrantes qui incluent un en-tête personnalisé "end-user" (utilisateur final) contenant la chaîne "atharvak".

Tâche 2. Terminer la configuration de l'atelier

L'environnement de cet atelier a déjà été partiellement configuré.

• Un cluster GKE nommé gke a été créé.
• Cloud Service Mesh a été installé.
• L'exemple d'application multiservice Bookinfo a été déployé.

Configurer l'accès au cluster pour kubectl

1. Définissez la variable d'environnement correspondant à la zone :

   CLUSTER_ZONE={{{ project_0.default_zone| "Zone added at lab start" }}}

2. Dans Cloud Shell, définissez la variable d'environnement correspondant au nom du cluster :

   export CLUSTER_NAME=gke

3. Configurez l'accès à la ligne de commande kubectl en exécutant cette commande :

   export GCLOUD_PROJECT=$(gcloud config get-value project) gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $CLUSTER_ZONE --project $GCLOUD_PROJECT

   Si vous y êtes invité, cliquez sur le bouton Autoriser.

Vérifier l'installation du cluster et de Cloud Service Mesh

4. Vérifiez que votre cluster est opérationnel :

   gcloud container clusters list

   Résultat :

   NAME: gke LOCATION: {{{ project_0.default_zone| "Zone" }}} MASTER_VERSION: 1.24.8-gke.2000 MASTER_IP: 35.222.150.207 MACHINE_TYPE: e2-standard-4 NODE_VERSION: 1.24.8-gke.2000 NUM_NODES: 2 STATUS: RUNNING

5. Vérifiez que les pods Kubernetes pour le plan de contrôle Cloud Service Mesh sont déployés :

   kubectl get pods -n asm-ingress

Résultat :

NAME READY STATUS RESTARTS AGE istio-ingressgateway-69fc5475fd-4wglw 1/1 Running 0 22m istio-ingressgateway-69fc5475fd-stb7x 1/1 Running 0 22m istio-ingressgateway-69fc5475fd-vkxp4 1/1 Running 0 22m

L'état des pods doit être Running (En cours d'exécution) ou Completed (Terminé).

6. Vérifiez que les services Kubernetes correspondants pour le plan de contrôle Cloud Service Mesh sont déployés :

   kubectl get service -n asm-ingress

Résultat :

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE istio-ingressgateway LoadBalancer 34.118.232.124 34.75.207.190 15021:32645/TCP,80:31091/TCP,443:32092/TCP 30m

Vérifier le déploiement de Bookinfo

8. Vérifiez que l'application a été correctement déployée :

   kubectl get pods

   Résultat :

   NAME READY STATUS details-v1-1520924117-48z17 2/2 Running productpage-v1-560495357-jk1lz 2/2 Running ratings-v1-734492171-rnr5l 2/2 Running reviews-v1-874083890-f0qf0 2/2 Running reviews-v2-1343845940-b34q5 2/2 Running reviews-v3-1813607990-8ch52 2/2 Running Remarque : Vous pouvez constater que chaque pod comporte deux conteneurs. Il s'agit du conteneur d'application et du proxy side-car Istio.

9. Examinez les services applicatifs en cours d'exécution :

   kubectl get services

   Résultat :

   NAME TYPE CLUSTER-IP EXTERNAL-IP ... details ClusterIP 10.7.248.49 kubernetes ClusterIP 10.7.240.1 productpage ClusterIP 10.7.248.22 ratings ClusterIP 10.7.247.26 reviews ClusterIP 10.7.246.22

Tâche 3 : Installer des ressources de passerelle (Gateway) pour activer une ressource Ingress

Dans un environnement Kubernetes, les services qui doivent être exposés en dehors du cluster sont définis par la ressource Ingress de Kubernetes. Dans Cloud Service Mesh, l'approche est améliorée et consiste à utiliser une ressource de passerelle, ce qui fonctionne également dans Kubernetes et d'autres environnements. Une passerelle offre des fonctionnalités de maillage, telles que la surveillance, mTLS et des règles de routage avancées applicables au trafic entrant dans le cluster.

Les passerelles corrigent les limites de la ressource Ingress de Kubernetes en séparant les spécifications L4 à L6 de L7. La passerelle configure les fonctions L4 à L6, telles que les ports à exposer ou le protocole à utiliser. Les propriétaires de services lient ensuite une ressource VirtualService pour configurer les options de routage du trafic L7, telles que le routage en fonction des chemins d'accès, des en-têtes, des pondérations, etc.

Il existe deux options pour le déploiement des passerelles : les passerelles partagées et les passerelles dédiées. L'option de passerelle partagée utilise une seule passerelle centralisée pour de nombreuses applications, éventuellement dans plusieurs espaces de noms. Dans l'exemple ci-dessous, la passerelle dans l'espace de noms Ingress délègue la propriété des routes aux espaces de noms de l'application, mais garde le contrôle de la configuration TLS. Cette configuration est idéale lorsque vous utilisez des certificats TLS partagés ou une infrastructure partagée. Dans cet atelier, nous allons utiliser cette option.

Les passerelles dédiées permettent d'avoir un contrôle total et l'entière propriété des données dans un espace de noms unique, étant donné que l'espace de noms de l'application possède sa propre passerelle dédiée. Cette configuration est idéale pour les applications nécessitant une isolation dans une optique de sécurité ou de performances.

Installer une passerelle d'entrée dans votre cluster

1. Créez un espace de noms pour la passerelle :

   kubectl create namespace ingress

2. Ajoutez une étiquette de révision à l'espace de noms de la passerelle pour l'injection automatique :

   kubectl label namespace ingress istio.io/rev=asm-managed --overwrite

   Le webhook d'injecteur side-car utilise l'étiquette de révision pour associer les proxys injectés à une révision du plan de contrôle particulière.

   Vous pouvez ignorer le message "istio-injection not found" dans le résultat. Ce message s'affiche parce que l'étiquette "istio-injection" devrait en principe être attribuée à l'espace de noms, comme c'est le cas pour les nouvelles installations de Service Mesh ou les nouveaux déploiements.

   Étant donné que l'injection automatique échoue si un espace de noms possède à la fois l'étiquette "istio-injection" et l'étiquette de révision, toutes les commandes kubectl label de la documentation de Service Mesh incluent la suppression de l'étiquette "istio-injection".

3. Téléchargez et appliquez les fichiers de configuration de la passerelle. Ils indiquent les pods et les services qui recevront d'abord les requêtes entrantes provenant de l'extérieur du cluster :

cat <<'EOF' > ingress.yaml apiVersion: v1 kind: ServiceAccount metadata: name: istio-ingressgateway namespace: ingress --- apiVersion: v1 kind: Service metadata: name: istio-ingressgateway namespace: ingress labels: app: istio-ingressgateway istio: ingressgateway spec: ports: # status-port exposes a /healthz/ready endpoint that can be used with GKE Ingress health checks - name: status-port port: 15021 protocol: TCP targetPort: 15021 # Any ports exposed in Gateway resources should be exposed here. - name: http2 port: 80 - name: https port: 443 selector: istio: ingressgateway app: istio-ingressgateway type: LoadBalancer --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: istio-ingressgateway namespace: ingress rules: - apiGroups: - "" resources: - secrets verbs: - get - watch - list --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: istio-ingressgateway namespace: ingress roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: istio-ingressgateway subjects: - kind: ServiceAccount name: istio-ingressgateway --- apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: istio-ingressgateway namespace: ingress spec: maxUnavailable: 1 selector: matchLabels: istio: ingressgateway app: istio-ingressgateway --- apiVersion: apps/v1 kind: Deployment metadata: name: istio-ingressgateway namespace: ingress spec: replicas: 1 selector: matchLabels: app: istio-ingressgateway istio: ingressgateway template: metadata: annotations: # This is required to inject the gateway with the # required configuration. inject.istio.io/templates: gateway labels: app: istio-ingressgateway istio: ingressgateway spec: containers: - name: istio-proxy image: auto # The image will automatically update each time the pod starts. serviceAccountName: istio-ingressgateway --- apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: istio-ingressgateway namespace: ingress spec: maxReplicas: 5 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 80 minReplicas: 3 scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: istio-ingressgateway EOF kubectl apply -n ingress -f ingress.yaml

4. Après avoir créé le déploiement, vérifiez que les nouveaux services fonctionnent bien :

   kubectl get pod,service -n ingress

   Notez que la ressource est un équilibreur de charge (LoadBalancer). Cette passerelle d'entrée utilise un équilibreur de charge TCP externe dans GCP.

5. Déployez la passerelle pour spécifier le port et le protocole à utiliser. Ici, la passerelle autorise le trafic HTTP sur le port 80 :

   cat <<EOF | kubectl apply -f - apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: bookinfo-gateway namespace: ingress spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - "*" EOF

   La ressource Gateway doit se trouver dans le même espace de noms que le déploiement de la passerelle.

6. Déployez la ressource VirtualService pour acheminer le trafic provenant des pods et du service de la passerelle que vous venez de créer vers l'application Bookinfo :

   cat <<EOF | kubectl apply -f - apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: bookinfo spec: hosts: - "*" gateways: - ingress/bookinfo-gateway http: - match: - uri: exact: /productpage - uri: prefix: /static - uri: exact: /login - uri: exact: /logout - uri: prefix: /api/v1/products route: - destination: host: productpage port: number: 9080 EOF

   La ressource VirtualService doit se trouver dans le même espace de noms que l'application. Notez qu'elle définit le service productpage comme destination par défaut.

7. Vérifiez que les ressources Gateway et VirtualService ont bien été créées et notez que VirtualService pointe vers Gateway :

   kubectl get gateway,virtualservice

8. Enregistrez cette adresse IP externe dans votre environnement Cloud Shell :

   export GATEWAY_URL=$(kubectl get svc -n ingress istio-ingressgateway \ -o=jsonpath='{.status.loadBalancer.ingress[0].ip}') echo The gateway address is $GATEWAY_URL

Remarque : Si aucune adresse n'apparaît pour la passerelle, patientez une à deux minutes, puis réexécutez la dernière commande. Répétez cette opération jusqu'à ce qu'une adresse soit définie dans la variable $GATEWAY_URL.

Générer du trafic en arrière-plan

Générez du trafic en arrière-plan sur l'application afin de pouvoir consulter quelques données pertinentes dans le tableau de bord Service Mesh.

1. Dans Cloud Shell, installez l'outil de génération de charge siege :

   sudo apt install siege

2. La commande siege vous permet de créer du trafic sur vos services :

   siege http://${GATEWAY_URL}/productpage

Accéder à l'application Bookinfo

1. Dans Cloud Shell, ouvrez un autre onglet en cliquant sur l'icône + dans la barre de menu.

2. Définissez la variable d'environnement correspondant à la zone :

   CLUSTER_ZONE={{{ project_0.default_zone| "Zone added at lab start" }}}

3. Initialisez le nouvel onglet Cloud Shell :

   export CLUSTER_NAME=gke export GCLOUD_PROJECT=$(gcloud config get-value project) gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $CLUSTER_ZONE --project $GCLOUD_PROJECT export GATEWAY_URL=$(kubectl get svc istio-ingressgateway \ -o=jsonpath='{.status.loadBalancer.ingress[0].ip}' -n ingress)

4. Vérifiez que l'application Bookinfo répond en lui envoyant une requête curl depuis l'un des pods du cluster (par exemple, depuis ratings) :

   kubectl exec -it \ $(kubectl get pod -l app=ratings -o jsonpath='{.items[0].metadata.name}') \ -c ratings -- curl productpage:9080/productpage \ | grep -o "<title>.*</title>"

   Résultat :

   <title>Simple Bookstore App</title>

5. Vérifiez que l'application Bookinfo répond à une requête curl qui lui est envoyée depuis l'extérieur du cluster, en utilisant l'adresse IP externe enregistrée précédemment :

   curl -I http://${GATEWAY_URL}/productpage

   Résultat :

   HTTP/1.1 200 OK content-type: text/html; charset=utf-8 content-length: 5293 server: istio-envoy date: Wed, 01 Feb 2023 13:28:58 GMT x-envoy-upstream-service-time: 27

6. Ouvrez l'application Bookinfo dans votre navigateur. Exécutez la commande suivante dans Cloud Shell pour obtenir l'URL complète :

   echo http://${GATEWAY_URL}/productpage

Félicitations ! Vous avez exposé un point de terminaison HTTP pour le service "productpage" Bookinfo au trafic externe. Les ressources de configuration de la passerelle permettent au trafic externe d'entrer dans le maillage de services et mettent les fonctionnalités de gestion du trafic et de règles à la disposition des services périphériques.

Cliquez sur Vérifier ma progression pour valider l'objectif. Installer des ressources de passerelle (Gateway) pour activer une ressource Ingress

Tâche 4 : Visualiser le routage vers plusieurs versions à l'aide du tableau de bord Service Mesh

Deux points sont à noter concernant l'affichage des données dans le tableau de bord Service Mesh.

Le premier est que, pour la plupart des pages, l'affichage des données prend une à deux minutes. Par conséquent, il est possible que vous deviez attendre une à deux minutes pour voir les données qui vous intéressent. Si elles ne s'affichent pas, patientez environ une minute, puis actualisez la page.

De plus, l'affichage des données sur la page "Topologie" prend beaucoup de temps. Les premières données peuvent mettre jusqu'à cinq minutes à s'afficher. Si vous recevez un message indiquant qu'aucune donnée n'est disponible, patientez un peu, puis actualisez la page et revenez à la vue "Topologie".

Les paragraphes précédents vous invitent à patienter, mais aussi à actualiser la page. En effet, l'affichage des données prend du temps, mais nécessite aussi dans de nombreux cas d'actualiser la page. Par conséquent, si vous ne voyez pas les données alors qu'elles devraient être disponibles, actualisez la page dans votre navigateur.

Afficher les informations de routage dans la vue "Tableau"

1. Dans le menu de navigation, sélectionnez Kubernetes Engine > Fonctionnalités > Service Mesh.

   

Remarque : Si la vue "Topologie" ne s'affiche pas, actualisez la fenêtre du navigateur.

2. Cliquez sur le service productpage, puis sélectionnez Services connectés sur la gauche.

3. Sélectionnez l'onglet Sortant, puis notez les deux services appelés par les pods productpage.

4. Cliquez sur le service reviews.

   

5. Notez les statistiques du service, puis sélectionnez le lien Infrastructure dans le menu de gauche.

Vous pouvez constater qu'il existe plusieurs pods, exécutant différentes versions de la logique "reviews", qui reçoivent le trafic envoyé vers le service "reviews".

6. Cliquez sur Trafic dans le menu de gauche pour afficher une autre vue de la répartition du trafic.

   

   Vous pouvez constater que la répartition du trafic entre les trois pods de backend exécutant les différentes versions de la logique d'application est relativement équitable.

Afficher les informations sur le routage dans la vue "Topologie"

1. Cliquez sur le logo Service Mesh en haut à gauche pour revenir à la page principale du tableau de bord.

Remarque : Si un message d'erreur indiquant qu'il n'y a pas de données disponibles pour le graphique s'affiche, ou si un graphique ne contient pas l'ensemble du trafic attendu, patientez une à deux minutes, puis réessayez.

2. Réorganisez le graphique de maillage pour pouvoir consulter facilement les éléments suivants :

   • Le service productpage allant vers le déploiement productpage
   • Le déploiement productpage allant vers le service reviews
   • Le service reviews allant vers trois versions de reviews

   

3. Cliquez sur le nœud du service reviews, puis affichez le nombre de RPS relatif correspondant à chaque version de backend.

   

Tâche 5 : Appliquer les règles de destination par défaut pour toutes les versions disponibles

Dans cette tâche, vous définissez toutes les versions disponibles, appelées sous-ensembles, dans les règles de destination.

1. Examinez la configuration disponible sur GitHub. Cette configuration définit quatre ressources DestinationRule, une pour chaque service.

2. Appliquez la configuration en exécutant la commande suivante dans Cloud Shell :

   wget https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/networking/destination-rule-all.yaml sed -i 's#istio\.io/v1#istio\.io/v1alpha3#g' destination-rule-all.yaml kubectl apply -f destination-rule-all.yaml

   Résultat :

   destinationrule.networking.istio.io/productpage created destinationrule.networking.istio.io/reviews created destinationrule.networking.istio.io/ratings created destinationrule.networking.istio.io/details created

3. Vérifiez que les quatre ressources DestinationRule ont bien été définies.

   kubectl get destinationrules

   Résultat :

   NAME HOST AGE details details 1m productpage productpage 1m ratings ratings 1m reviews reviews 1m

4. Examinez les détails des règles de destination :

   kubectl get destinationrules -o yaml

   Notez que des subsets sont définis dans spec d'une ressource DestinationRule.

5. Patientez une à deux minutes, puis revenez au tableau de bord Service Mesh.

6. Examinez à la fois les vues "Tableau" et "Topologie", puis vérifiez que le trafic continue à être réparti de manière égale entre les trois versions de backend. Vous pouvez cliquer sur AFFICHER LA CHRONOLOGIE pour ajuster la période représentée dans le graphique, ce qui vous permet de vous concentrer plus facilement sur les données qui vous intéressent.

Cliquez sur Vérifier ma progression pour valider l'objectif. Appliquer les règles de destination

Tâche 6 : Appliquer des services virtuels pour acheminer par défaut le trafic vers une seule version

Dans cette tâche, vous allez appliquer des services virtuels pour chaque service qui achemine la totalité du trafic vers la v1 de la charge de travail du service.

1. Examinez la configuration disponible sur GitHub. Cette configuration définit quatre ressources VirtualService, une pour chaque service.

2. Appliquez la configuration en exécutant la commande suivante dans Cloud Shell :

   wget https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/networking/virtual-service-all-v1.yaml sed -i 's#istio\.io/v1#istio\.io/v1alpha3#g' virtual-service-all-v1.yaml kubectl apply -f virtual-service-all-v1.yaml

   Résultat :

   virtualservice.networking.istio.io/productpage created virtualservice.networking.istio.io/reviews created virtualservice.networking.istio.io/ratings created virtualservice.networking.istio.io/details created

   La propagation de la configuration étant cohérente à terme, attendez quelques secondes que les services virtuels prennent effet.

3. Vérifiez que les quatre routes (ressources VirtualService) ont bien été définies :

   kubectl get virtualservices

   Résultat :

   NAME GATEWAYS HOSTS AGE bookinfo ["ingress/bookinfo-gateway"] ["*"] 19m details ["details"] 6s productpage ["productpage"] 7s ratings ["ratings"] 6s reviews ["reviews"] 7s

4. Dans Cloud Shell, récupérez l'adresse IP externe de la passerelle d'entrée :

   echo $GATEWAY_URL

5. Testez la nouvelle configuration de routage à l'aide de l'UI de Bookinfo.

   • Ouvrez le site Bookinfo dans votre navigateur. L'URL est http://[GATEWAY_URL]/productpage, où GATEWAY_URL correspond à l'adresse IP externe de l'entrée.

   • Actualisez la page plusieurs fois pour envoyer plusieurs requêtes.

   Notez que la section Book Reviews (Avis sur les livres) de la page n'affiche aucune note, quel que soit le nombre de fois que vous la réactualisez. Ceci est dû au fait que vous avez configuré le maillage pour acheminer tout le trafic du service "reviews" vers la version reviews:v1 et que cette version du service n'accède pas au service "ratings".

6. Patientez une à deux minutes, puis revenez au tableau de bord Service Mesh en cliquant sur le menu de navigation > Kubernetes Engine > Service Mesh > reviews > Infrastructure.

7. Sélectionnez AFFICHER LA CHRONOLOGIE, puis concentrez-vous sur les cinq dernières minutes de trafic représentées sur le graphique. Vous constaterez que le trafic n'est plus réparti de manière équitable, mais acheminé vers la charge de travail de la version 1 100 % du temps.

   

   Vous pouvez également voir la nouvelle distribution du trafic en consultant l'onglet Trafic ou la vue "Topologie". L'affichage des données prend toutefois une à deux minutes supplémentaires.

Cliquez sur Vérifier ma progression pour valider l'objectif. Appliquer des services virtuels

Tâche 7 : Acheminer le trafic vers une version spécifique d'un service selon l'identité de l'utilisateur

Dans cette tâche, vous modifiez la configuration du routage afin que tout le trafic d'un utilisateur spécifique soit acheminé vers une version spécifique d'un service. Dans ce cas, tout le trafic provenant de l'utilisateur Jason sera acheminé vers le service reviews:v2, la version qui inclut la fonction de note.

Remarque : Istio n'offre pas de fonctionnalité intégrée de reconnaissance de l'identité des utilisateurs. Cet exemple est possible, car le service "productpage" ajoute un en-tête personnalisé pour l'utilisateur final à toutes les requêtes HTTP sortantes destinées au service "reviews".

1. Examinez la configuration disponible sur GitHub. Cette configuration définit une ressource VirtualService.

2. Appliquez la configuration en exécutant la commande suivante dans Cloud Shell :

   wget https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/networking/virtual-service-reviews-test-v2.yaml sed -i 's#istio\.io/v1#istio\.io/v1alpha3#g' virtual-service-reviews-test-v2.yaml kubectl apply -f virtual-service-reviews-test-v2.yaml

   Résultat :

   virtualservice.networking.istio.io/reviews configured

3. Vérifiez que la règle a bien été créée :

   kubectl get virtualservice reviews

   Résultat :

   NAME GATEWAYS HOSTS AGE reviews ["reviews"] 35m

4. Testez la nouvelle configuration de routage à l'aide de l'UI de Bookinfo :

   • Accédez à nouveau à /productpage dans l'application Bookinfo.

   • Cette fois, cliquez sur Sign in (Se connecter), puis indiquez jason dans le champ User Name (Nom d'utilisateur), sans saisir de mot de passe.

   • Notez que l'UI affiche les étoiles du service "ratings".

   Vous pouvez vous déconnecter, et essayer de vous connecter en tant qu'autre utilisateur. Vous ne verrez plus d'étoiles avec les avis.

Pour mieux visualiser l'effet du nouveau routage du trafic, vous pouvez créer une charge en arrière-plan des requêtes authentifiées vers le service.

5. Démarrez une nouvelle session "siege", qui ne génère que 20 % du trafic de la première, mais dont toutes les requêtes sont authentifiées sous le nom de jason :

   curl -c cookies.txt -F "username=jason" -L -X \ POST http://$GATEWAY_URL/login cookie_info=$(grep -Eo "session.*" ./cookies.txt) cookie_name=$(echo $cookie_info | cut -d' ' -f1) cookie_value=$(echo $cookie_info | cut -d' ' -f2) siege -c 5 http://$GATEWAY_URL/productpage \ --header "Cookie: $cookie_name=$cookie_value"

6. Patientez une à deux minutes, puis actualisez la page montrant la télémétrie de l'infrastructure. Ajustez ensuite la chronologie pour afficher l'heure actuelle et examinez le tableau de bord Service Mesh. Vous constaterez qu'environ 85 % des requêtes effectuées au cours des dernières minutes sont transmises à la version 1, car elles ne sont pas authentifiées. Environ 15 % d'entre elles sont transmises à la version 2, car elles ont été authentifiées sous le nom de jason.

7. Dans Cloud Shell, annulez la session "siege" en appuyant sur Ctrl+C.

8. Terminez cet exercice en supprimant les services virtuels de l'application :

   kubectl delete -f virtual-service-all-v1.yaml

   Résultat :

   virtualservice.networking.istio.io "productpage" deleted virtualservice.networking.istio.io "reviews" deleted virtualservice.networking.istio.io "ratings" deleted virtualservice.networking.istio.io "details" deleted

9. Patientez une à deux minutes, puis actualisez le tableau de bord Service Mesh. Ajustez ensuite la chronologie pour afficher l'heure actuelle et vérifiez que le trafic est à nouveau réparti de manière équilibrée entre les versions.

   

Cliquez sur Vérifier ma progression pour valider l'objectif. Configuration de routage spécifique à l'utilisateur

Tâche 8 : Déplacer progressivement le trafic d'une version d'un microservice à une autre

Dans cette tâche, vous allez migrer progressivement le trafic d'une version d'un microservice à une autre. Cette approche vous permet par exemple de migrer le trafic d'une ancienne version vers une nouvelle.

Vous allez envoyer 50 % du trafic à "reviews:v1" et 50 % à "reviews:v3". Vous terminerez ensuite la migration en envoyant 100 % du trafic à "reviews:v3".

Dans Service Mesh, vous allez atteindre cet objectif en configurant une séquence de règles qui acheminent un pourcentage du trafic vers l'un ou l'autre de ces services.

1. Dans Cloud Shell, acheminez tout le trafic vers la version v1 de chaque service :

   kubectl apply -f virtual-service-all-v1.yaml

   Résultat :

   virtualservice.networking.istio.io/productpage created virtualservice.networking.istio.io/reviews created virtualservice.networking.istio.io/ratings created virtualservice.networking.istio.io/details created

2. Accédez de nouveau à /productpage dans l'application Bookinfo, puis vérifiez que vous ne voyez pas d'étoiles avec les avis. L'ensemble du trafic est acheminé vers la version v1 du backend.

3. Patientez une minute, puis actualisez le tableau de bord Service Mesh. Ajustez ensuite la chronologie pour afficher l'heure actuelle et vérifiez que tout le trafic a été acheminé vers la version v1 du backend.

4. Transférez 50 % du trafic de "reviews:v1" à "reviews:v3".

   wget https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/networking/virtual-service-reviews-50-v3.yaml sed -i 's#istio\.io/v1#istio\.io/v1alpha3#g' virtual-service-reviews-50-v3.yaml kubectl apply -f virtual-service-reviews-50-v3.yaml

   Résultat :

   virtualservice.networking.istio.io/reviews configured

5. Accédez à nouveau à /productpage dans l'application Bookinfo.

6. Actualisez la vue pour envoyer plusieurs requêtes.

   Vous constatez une répartition à peu près égale des avis sans étoiles de v1 et des avis avec des étoiles rouges de v3, la version qui accède au service "ratings".

7. Patientez une minute, puis actualisez la page. Ajustez ensuite la chronologie pour afficher l'heure actuelle et vérifiez dans le tableau de bord Service Mesh que le trafic vers le service "reviews" est acheminé à 50 % vers la v1 et à 50 % vers la v3.

   

8. Transférez les 50 % restants du trafic vers "reviews:v3".

9. Supposons que vous jugiez le service "reviews:v3" stable. Acheminez 100 % du trafic vers "reviews:v3" en appliquant ce service virtuel :

   wget https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/networking//virtual-service-reviews-v3.yaml sed -i 's#istio\.io/v1#istio\.io/v1alpha3#g' virtual-service-reviews-v3.yaml kubectl apply -f virtual-service-reviews-v3.yaml

   Résultat :

   virtualservice.networking.istio.io/reviews configured

10. Testez la nouvelle configuration de routage à l'aide de l'UI de Bookinfo.

11. Accédez à nouveau à /productpage dans l'application Bookinfo.

12. Actualisez la page /productpage. Les avis sur les livres continuent à s'afficher, avec des étoiles rouges pour chaque avis.

13. Patientez une minute, puis actualisez la page. Vérifiez ensuite dans le tableau de bord Service Mesh que tout le trafic vers le service "reviews" est acheminé vers la v3.

    

14. Terminez cet exercice en supprimant les services virtuels de l'application.

    kubectl delete -f virtual-service-all-v1.yaml

    Résultat :

    virtualservice.networking.istio.io "productpage" deleted virtualservice.networking.istio.io "reviews" deleted virtualservice.networking.istio.io "ratings" deleted virtualservice.networking.istio.io "details" deleted

Dans cette tâche, vous avez migré le trafic d'une ancienne version du service "reviews" vers une nouvelle version à l'aide de la fonctionnalité de routage pondéré de Service Mesh. Cette opération est très différente de la migration de versions à l'aide des fonctions de déploiement des plates-formes d'orchestration de conteneurs, qui utilisent le scaling d'instances afin de gérer le trafic.

Cliquez sur Vérifier ma progression pour valider l'objectif. Migrer le trafic de la v1 vers la v3

Tâche 9 : Ajouter des délais avant expiration pour éviter d'attendre indéfiniment les réponses du service

Le champ de délai avant expiration de la règle de routage permet de spécifier la durée de vie des requêtes HTTP. Par défaut, le délai avant expiration de la requête est désactivé, mais dans cette tâche, vous définissez le délai avant expiration du service "reviews" sur une seconde. Toutefois, pour observer son effet, vous devez ajouter un délai artificiel de deux secondes aux appels vers le service de note. Nous allons commencer par ajouter le délai.

1. Dans Cloud Shell, acheminez tout le trafic vers la version v1 de chaque service :

   kubectl apply -f virtual-service-all-v1.yaml

   Résultat :

   virtualservice.networking.istio.io/productpage created virtualservice.networking.istio.io/reviews created virtualservice.networking.istio.io/ratings created virtualservice.networking.istio.io/details created

2. Acheminez les requêtes vers la version v2 du service "reviews", c'est-à-dire une version qui appelle le service "ratings" :

   kubectl apply -f - <<EOF apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: reviews spec: hosts: - reviews http: - route: - destination: host: reviews subset: v2 EOF

3. Ajoutez un délai de deux secondes aux appels vers le service de note :

   kubectl apply -f - <<EOF apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: ratings spec: hosts: - ratings http: - fault: delay: percent: 100 fixedDelay: 2s route: - destination: host: ratings subset: v1 EOF

4. Ouvrez l'URL Bookinfo http://$GATEWAY_URL/productpage dans votre navigateur. L'application Bookinfo doit s'afficher normalement (avec des notes sous la forme d'étoiles), mais il existe un délai de deux secondes chaque fois que vous actualisez la page. Si l'application Bookinfo ne fonctionne pas normalement, définissez le délai sur une seconde, puis réessayez.

5. Accédez aux avis et métriques pour vérifier que la latence augmente à deux secondes. Si vous avez défini le délai sur une seconde, la latence doit augmenter à une seconde.

   

6. Ajoutez maintenant un délai avant expiration d'une demi-seconde pour les appels au service "reviews" :

   kubectl apply -f - <<EOF apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: reviews spec: hosts: - reviews http: - route: - destination: host: reviews subset: v2 timeout: 0.5s EOF

7. Actualisez la page Web Bookinfo.

Vous devriez à présent voir qu'elle s'affiche en une seconde environ au lieu de deux, et que les avis ne sont pas disponibles.

Remarque : Une seconde s'écoule avant l'obtention d'une réponse même si le délai avant expiration est défini sur une demi-seconde, car une nouvelle tentative est codée en dur dans le service "productpage". Celui-ci appelle donc le service "reviews" avec le délai avant expiration deux fois avant de renvoyer une réponse. Si vous souhaitez modifier le paramètre de nouvelle tentative, configurez la ressource VirtualService en exécutant la commande affichée ci-dessous. kubectl apply -f - <<EOF apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: productpage spec: hosts: - productpage http: - route: - destination: host: productpage subset: v1 retries: attempts: 1 perTryTimeout: 2s EOF

8. Terminez cet exercice en supprimant les services virtuels de l'application.

   kubectl delete -f virtual-service-all-v1.yaml

   Résultat :

   virtualservice.networking.istio.io "productpage" deleted virtualservice.networking.istio.io "reviews" deleted virtualservice.networking.istio.io "ratings" deleted virtualservice.networking.istio.io "details" deleted

Dans cette tâche, vous avez utilisé Istio afin de définir le délai avant expiration des requêtes sur une demi-seconde pour les appels effectués vers le microservice "reviews". Par défaut, le délai avant expiration des requêtes est désactivé. Comme le service "reviews" appelle ensuite le service "ratings" lors du traitement des requêtes, vous avez utilisé Istio pour injecter un délai de deux secondes dans les appels au service "ratings" afin que le service "reviews" prenne plus d'une demi-seconde à traiter la requête. Vous avez ainsi pu voir le délai avant expiration en action.

Vous avez remarqué qu'au lieu d'afficher des avis, la page produit de Bookinfo (qui appelle le service "reviews" pour remplir la page) affiche le message suivant : "Désolé, les avis sur le produit ne sont pas disponibles pour ce livre à l'heure actuelle." Cela est dû au fait que l'application a reçu un message d'erreur de délai avant expiration pour ce service.

Cliquez sur Vérifier ma progression pour valider l'objectif. Ajouter des délais avant expiration pour le service "ratings"

Tâche 10 : Ajouter des disjoncteurs pour améliorer la résilience des microservices

Dans cette tâche, vous allez apprendre à configurer une rupture de circuit pour les connexions, les requêtes et la détection d'anomalies.

La rupture de circuit est un modèle important pour la création d'applications de microservices résilientes. La rupture de circuit vous permet d'écrire des applications qui limitent l'impact des défaillances, des pics de latence et d'autres effets indésirables des particularités du réseau.

Dans cette tâche, vous allez configurer des règles de rupture de circuit, puis tester la configuration en déclenchant intentionnellement le disjoncteur.

1. Dans Cloud Shell, acheminez tout le trafic vers la version v1 de chaque service :

   kubectl apply -f virtual-service-all-v1.yaml

   Résultat :

   virtualservice.networking.istio.io/productpage created virtualservice.networking.istio.io/reviews created virtualservice.networking.istio.io/ratings created virtualservice.networking.istio.io/details created

2. Créez une règle de destination pour appliquer des paramètres de rupture de circuit lorsque le service "productpage" est appelé :

   kubectl apply -f - <<EOF apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: productpage spec: host: productpage subsets: - name: v1 labels: version: v1 trafficPolicy: connectionPool: tcp: maxConnections: 1 http: http1MaxPendingRequests: 1 maxRequestsPerConnection: 1 outlierDetection: consecutive5xxErrors: 1 interval: 1s baseEjectionTime: 3m maxEjectionPercent: 100 EOF

3. Dans Cloud Shell, accédez au premier onglet, puis appuyez sur Ctrl+C pour arrêter la session "siege".

4. Créez un client pour envoyer le trafic au service "productpage".

Le client est un client simple de test de charge appelé fortio. Fortio permet de contrôler le nombre de connexions, la simultanéité et les délais des appels HTTP sortants. Vous utiliserez ce client pour déclencher les règles de disjoncteur que vous avez définies dans la ressource DestinationRule :

kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.9/samples/httpbin/sample-client/fortio-deploy.yaml

5. Connectez-vous au pod client et utilisez l'outil Fortio pour appeler le service productpage. Utilisez curl pour indiquer que vous ne souhaitez effectuer qu'un seul appel :

   export FORTIO_POD=$(kubectl get pods -lapp=fortio -o 'jsonpath={.items[0].metadata.name}') kubectl exec "$FORTIO_POD" -c fortio -- /usr/bin/fortio curl -quiet http://${GATEWAY_URL}/productpage

6. Appelez le service avec deux connexions simultanées (-c 2), puis envoyez 20 requêtes (-n 20) :

   kubectl exec "$FORTIO_POD" -c fortio -- /usr/bin/fortio load -c 2 -qps 0 -n 20 -loglevel Warning http://${GATEWAY_URL}/productpage

   Il est intéressant de constater que presque toutes les requêtes ont abouti. Voilà qui est surprenant, sachant que maxConnections: 1 (nombre max. de connexions = 1) et que http1MaxPendingRequests: 1 (nombre max. de requêtes HTTP en attente = 1). Ces règles indiquent que si vous avez plusieurs connexions et requêtes simultanées, vous devriez constater des échecs lorsque le proxy Istio ouvre le circuit pour d'autres requêtes et connexions.

   Toutefois, vous pouvez voir que le proxy Istio autorise une certaine marge de manœuvre :

   Code 200 : 17 (85.0 %) Code 503 : 3 (15.0 %)

7. Définissez le nombre de connexions simultanées sur trois :

   kubectl exec "$FORTIO_POD" -c fortio -- /usr/bin/fortio load -c 3 -qps 0 -n 30 -loglevel Warning http://${GATEWAY_URL}/productpage

   Vous constatez à présent la rupture de circuit prévue. Seulement 36,7 % des requêtes ont abouti. Les autres ont été interceptées par la rupture de circuit :

   Code 200 : 11 (36.7 %) Code 503 : 19 (63.3 %)

Cliquez sur Vérifier ma progression pour valider l'objectif. Ajouter des disjoncteurs

Récapitulatif

Dans cet atelier, vous avez découvert de nombreuses façons de gérer et de router le trafic à différentes fins. Vous avez également vu comment ajuster le trafic et afficher les modifications. Vous avez notamment eu un aperçu de la couche 7 (la couche application et de routage), qui examine les en-têtes de requête.

Étapes suivantes

• En savoir plus sur la gestion de trafic avec Istio
• En savoir plus sur les déploiements Canary avec Istio

Terminer l'atelier

Une fois l'atelier terminé, cliquez sur Terminer l'atelier. Google Skills supprime les ressources que vous avez utilisées, puis efface le compte.

Si vous le souhaitez, vous pouvez noter l'atelier. Sélectionnez un nombre d'étoiles, saisissez un commentaire, puis cliquez sur Envoyer.

Voici à quoi correspond le nombre d'étoiles que vous pouvez attribuer à un atelier :

• 1 étoile = très insatisfait(e)
• 2 étoiles = insatisfait(e)
• 3 étoiles = ni insatisfait(e), ni satisfait(e)
• 4 étoiles = satisfait(e)
• 5 étoiles = très satisfait(e)

Si vous ne souhaitez pas donner votre avis, vous pouvez fermer la boîte de dialogue.

Pour soumettre des commentaires, suggestions ou corrections, veuillez accéder à l'onglet Assistance.

Copyright 2026 Google LLC Tous droits réservés. Google et le logo Google sont des marques de Google LLC. Tous les autres noms de société et de produit peuvent être des marques des sociétés auxquelles ils sont associés.