Présentation

Dans cet atelier, vous allez apprendre à installer Cloud Service Mesh (CSM) sur Google Kubernetes Engine. Cloud Service Mesh est un service géré basé sur Istio, le maillage de services Open Source le plus utilisé.

Un maillage de services vous offre un framework permettant de connecter, de sécuriser et de gérer des microservices. Il fournit pour Kubernetes une couche de mise en réseau dotée de fonctionnalités avancées d'équilibrage de charge, d'authentification mutuelle entre services et de surveillance, sans qu'il soit nécessaire de modifier le code des services.

Cloud Service Mesh dispose d'une suite de fonctionnalités et d'outils supplémentaires qui vous permettent d'observer et de gérer des services sécurisés et fiables de manière unifiée. Dans cet atelier, vous allez également apprendre à utiliser certaines de ces fonctionnalités :

• Les métriques et journaux de service pour le trafic HTTP(S) dans le cluster GKE de votre maillage sont automatiquement ingérés dans Google Cloud.
• Les tableaux de bord de services préconfigurés vous fournissent les informations nécessaires pour comprendre vos services.
• La télémétrie détaillée vous permet d'explorer vos métriques et journaux, en filtrant et en segmentant vos données en fonction d'une grande variété d'attributs.
• Les relations de service à service vous permettent de savoir rapidement qui se connecte à quel service et d'identifier les dépendances entre services.
• Les objectifs de niveau de service (SLO) fournissent des insights sur l'état de vos services. Vous pouvez facilement définir un SLO et une alerte en fonction de vos propres normes d'état de service.

Cloud Service Mesh est le moyen le plus simple et le plus complet pour mettre en œuvre un maillage de services basé sur Istio sur vos clusters GKE Enterprise.

Objectifs

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

• Installer Cloud Service Mesh, en activant le traçage et en le configurant de façon à utiliser Cloud Trace comme backend
• Déployer Bookinfo, une application multiservice compatible avec Istio
• Activer l'accès externe à l'aide d'une passerelle d'entrée Istio
• Utiliser l'application Bookinfo
• Évaluer les performances du service à l'aide des fonctionnalités Cloud Trace dans Google Cloud
• Créer et surveiller des objectifs de niveau de service (SLO)
• Utiliser le tableau de bord Cloud Service Mesh pour comprendre les performances du service

Préparation

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 à Qwiklabs 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 pouvez pas le mettre en 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 à Google Cloud Console.

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 appliqué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 du projet GCP. Cliquez ensuite sur Ouvrir pour ouvrir le projet sélectionné.

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 :

Résultat :

Exemple de résultat :

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

Résultat :

Exemple de résultat :

Tâche 1 : Installer Cloud Service Mesh en installant le traçage

Un cluster Google Kubernetes Engine (GKE) nommé gke a déjà été créé et enregistré. Vous allez installer Cloud Service Mesh sur ce cluster et remplacer la configuration standard afin d'activer les composants de traçage facultatifs.

Configurer l'accès au cluster pour kubectl et vérifier le cluster

Pour définir les variables d'environnement à utiliser dans les scripts, exécutez les commandes suivantes dans Cloud Shell :

1. Définissez la variable d'environnement "Nom".

   CLUSTER_NAME=gke

2. Définissez les variables d'environnement "Zone" et "Région".

   CLUSTER_ZONE={{{ project_0.default_zone| "Zone ajoutée au début de l'atelier" }}} CLUSTER_REGION={{{ project_0.default_region| "Région ajoutée au début de l'atelier" }}}

3. Définissez la variable d'environnement "ID du projet".

   PROJECT_ID={{{ project_0.project_id | "PROJECT ID ajouté au début de l'atelier" }}}

4. Définissez la variable d'environnement "Numéro de projet".

   PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} \ --format="value(projectNumber)")

5. Définissez la variable d'environnement "ID du projet de parc".

   FLEET_PROJECT_ID="${PROJECT_ID}"

6. Définissez la variable d'environnement "IDNS".

   IDNS="${PROJECT_ID}.svc.id.goog"

7. Définissez le répertoire de sortie.

   DIR_PATH=.

