Ce guide explique comment mettre à niveau Anthos Service Mesh de la version 1.5.4+ or 1.6.4+ vers la version 1.6.14 sur GKE. Pour mettre à niveau Anthos Service Mesh 1.4.5 ou version ultérieure, vous devez d'abord passer à Anthos Service Mesh 1.5. Il n'est pas possible de mettre à niveau Anthos Service Mesh 1.4 directement vers 1.6.
Lors de la mise à niveau, nous vous recommandons d'effectuer une mise à niveau du plan de contrôle double (également appelée mise à niveau Canary), où les versions nouvelle et précédente du plan de contrôle sont exécutées lorsque vous testez la nouvelle version avec un faible pourcentage de vos charges de travail. Cette approche est plus sûre qu'une mise à niveau sur place, où la nouvelle version du plan de contrôle remplace la version précédente. Notez que le service istio-ingressgateway est mis à niveau. Vous devez donc prévoir certaines interruptions sur votre cluster.Le redéploiement des composants du plan de contrôle d'Anthos Service Mesh prend environ 5 à 10 minutes. En outre, vous devez injecter de nouveaux proxys side-car dans toutes vos charges de travail afin qu'elles soient mises à jour avec la version actuelle d'Anthos Service Mesh. Le temps nécessaire à la mise à jour des proxys side-car dépend de nombreux facteurs, tels que le nombre de pods, le nombre de nœuds, les paramètres de scaling du déploiement, les budgets d'interruption de pod et d'autres paramètres de configuration. Une estimation approximative du temps nécessaire à la mise à jour des proxys side-car est de 100 pods par minute.
Préparer la mise à niveau
Cette section décrit les étapes à suivre pour préparer la mise à niveau d'Anthos Service Mesh.
Consultez la page Fonctionnalités compatibles et ce guide pour vous familiariser avec les fonctionnalités et le processus de mise à niveau.
Si vous avez activé des fonctionnalités facultatives lors de l'installation de la version précédente d'Anthos Service Mesh, vous devez activer les mêmes fonctionnalités lors de la mise à niveau. Vous activez des fonctionnalités facultatives en ajoutant des options
--set values
ou en spécifiant l'option-f
avec un fichier YAML lorsque vous exécutez la commandeistioctl install
.Si vous installez Anthos Service Mesh sur un cluster privé, vous devez ouvrir le port 15017 dans le pare-feu pour que le webhook utilisé avec l'injection side-car automatique fonctionne correctement. Pour en savoir plus, consultez la page Ouvrir un port sur un cluster privé.
Si vous effectuez une mise à niveau à partir de Anthos Service Mesh 1.5, procédez comme suit au cas où vous auriez besoin d'effectuer un rollback :
Créez un répertoire appelé
asm-1-5
.Téléchargez le fichier d'installation 1.5 dans le répertoire
asm-1-5
.Extrayez le contenu du fichier vers le répertoire
asm-1-5
.Assurez-vous de vous trouver dans le répertoire racine d'installation d'Anthos Service Mesh 1.5.
Téléchargez le package
kpt
1.5 et configurez le fichieristio-operator.yaml
de version 1.5.
Configurer votre environnement
Pour les installations sur Google Kubernetes Engine, vous pouvez suivre les guides d'installation via Cloud Shell, une interface de ligne de commande intégrée au navigateur vers vos ressources Google Cloud, ou votre propre ordinateur fonctionnant sous Linux ou macOS.
Option A : Utiliser Cloud Shell
Cloud Shell provisionne une machine virtuelle (VM) g1-small Compute Engine exécutant un système d'exploitation Linux basé sur Debian. Les avantages liés à l'utilisation de Cloud Shell sont les suivants :
Il comprend, entre autres, les outils de ligne de commande
gcloud
,kubectl
ethelm
.Votre répertoire Cloud Shell $HOME dispose d'un espace de stockage persistant de 5 Go.
Nous vous proposons plusieurs éditeurs de texte :
Éditeur de code, auquel vous accédez en cliquant sur en haut de la fenêtre Cloud Shell.
Emacs, Vim ou Nano, auxquels vous accédez depuis la ligne de commande dans Cloud Shell.
Pour utiliser Cloud Shell, procédez comme suit :
- Accédez à Google Cloud Console.
- Sélectionnez votre projet Google Cloud.
Cliquez sur le bouton Activer Cloud Shell en haut de la fenêtre de la console Google Cloud.
Une session Cloud Shell s'ouvre dans un nouveau cadre en bas de la console Google Cloud et affiche une invite de ligne de commande.
Mettez à jour les composants :
gcloud components update
La commande renvoie un résultat semblable à celui-ci :
ERROR: (gcloud.components.update) You cannot perform this action because the gcloud CLI component manager is disabled for this installation. You can run the following command to achieve the same result for this installation: sudo apt-get update && sudo apt-get --only-upgrade install ...
Copiez la commande longue, puis collez-la pour mettre à jour les composants.
Assurez-vous que Git se trouve dans votre chemin pour que
kpt
puisse le trouver.
Option B : Utiliser des outils de ligne de commande localement
Sur votre ordinateur local, installez et initialisez gcloud CLI.
Si gcloud CLI est déjà installé :
Authentifiez-vous en utilisant gcloud CLI :
gcloud auth login
Mettez à jour les composants :
gcloud components update
Installez
kubectl
:gcloud components install kubectl
Installez
kpt
:gcloud components install kpt
Assurez-vous que Git se trouve dans votre chemin pour que
kpt
puisse le trouver.
Définir des variables d'environnement
Obtenez l'ID du projet dans lequel le cluster a été créé et le numéro du projet hôte du parc.
gcloud
Exécutez la commande suivante :
gcloud projects list
Console
Accédez à la page Tableau de bord de la console Google Cloud.
Cliquez sur la liste déroulante de sélection du projet située en haut de la page. Sélectionnez votre projet dans la fenêtre Sélectionnez une organisation qui vous est présentée.
L'ID du projet est affiché sur la fiche Informations sur le projet du tableau de bord du projet.
Créez une variable d'environnement pour l'ID du projet dans lequel le cluster a été créé:
export PROJECT_ID=YOUR_PROJECT_ID
Créez une variable d'environnement pour le numéro de projet du projet hôte du parc.
export FLEET_PROJECT_NUMBER=YOUR_FLEET_PROJECT_NUMBER
Créez les variables d'environnement suivantes :
Définissez le nom du cluster :
export CLUSTER_NAME=YOUR_CLUSTER_NAME
Définissez le paramètre
CLUSTER_LOCATION
sur la zone ou la région de votre cluster :export CLUSTER_LOCATION=YOUR_ZONE_OR_REGION
Modifier l'ID de maillage sur le cluster (facultatif)
Si votre maillage de services contient ou contiendra plusieurs clusters faisant partie de différents projets, tous les clusters doivent avoir le même ID de maillage, qui est basé sur le numéro du projet hôte du parc. L'ID de maillage défini sur votre cluster doit correspondre à celui que vous configurez pour Anthos Service Mesh.
Si vous ne disposez que d'un seul cluster ou si votre maillage de services contient ou contiendra plusieurs clusters appartenant au même projet, ignorez les étapes suivantes et passez à la section Définir des identifiants et des autorisations.
Pour définir le nouveau libellé d'ID de maillage sur le cluster, procédez comme suit :
Créez une variable d'environnement pour l'ID du maillage:
export MESH_ID="proj-${FLEET_PROJECT_NUMBER}"
Si votre cluster contient des libellés existants que vous souhaitez conserver, vous devez les inclure lors de l'ajout du libellé
mesh_id
.Pour savoir si votre cluster possède des libellés existants, procédez comme suit :
gcloud container clusters describe ${CLUSTER_NAME} \ --project ${PROJECT_ID}
Recherchez le champ
resourceLabels
dans le résultat. Chaque libellé est stocké sur une ligne distincte du champresourceLabels
, par exemple :resourceLabels: csm: '' env: dev release: stable
Vous n'avez pas besoin de conserver le
mesh_id
existant. Remplacez-le par le nouveau libellémesh_id
.Pour plus de commodité, vous pouvez ajouter les libellés à une variable d'environnement. Dans la commande suivante, remplacez
YOUR_EXISTING_LABELS
par la liste des libellés existants de votre cluster (séparés par une virgule) au formatKEY=VALUE
, par exemple :env=dev,release=stable
export EXISTING_LABELS="YOUR_EXISTING_LABELS"
Définissez le libellé
mesh_id
:Si votre cluster contient des libellés existants que vous souhaitez conserver, mettez à jour le cluster avec le libellé
mesh_id
et les libellés existants :gcloud container clusters update ${CLUSTER_NAME} \ --project ${PROJECT_ID} --update-labels=mesh_id=${MESH_ID},${EXISTING_LABELS}
Si votre cluster ne comporte aucun libellé existant, mettez à jour le cluster avec uniquement le nouveau libellé
mesh_id
:gcloud container clusters update ${CLUSTER_NAME} \ --project=${PROJECT_ID} \ --update-labels=mesh_id=${MESH_ID}
Définir des identifiants et des autorisations
Obtenez des identifiants d'authentification pour interagir avec le cluster :
gcloud container clusters get-credentials ${CLUSTER_NAME} \ --project=${PROJECT_ID}
Accordez des autorisations d'administrateur de cluster à l'utilisateur actuel. Vous avez besoin de ces autorisations pour créer les règles de contrôle d'accès basé sur les rôles (RBAC) nécessaires pour Anthos Service Mesh :
kubectl create clusterrolebinding cluster-admin-binding \ --clusterrole=cluster-admin \ --user="$(gcloud config get-value core/account)"
Si l'erreur "cluster-admin-binding" already exists
s'affiche, vous pouvez l'ignorer en toute sécurité et poursuivre avec le cluster-admin-binding existant.
Télécharger le fichier d'installation
-
Téléchargez le fichier d'installation d'Anthos Service Mesh dans votre répertoire de travail actuel :
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.6.14-asm.2-linux-amd64.tar.gz
-
Téléchargez le fichier de signature et utilisez
openssl
pour valider la signature :curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.6.14-asm.2-linux-amd64.tar.gz.1.sig openssl dgst -verify /dev/stdin -signature istio-1.6.14-asm.2-linux-amd64.tar.gz.1.sig istio-1.6.14-asm.2-linux-amd64.tar.gz <<'EOF' -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw== -----END PUBLIC KEY----- EOF
La sortie attendue est
Verified OK
. -
Extrayez le contenu du fichier vers n’importe quel emplacement de votre système de fichiers. Par exemple, pour extraire le contenu vers le répertoire de travail actuel :
tar xzf istio-1.6.14-asm.2-linux-amd64.tar.gz
La commande crée un répertoire d'installation dans votre répertoire de travail actuel, nommé
istio-1.6.14-asm.2
, et qui contient les éléments suivants:- Des exemples d'applications dans le répertoire
samples
- L'outil de ligne de commande
istioctl
que vous utilisez pour installer Anthos Service Mesh se trouve dans le répertoirebin
. - Les profils de configuration d'Anthos Service Mesh qui se trouvent dans le répertoire
manifests/profiles
- Des exemples d'applications dans le répertoire
-
Téléchargez le fichier d'installation d'Anthos Service Mesh dans votre répertoire de travail actuel :
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.6.14-asm.2-osx.tar.gz
-
Téléchargez le fichier de signature et utilisez
openssl
pour valider la signature :curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.6.14-asm.2-osx.tar.gz.1.sig openssl dgst -sha256 -verify /dev/stdin -signature istio-1.6.14-asm.2-osx.tar.gz.1.sig istio-1.6.14-asm.2-osx.tar.gz <<'EOF' -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw== -----END PUBLIC KEY----- EOF
La sortie attendue est
Verified OK
. -
Extrayez le contenu du fichier vers n’importe quel emplacement de votre système de fichiers. Par exemple, pour extraire le contenu vers le répertoire de travail actuel :
tar xzf istio-1.6.14-asm.2-osx.tar.gz
La commande crée un répertoire d'installation dans votre répertoire de travail actuel, nommé
istio-1.6.14-asm.2
, et qui contient les éléments suivants:- Des exemples d'applications dans le répertoire
samples
- L'outil de ligne de commande
istioctl
que vous utilisez pour installer Anthos Service Mesh se trouve dans le répertoirebin
. - Les profils de configuration d'Anthos Service Mesh qui se trouvent dans le répertoire
manifests/profiles
- Des exemples d'applications dans le répertoire
-
Téléchargez le fichier d'installation d'Anthos Service Mesh dans votre répertoire de travail actuel :
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.6.14-asm.2-win.zip
-
Téléchargez le fichier de signature et utilisez
openssl
pour valider la signature :curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.6.14-asm.2-win.zip.1.sig openssl dgst -verify - -signature istio-1.6.14-asm.2-win.zip.1.sig istio-1.6.14-asm.2-win.zip <<'EOF' -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw== -----END PUBLIC KEY----- EOF
La sortie attendue est
Verified OK
. -
Extrayez le contenu du fichier vers n’importe quel emplacement de votre système de fichiers. Par exemple, pour extraire le contenu vers le répertoire de travail actuel :
tar xzf istio-1.6.14-asm.2-win.zip
La commande crée un répertoire d'installation dans votre répertoire de travail actuel, nommé
istio-1.6.14-asm.2
, et qui contient les éléments suivants:- Des exemples d'applications dans le répertoire
samples
- L'outil de ligne de commande
istioctl
que vous utilisez pour installer Anthos Service Mesh se trouve dans le répertoirebin
. - Les profils de configuration d'Anthos Service Mesh qui se trouvent dans le répertoire
manifests/profiles
- Des exemples d'applications dans le répertoire
-
Assurez-vous d'être dans le répertoire racine de l'installation Anthos Service Mesh.
cd istio-1.6.14-asm.2
-
Pour plus de commodité, ajoutez les outils du répertoire
/bin
à votre variable PATH :export PATH=$PWD/bin:$PATH
Linux
macOS
Windows
Préparer les fichiers de configuration des ressources
Lorsque vous exécutez la commande istioctl install
, vous spécifiez -f istio-operator.yaml
sur la ligne de commande. Ce fichier contient des informations sur le projet et le cluster requis par Anthos Service Mesh. Vous devez télécharger un package contenant istio-operator.yaml
et d'autres fichiers de configuration des ressources afin de pouvoir définir les informations sur le projet et le cluster.
Pour commencer, choisissez un package à télécharger en fonction de l'autorité de certification que vous souhaitez utiliser :
asm
: thumb_up_alt Ce package active Mesh CA, que nous recommandons pour les nouvelles installations.asm-citadel
: vous pouvez éventuellement activer Citadel en tant qu'autorité de certification. Avant de choisir ce package, consultez la page Choisir une autorité de certification pour plus d'informations.
Pour préparer les fichiers de configuration des ressources, procédez comme suit :
Créez un répertoire pour les fichiers de configuration des ressources du package Anthos Service Mesh. Nous vous recommandons d'utiliser le nom du cluster comme nom de répertoire.
Accédez au répertoire dans lequel vous souhaitez télécharger le package Anthos Service Mesh.
Téléchargez le package que vous souhaitez utiliser en fonction de l'autorité de certification :
Mesh CA
Téléchargez le package
asm
, qui active Mesh CA :kpt pkg get \ https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.6-asm asm
Citadel
Téléchargez le package
asm-citadel
, qui active Citadel en tant qu'autorité de certification :kpt pkg get \ https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm-citadel@release-1.6-asm asm
Définissez l'ID du projet dans lequel le cluster a été créé :
kpt cfg set asm gcloud.core.project ${PROJECT_ID}
Définissez le numéro de projet du projet hôte du parc :
kpt cfg set asm gcloud.project.environProjectNumber ${FLEET_PROJECT_NUMBER}
Définissez le nom du cluster :
kpt cfg set asm gcloud.container.cluster ${CLUSTER_NAME}
Définissez la zone ou la région par défaut :
kpt cfg set asm gcloud.compute.location ${CLUSTER_LOCATION}
Définissez le profil de configuration que vous souhaitez utiliser :
Si tous vos clusters se trouvent dans le même projet, définissez le profil
asm-gcp
:kpt cfg set asm anthos.servicemesh.profile asm-gcp
Si votre maillage de services contient ou contiendra plusieurs clusters se trouvant dans des projets différents, définissez le profil
asm-gcp-multiproject
(version bêta) :kpt cfg set asm anthos.servicemesh.profile asm-gcp-multiproject
Si vous avez défini le profil
asm-gcp-multiproject
et téléchargé le packageasm
qui active Mesh CA, vous devez configurer les alias de domaine de confiance pour les autres projets qui formeront le maillage de services multicluster/multiprojet. Sinon, ignorez cette étape.Obtenez l'ID de projet de tous les clusters qui se trouveront dans le maillage multicluster/multiprojet.
Pour l'ID de projet de chaque cluster, définissez les alias de domaine de confiance. Par exemple, si vous avez des clusters dans trois projets, exécutez la commande suivante en remplaçant
PROJECT_ID_1
,PROJECT_ID_2
etPROJECT_ID_3
par l'ID de projet de chaque cluster.kpt cfg set asm anthos.servicemesh.trustDomainAliases PROJECT_ID_1.svc.id.goog PROJECT_ID_2.svc.id.goog PROJECT_ID_3.svc.id.goog
Lorsque vous configurez les clusters dans les autres projets, vous pouvez exécuter la même commande.
Les alias de domaine de confiance permettent à Mesh CA d'authentifier les charges de travail sur les clusters d'autres projets. En plus de définir les alias de domaine de confiance, vous devez activer l'équilibrage de charge interclusters après avoir installé Anthos Service Mesh.
Affichez les valeurs des setters
kpt
:kpt cfg list-setters asm
Dans le résultat de la commande, vérifiez que les valeurs des setters suivantes sont correctes :
- gcloud.compute.location
- gcloud.container.cluster
- gcloud.core.project
- gcloud.project.environProjectNumber
Mettre à niveau Anthos Service Mesh
Pour installer une nouvelle version d'Anthos Service Mesh, nous vous recommandons de suivre le processus de mise à niveau du plan de contrôle double (appelé mise à niveau Canary dans la documentation d'Istio). Avec une mise à niveau du plan de contrôle double, vous installez une nouvelle version du plan de contrôle à côté du plan de contrôle existant. Lors de l'installation de la nouvelle version, vous incluez le libellé revision
qui identifie la version du nouveau plan de contrôle. Chaque révision est une mise en œuvre complète du plan de contrôle d'Anthos Service Mesh avec ses propres déploiement et service.
Vous effectuez ensuite une migration vers la nouvelle version en définissant le même libellé revision
sur vos charges de travail de sorte qu'il pointe vers le nouveau plan de contrôle et en effectuant un redémarrage progressif pour réinjecter les proxys avec la nouvelle version d'Anthos Service Mesh. Avec cette approche, vous pouvez surveiller l'effet de la mise à niveau sur un petit pourcentage de vos charges de travail. Après avoir testé votre application, vous pouvez migrer tout le trafic vers la nouvelle version. Cette approche est beaucoup plus sûre qu'une mise à niveau sur place, où un nouveau plan de contrôle remplace la version précédente.
Mettre à jour le plan de contrôle
Exécutez la commande suivante pour déployer le nouveau plan de contrôle à l'aide du profil de configuration que vous avez défini dans le fichier istio-operator.yaml
. Si vous souhaitez activer une fonctionnalité facultative compatible, incluez -f
et le nom du fichier YAML dans la ligne de commande suivante. Pour plus d'informations, consultez la page Activer les fonctionnalités facultatives.
istioctl install \ -f asm/cluster/istio-operator.yaml \ --set revision=asm-1614-2
L'argument --set revision
ajoute un libellé istio.io/rev
à Istiod. Après avoir exécuté la commande, deux déploiements de plan de contrôle et des services s'exécutent côte à côte :
kubectl get pods -n istio-system
Exemple de résultat :
NAME READY STATUS RESTARTS AGE istio-ingressgateway-c56675fcd-86zdn 1/1 Running 0 2m9s istio-ingressgateway-c56675fcd-vn4nv 1/1 Running 0 2m21s istiod-asm-1614-2-6d5cfd4b89-xztlr 1/1 Running 0 3m44s istiod-fb7f746f4-wcntn 1/1 Running 0 50m
Redéployer des charges de travail
L'installation de la nouvelle révision n'a aucune incidence sur les proxys side-car existants. Pour les mettre à niveau, vous devez les configurer de sorte qu'ils pointent vers le nouveau plan de contrôle. Cette opération est contrôlée lors de l'injection side-car en fonction du libellé d'espace de noms istio.io/rev
.
Mettez à jour les charges de travail à injecter avec la nouvelle version d'Anthos Service Mesh :
kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-1614-2 --overwrite
Le libellé
istio-injection
doit être supprimé, car il est prioritaire sur le libelléistio.io/rev
.Redémarrez les pods pour déclencher la réinjection :
kubectl rollout restart deployment -n NAMESPACE
Vérifiez que les pods sont configurés de sorte qu'ils pointent vers le plan de contrôle
istiod-asm-1614-2
:kubectl get pods -n NAMESPACE -l istio.io/rev=asm-1614-2
Testez votre application pour vérifier que les charges de travail fonctionnent correctement.
Si vous avez des charges de travail dans d'autres espaces de noms, répétez les étapes précédentes pour chaque espace de noms.
Si vous êtes sûr que votre application fonctionne comme prévu, passez à la section Terminer la mise à niveau. Sinon, procédez comme suit pour effectuer un rollback vers la version précédente :
Mettez à jour les charges de travail à injecter avec la version précédente du plan de contrôle :
kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite
Redémarrez les pods pour déclencher une réinjection afin que les proxys aient la version précédente :
kubectl rollout restart deployment -n NAMESPACE
Effectuer un rollback des composants du plan de contrôle :
Revenir à la version 1.6 précédente
Redéployez la version précédente du fichier
istio-ingressgateway
:kubectl -n istio-system rollout undo deploy istio-ingressgateway
Supprimez le nouveau plan de contrôle :
kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-asm-1614-2 -n istio-system --ignore-not-found=true
Rollback vers la version 1.5
Accédez au répertoire dans lequel vous avez téléchargé le fichier d'installation 1.5 d'Anthos Service Mesh.
Réinstallez la version précédente d'Anthos Service Mesh. Dans la commande suivante, si vous avez activé les fonctionnalités facultatives, veillez à inclure les options
--set values
applicables ou l'option-f
avec le nom du fichier YAML.bin/istioctl install \ -f asm/cluster/istio-operator.yaml
Terminer la mise à niveau
Si vous êtes sûr que votre application fonctionne comme prévu, procédez comme suit pour terminer la mise à niveau :
Supprimez l'ancien plan de contrôle :
kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true
Exécutez la commande suivante pour déployer le contrôleur de service canonique :
kubectl apply -f asm/canonical-service/controller.yaml
La commande déploie le contrôleur de service canonique sur votre cluster. Le contrôleur de service canonique regroupe les charges de travail appartenant au même service logique. Il est nécessaire de débloquer les fonctionnalités supplémentaires du tableau de bord des services dans la console Google Cloud. Pour en savoir plus, consultez la page Activer et désactiver le contrôleur de service canonique.