8. Vérifiez que les variables d'environnement sont correctement définies.

   printf '\nCLUSTER_NAME:'$CLUSTER_NAME'\nCLUSTER_ZONE:'$CLUSTER_ZONE'\nPROJECT_ID:'$PROJECT_ID'\nPROJECT_NUMBER:'$PROJECT_NUMBER'\nFLEET PROJECT_ID:'$FLEET_PROJECT_ID'\nIDNS:'$IDNS'\nDIR_PATH:'$DIR_PATH'\n'

   Résultat :

   CLUSTER_NAME:gke CLUSTER_ZONE:{{{ project_0.default_zone| "Zone" }}} PROJECT_ID:{{{ project_0.project_id | "PROJECT ID" }}} PROJECT_NUMBER:946429310725 FLEET PROJECT_ID:{{{ project_0.project_id | "PROJECT ID" }}} IDNS:{{{ project_0.project_id | "PROJECT ID" }}}.svc.id.goog DIR_PATH:.

9. Configurez kubectl pour gérer votre cluster GKE :

   gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $CLUSTER_ZONE --project $PROJECT_ID

10. Examinez votre configuration de kubectl :

    kubectl config view

Résultat :

11. Vérifiez que votre cluster est en cours d'exécution :

Résultat :

Activer GKE Enterprise

12. Activez GKE Enterprise à partir de la ligne de commande. L'API Fleet (GKE Hub) est également activée automatiquement.

13. Enregistrez le cluster GKE appelé gke dans le parc du projet.

14. Vérifiez que le cluster a bien été enregistré dans votre parc.

Installez Cloud Service Mesh

15. Activez Cloud Service Mesh sur le projet de parc.

16. Activez la gestion automatique du plan de contrôle Cloud Service Mesh.

17. Vérifiez que le plan de contrôle est géré.

Attendez que l'état de controlPlaneManagement passe de PROVISIONING à REVISION_READY. Cela peut prendre quelques minutes.

Résultat :

18. Activez Cloud Service Mesh pour envoyer des données de télémétrie à Cloud Trace.

19. Vérifiez que le mappage de configuration a été activé : kubectl get configmap

Résultat :

Félicitations !

Vous disposez maintenant d'un cluster GKE sur lequel Cloud Service Mesh est installé. Les métriques Kubernetes sont enregistrées dans Cloud Monitoring, les journaux sont enregistrés dans Cloud Logging et les informations de traçage distribué sont envoyées à Cloud Trace.

Tâche 2 : Installer l'application de démonstration des microservices sur le cluster

Online Boutique est une application de démonstration de microservices cloud native. L'application de microservices Online Boutique comprend 10 niveaux. Cette application est un outil Web d'e-commerce permettant aux utilisateurs de parcourir des articles, de les ajouter à un panier et de les acheter.

Google s'en sert pour démontrer l'utilisation de technologies telles que Kubernetes/GKE, Istio/ASM, la suite Google Operations, gRPC et OpenCensus. Cette application fonctionne sur tous les clusters Kubernetes (comme un cluster local) et sur Google Kubernetes Engine. Facile à déployer, elle nécessite peu de configuration, voire aucune.

Pour en savoir plus sur l'application, consultez le dépôt GitHub.

Configurer le plan de données du maillage

1. Activez l'injection side-car Istio :

   kubectl label namespace default istio.io/rev- istio-injection=enabled --overwrite

   Résultat :

   namespace/default labeled

2. Pour permettre à Google de gérer votre plan de données de sorte que les proxys side-car soient automatiquement mis à jour, annotez l'espace de noms :

   kubectl annotate --overwrite namespace default \ mesh.cloud.google.com/proxy='{"managed":"true"}'

   Résultat :

   namespace/default annotated

Installer l'application Online Boutique sur le cluster GKE

1. Pour déployer l'application, procédez comme suit :

   kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/microservices-demo/master/release/kubernetes-manifests.yaml kubectl patch deployments/productcatalogservice -p '{"spec":{"template":{"metadata":{"labels":{"version":"v1"}}}}}'

2. Pour pouvoir accéder à l'application depuis l'extérieur du cluster, installez la passerelle d'entrée :

   git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages kubectl apply -f anthos-service-mesh-packages/samples/gateways/istio-ingressgateway

3. Installez les définitions de ressources personnalisées requises :

   kubectl apply -k "github.com/kubernetes-sigs/gateway-api/config/crd/experimental?ref=v0.6.0" kubectl kustomize "https://github.com/GoogleCloudPlatform/gke-networking-recipes.git/gateway-api/config/mesh/crd" | kubectl apply -f -

4. Configurez la passerelle :

   kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/microservices-demo/master/release/istio-manifests.yaml

5. Revenez à Kubernetes, cliquez sur Charges de travail, puis sous Mise en réseau, cliquez sur les pages Passerelles, services et entrées, et vérifiez que les nouveaux déploiements et services ont été créés sur le cluster GKE.

   Remarque : Vous pouvez filtrer ces pages par cluster, type d'objet et espace de noms pour faciliter l'analyse des informations présentées.

6. Prenez quelques instants pour examiner l'application de démonstration à l'aide de la console et de l'UI.

   Remarque : Lorsque les charges de travail affichent l'état OK, utilisez l'adresse IP associée au service frontend-external (pour l'un des clusters) pour effectuer l'une des opérations suivantes :
   • Consultez la page Services et entrées dans la console.
   • Explorez le cluster à l'aide de Cloud Shell.

7. Affichez le déploiement à l'aide de Cloud Shell.

   kubectl get deployments

   Résultat :

   NAME READY UP-TO-DATE AVAILABLE AGE adservice 1/1 1 1 2m39s cartservice 1/1 1 1 2m41s checkoutservice 1/1 1 1 2m44s currencyservice 1/1 1 1 2m40s emailservice 1/1 1 1 2m45s frontend 1/1 1 1 2m43s istio-ingressgateway 3/3 3 3 2m24s loadgenerator 1/1 1 1 2m41s paymentservice 1/1 1 1 2m42s productcatalogservice 1/1 1 1 2m42s recommendationservice 1/1 1 1 2m43s redis-cart 1/1 1 1 2m39s shippingservice 1/1 1 1 2m40s

8. Affichez les services à l'aide de Cloud Shell.

   kubectl get services

   Résultat :

   NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE adservice ClusterIP 10.28.7.144 9555/TCP 7m37s cartservice ClusterIP 10.28.12.9 7070/TCP 7m40s checkoutservice ClusterIP 10.28.15.239 5050/TCP 7m42s currencyservice ClusterIP 10.28.14.145 7000/TCP 7m39s emailservice ClusterIP 10.28.11.181 5000/TCP 7m43s frontend ClusterIP 10.28.1.40 80/TCP 7m41s frontend-external LoadBalancer 10.28.15.84 34.66.85.60 80:31445/TCP 7m41s istio-ingressgateway LoadBalancer 10.28.0.95 34.68.255.184 15021:30153/TCP,80:31266/TCP,443:30286/TCP 7m22s kubernetes ClusterIP 10.28.0.1 443/TCP 62m paymentservice ClusterIP 10.28.1.138 50051/TCP 7m41s productcatalogservice ClusterIP 10.28.8.22 3550/TCP 7m40s recommendationservice ClusterIP 10.28.0.104 8080/TCP 7m42s redis-cart ClusterIP 10.28.5.71 6379/TCP 7m38s shippingservice ClusterIP 10.28.5.69 50051/TCP 7m39s

9. Ouvrez un nouvel onglet et saisissez l'adresse IP du service frontend-external.

10. Parcourez plusieurs pages pour vous faire une idée de l'application.

Tâche 3 : Examiner les fonctionnalités de la suite Google Cloud Operations

Lorsque vous installez un cluster GKE ou Anthos, vous pouvez activer la collecte de journaux et de métriques de cluster, ainsi que leur transfert à Cloud Logging et Cloud Monitoring. Vous bénéficiez ainsi d'une visibilité sur le cluster, les nœuds, les pods et même les conteneurs du cluster. Toutefois, GKE et Anthos ne surveillent pas la communication entre les microservices.

Avec Cloud Service Mesh, puisque chaque requête passe par un proxy Envoy, des informations de télémétrie sur les microservices peuvent être collectées et inspectées. Les extensions de proxy Envoy envoient ensuite ces données de télémétrie à Google Cloud, où vous pouvez les inspecter. Utilisez les tableaux de bord Cloud Trace pour examiner les requêtes et leur latence, ainsi que pour obtenir le détail de tous les services impliqués dans une requête.

1. Dans la console Google Cloud, accédez au menu de navigation, puis cliquez sur Trace.

   Un graphique de trace indique les requêtes de service effectuées dans l'application de démonstration.

2. Cliquez sur un point qui apparaît plus haut sur le graphique (correspondant à une durée de requête globale plus élevée).

• Combien de temps la requête a-t-elle duré ?
• Quand cette requête a-t-elle eu lieu ?
• Quel service a été appelé ?
• Quels autres services ont été appelés lors de l'exécution de cette requête ?
• Qu'est-ce qui a pris le plus de temps lors du traitement de cette requête ?

Consultez la documentation de Cloud Trace pour en savoir plus sur les informations de traçage.

Tâche 4 : Déployer une version Canary à latence élevée

Dans cette tâche, vous allez déployer une nouvelle version d'un service présentant un problème qui entraîne une latence élevée. Dans les tâches suivantes, vous allez utiliser les outils d'observabilité pour diagnostiquer et résoudre le problème.

1. Dans Cloud Shell, clonez le dépôt contenant les fichiers de configuration dont vous avez besoin pour cette partie de l'atelier :

   git clone https://github.com/GoogleCloudPlatform/istio-samples.git \ ~/istio-samples

2. Créez la règle de destination sur le cluster gke :

   kubectl apply -f ~/istio-samples/istio-canary-gke/canary/destinationrule.yaml

3. Créez le catalogue de produits sur le cluster gke :

   kubectl apply -f ~/istio-samples/istio-canary-gke/canary/productcatalog-v2.yaml

4. Créez une répartition du trafic sur le cluster gke :

   kubectl apply -f ~/istio-samples/istio-canary-gke/canary/vs-split-traffic.yaml Remarque : Vous créez les éléments suivants :
   • Une règle DestinationRule pour définir le routage des requêtes entre les versions du service
   • Un nouveau déploiement du service de catalogue de produits présentant une latence élevée
   • Un service VirtualService pour router 75 % du trafic du catalogue de produits vers v1, et 25 % vers v2
   Vous pouvez ouvrir chacun des fichiers de configuration dans l'éditeur Cloud Shell pour mieux comprendre la définition de chaque nouvelle ressource.

Tâche 5 : Définir votre objectif de niveau de service

Lorsque vous n'utilisez pas Cloud Service Mesh, vous pouvez définir des SLO à l'aide de l'API Service Monitoring. Lorsque vous utilisez Cloud Service Mesh, comme avec le cluster gke, vous pouvez définir et surveiller des SLO via le tableau de bord Cloud Service Mesh.

1. Dans le menu de navigation de la console Google Cloud, cliquez sur Kubernetes Engine pour ouvrir le tableau de bord GKE.

   Notez qu'un cluster est enregistré dans le parc.

2. Dans le panneau latéral, sous Fonctionnalités, cliquez sur Service Mesh pour accéder au tableau de bord Cloud Service Mesh.

   Un résumé des performances de service comprenant des informations sur le SLO s'affiche. Vous allez à présent définir un nouveau SLO pour le service de catalogue de produits.

3. Dans la liste des Services, cliquez sur productcatalogservice.

4. Dans le volet de navigation, cliquez sur État.

5. Cliquez sur + Créer un SLO.

6. Dans le menu coulissant Définissez votre SLI, sélectionnez Latence comme métrique.

7. Sélectionnez la méthode d'évaluation Basée sur les requêtes.

8. Cliquez sur Continuer.

9. Fixez le Seuil de latence à 1 000 et cliquez sur Continuer.

10. Pour le Type de période, choisissez Agenda.

11. Définissez la Durée de la période sur Jour calendaire.

    Remarque : Une disponibilité de 99 % sur une même journée est différente d'une disponibilité de 99 % sur un mois. Le premier SLO ne vous permet pas plus de 14 minutes consécutives de temps d'arrêt (24 h * 1 %), tandis que le second SLO permet un temps d'arrêt pouvant représenter jusqu'à 7 heures consécutives environ (30 jours * 1 %).

12. Définissez l'Objectif de performances sur 99,5 %.

    Le graphique Preview (Aperçu) montre où se situe votre objectif par rapport aux données historiques réelles.

13. Cliquez sur Continuer.

14. Examinez le nom à afficher : 99,5 % - Latence - Jour calendaire.

    Vous pouvez l'ajuster si nécessaire.

    Le document JSON généré automatiquement s'affiche également. Vous pouvez aussi utiliser les API pour automatiser la création de SLO à l'avenir.

15. Pour créer le SLO, cliquez sur +Créer un SLO.

Tâche 6 : Diagnostiquer le problème

Rechercher l'origine du problème à l'aide des métriques de service

1. Cliquez sur l'entrée de votre SLO dans la liste des SLO.

   Une vue détaillée s'affiche. Votre SLO indique probablement que vous avez déjà dépassé la marge d'erreur. Si ce n'est pas le cas, attendez trois à cinq minutes avant d'actualiser la page. Vous finirez par épuiser votre marge d'erreur, car un trop grand nombre des requêtes adressées à ce service atteindront le nouveau backend, lequel présente une latence élevée.

2. Dans le volet de navigation, cliquez sur Métriques.

   Faites défiler la page jusqu'à la section Latence de la vue Métriques. Notez que la latence du service a augmenté il y a quelques minutes, à peu près au moment du déploiement de la version Canary du service.

3. Dans le menu déroulant Répartir par, sélectionnez Service source.

   Quels pods affichent une latence élevée et entraînent l'échec général du SLO ?

4. Pour revenir à la page Service Mesh, dans le volet de navigation, cliquez sur Service Mesh.

   Un SLO apparaît comme dépassant la marge d'erreur. Un avertissement figure à côté du service concerné dans la liste des Services.

   Remarque : Vous n'avez défini qu'un seul SLO pour un seul service. Dans un environnement de production réel, il est probable que vous disposiez de plusieurs SLO pour chaque service.
   En outre, vous n'avez défini aucune règle d'alerte pour votre SLO. Il est préférable que Cloud Monitoring déclenche une alerte si vous dépassez la marge d'erreur plus rapidement que prévu.

Utiliser Cloud Trace pour mieux comprendre l'origine du retard

1. Dans le menu de navigation de la console Google Cloud, cliquez sur Trace > Explorateur Trace.

2. Cliquez sur un point positionné à environ 3 000 ms. Celui-ci doit représenter l'une des requêtes adressées au service de catalogue de produits.

   Notez que tout le temps semble consacré au service de catalogue lui-même. Bien que des appels soient adressés à d'autres services, ceux-ci paraissent tous renvoyer des résultats très rapidement. En revanche, un élément du service de catalogue de produits semble prendre beaucoup de temps.

   Remarque : Cloud Service Mesh collecte automatiquement des informations sur les appels réseau dans le maillage et fournit des données de traçage qui indiquent le temps consacré à ces appels. Cette méthode est utile et ne requiert aucun effort supplémentaire de la part du développeur.
   Cependant, le temps consacré à la charge de travail (dans le cas présent, le pod du service de catalogue de produits) n'est pas instrumenté directement par Istio. Si nécessaire, le développeur peut ajouter une logique d'instrumentation dans le service lui-même pour obtenir ce niveau de détail.

Tâche 7 : Effectuer un rollback de la version et vérifier que la situation s'améliore

1. Dans Cloud Shell, supprimez la version Canary de la règle de destination :

   kubectl delete -f ~/istio-samples/istio-canary-gke/canary/destinationrule.yaml

2. Dans Cloud Shell, supprimez la version Canary du catalogue de produits :

   kubectl delete -f ~/istio-samples/istio-canary-gke/canary/productcatalog-v2.yaml

3. Dans Cloud Shell, supprimez la version Canary de répartition du trafic :

   kubectl delete -f ~/istio-samples/istio-canary-gke/canary/vs-split-traffic.yaml

4. Dans le menu de navigation de la console Google Cloud, cliquez sur Anthos > Service Mesh.

5. Cliquez sur productcatalogservice, puis dans le volet de navigation, cliquez sur État.

   Notez le pourcentage de conformité actuel.

6. Cliquez sur Métriques.

   Sur le graphique affichant la latence, les séries de latence indiquent toutes une baisse correspondant au moment où vous avez effectué un rollback de la version incorrecte de la charge de travail.

7. Revenez à la page État.

8. Comparez la métrique de conformité actuelle avec celle que vous avez relevée précédemment. La nouvelle métrique devrait avoir une valeur plus élevée, étant donné que vous ne voyez plus les requêtes à latence élevée.

Tâche 8 : Visualiser votre maillage avec le tableau de bord Cloud Service Mesh

1. Dans le menu de navigation, cliquez sur Kubernetes Engine > Service Mesh.

2. Affichez la topologie sur la droite.

   Un graphique représentant votre maillage de services s'affiche.

   

   Si vous ne voyez pas de graphique de topologie complet comme celui-ci, il est possible que toutes les données de topologie n'aient pas été collectées. L'actualisation de ces données dans le graphique peut prendre plus de 10 minutes. Vous pouvez passer à la section suivante et revenir plus tard pour consulter le graphique.

3. Cliquez sur le nœud de la charge de travail d'interface et notez les services appelés par cette charge de travail.

   

Prenez quelques minutes pour en apprendre davantage sur l'architecture de l'application et mieux la comprendre. Vous pouvez réorganiser les nœuds, afficher le détail des charges de travail pour visualiser les déploiements et les pods, modifier les périodes, etc.

Félicitations ! Vous avez utilisé les outils de la suite Operations de Google Cloud pour évaluer et résoudre les problèmes, et améliorer les performances du service sur votre cluster GKE Enterprise géré.

Récapitulatif

Dans cet atelier, vous avez appris à effectuer des opérations de journalisation, de surveillance et de traçage à l'aide de la suite Google Cloud Operations.

Terminer l'atelier

Une fois l'atelier terminé, cliquez sur Terminer l'atelier. Google Cloud Skills Boost 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.

Le nombre d'étoiles correspond à votre degré de satisfaction :

• 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.