Installer Anthos Service Mesh

Cette page explique comment exécuter le script permettant d'installer la version 1.10.6 d'Anthos Service Mesh sur un cluster GKE pour un maillage contenant un ou plusieurs clusters qui se trouvent dans le même projet Google Cloud.

Pour les installations dans lesquelles les clusters se trouvent dans des projets différents, consultez le guide multiprojet pour GKE.

Ce guide explique comment installer Anthos Service Mesh ou comment réinstaller la même version avec une configuration différente. Toutefois, la réinstallation avec différentes configurations, mises à niveau et migrations à partir d'Istio nécessite une planification supplémentaire. Pour en savoir plus, consultez les pages suivantes :

• Mettre à niveau Anthos Service Mesh
• Migrer depuis Istio
• Réinstaller la même version

Avant de commencer

Avant de commencer l'installation, vérifiez que vous avez effectué les opérations suivantes :

• Examiner les exigences
• Choisir une autorité de certification (CA)
• Enregistrer le cluster
• Installer les outils nécessaires
• Télécharger le script

Le script nécessite que vous disposiez des autorisations requises, ou que vous incluiez les options --enable_all ou --enable_gcp_iam_roles afin de lui permettre d'activer automatiquement l'autorisation. De même, pour autoriser le script à activer les API requises et à mettre à jour votre cluster, spécifiez l'option --enable_all ou des options d'activation plus précises.

Installer Anthos Service Mesh

1. Définissez les options permettant d'exécuter le script. Vous incluez toujours les options suivantes : --project_id, --cluster_name, --cluster_location et --mode install. Si vous souhaitez utiliser Istio CA (anciennement appelé Citadel) comme autorité de certification, vous devez spécifier l'option --ca et d'autres options, comme décrit dans la section Installation avec Istio CA Pour obtenir une description complète des arguments du script, consultez la section Options.

2. Pour terminer la configuration d'Anthos Service Mesh, vous devez activer l'injection side-car automatique et déployer ou redéployer des charges de travail.

La section suivante fournit des exemples typiques d'exécution du script. Consultez la barre de navigation située à droite pour obtenir la liste des exemples.

Examples

Cette section présente des exemples d'exécution du script pour une installation, ainsi que des arguments supplémentaires qui peuvent vous être utiles. Consultez la barre de navigation située à droite pour obtenir la liste des exemples.

Valider uniquement

L'exemple suivant montre comment exécuter le script avec l'option --only_validate. Avec cette option, le script n'apporte aucune modification à votre projet ou cluster et il n'installe pas Anthos Service Mesh. Lorsque vous spécifiez l'option --only_validate, le script échoue si vous incluez l'une des options --enable_*.

Le script valide les points suivants :

• Votre environnement dispose des outils nécessaires.
• Vous disposez de l'autorisation requise sur le projet spécifié.
• Le cluster répond aux exigences minimales.
• Toutes les API Google requises sont activées dans le projet.

Par défaut, le script télécharge et extrait le fichier d'installation et télécharge le package de configuration asm de GitHub dans un répertoire temporaire. Avant de quitter, le script génère un message indiquant le nom du répertoire temporaire. Vous pouvez spécifier un répertoire pour les téléchargements à l'aide de l'option --output_dir DIR_PATH. L'option --output_dir vous permet d'utiliser l'outil de ligne de commande istioctl si vous en avez besoin. De plus, les fichiers de configuration permettant d'activer les fonctionnalités facultatives sont inclus dans le répertoire asm/istio/options.

Exécutez la commande suivante pour valider votre configuration et télécharger le fichier d'installation et le package asm dans le répertoire OUTPUT_DIR :

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --output_dir DIR_PATH \
  --only_validate

En cas de réussite, le script génère ce qui suit :

./install_asm \
install_asm: Setting up necessary files...
install_asm: Creating temp directory...
install_asm: Generating a new kubeconfig...
install_asm: Checking installation tool dependencies...
install_asm: Downloading ASM..
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 57.0M  100 57.0M    0     0  30.6M      0  0:00:01  0:00:01 --:--:-- 30.6M
install_asm: Downloading ASM kpt package...
fetching package /asm from https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages to asm
install_asm: Checking for project PROJECT_ID...
install_asm: Confirming cluster information...
install_asm: Confirming node pool requirements...
install_asm: Fetching/writing GCP credentials to kubeconfig file...
Fetching cluster endpoint and auth data.
kubeconfig entry generated for cluster-1.
install_asm: Checking Istio installations...
install_asm: Checking required APIs...
install_asm: Successfully validated all requirements to install ASM from this computer.

Si l'un des tests échoue à la validation, le script génère un message d'erreur. Par exemple, si toutes les API Google requises ne sont pas activées pour votre projet, vous obtenez l'erreur suivante :

ERROR: One or more APIs are not enabled. Please enable them and retry, or run
the script with the '--enable_gcp_apis' flag to allow the script to enable them
on your behalf.

Si vous recevez un message d'erreur indiquant que vous devez exécuter le script avec une option d'activation, vous disposez des options suivantes :

• Incluez l'option spécifique du message d'erreur ou l'option --enable_all lors de l'exécution du script pour effectuer l'installation réelle (c'est-à-dire sans --only_validate).

• Si vous préférez, vous pouvez vous-même mettre à jour votre projet et votre cluster avant d'exécuter le script, comme décrit dans la section Configurer l'installation d'Anthos Service Mesh sur GKE.

Notez que install_asm n'autorise aucune option d'activation avec --only_validate.

Installation avec les fonctionnalités par défaut

La commande suivante exécute le script pour une nouvelle installation avec les fonctionnalités par défaut.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --ca mesh_ca \
  --output_dir DIR_PATH \
  --enable_registration \
  --enable_all

• --ca mesh_ca : Bien que l'autorité de certification Mesh soit définie par défaut pour les nouvelles installations, --ca mesh_ca est inclus dans la ligne de commande pour plus de clarté. Si vous ne spécifiez pas --ca, install_asm active l'autorité de certification Mesh.

• --output_dir DIR_PATH Incluez cette option pour spécifier un répertoire dans lequel le script télécharge le package asm et le fichier d'installation d'Anthos Service Mesh, qui contient le fichier istioctl, des exemples et des fichiers manifestes. Sinon, le script télécharge le package asm et le fichier d'installation dans un répertoire temporaire.

• --enable_registration Cette option permet au script d'enregistrer le cluster dans le projet hébergeant ce cluster. Si vous n'incluez pas cette option, suivez les étapes décrites dans la section Enregistrer un cluster pour enregistrer manuellement votre cluster.

• --enable_all permet au script d'activer les API Google requises, de définir les autorisations Identity and Access Management, et d'effectuer les mises à jour requises de votre cluster, ce qui inclut l'activation de GKE Workload Identity. Si vous préférez ne pas autoriser install_asm à répondre à ces exigences de projet et de cluster, consultez la page Configurer l'installation d'Anthos Service Mesh sur GKE.

Remarque : Si vous n'avez pas activé l'GKE Workload Identity, l'installation échoue et affiche l'erreur. une "erreur d'appartenance au cluster". Si l'installation échoue pour cette raison, réenregistrez le cluster sur la ligne de commande à l'aide de la commande suivante : gcloud container hub memberships register --enable-workload-identity

Installation avec Istio CA

Cette section explique comment effectuer les opérations suivantes :

• Générer des certificats et des clés qu'Anthos Service Mesh utilise pour enregistrer vos charges de travail
• Exécuter le script permettant d'effectuer une installation et activer Istio CA en tant qu'autorité de certification

Nous vous recommandons d'utiliser Istio CA uniquement lorsque vous avez besoin d'une autorité de certification personnalisée.

Pour une sécurité optimale, nous vous recommandons vivement de conserver une autorité de certification racine hors connexion et d'utiliser les autorités de certification subordonnées pour émettre des autorités de certification pour chaque cluster. Pour en savoir plus, consultez la section Utiliser des certificats CA. Dans cette configuration, toutes les charges de travail du maillage de services utilisent la même autorité de certification racine. Chaque autorité de certification Anthos Service Mesh utilise une clé et un certificat de signature CA intermédiaires, signés par l'autorité de certification racine. Lorsque plusieurs autorités de certification existent dans un maillage, cela établit une hiérarchie de confiance entre les autorités de certification. Vous pouvez répéter ces étapes pour provisionner les certificats et les clés d'un nombre illimité d'autorités de certification.

Important : Ces étapes permettent de créer des certificats et des clés à l'aide d'une commande make que nous ne fournissons qu'à titre indicatif. Pour une sécurité optimale, utilisez un ordinateur et des outils de production sécurisés hors connexion. Par exemple, utilisez HashiCorp Vault pour générer la clé de signature CA en toute sécurité et la protéger.

1. Créez un répertoire pour les certificats et les clés :

   mkdir -p certs && \
   pushd certs

2. Générez un certificat et une clé racine :

   make -f ../tools/certs/Makefile.selfsigned.mk root-ca
   

   Les fichiers suivants sont alors générés :

   • root-cert.pem : certificat racine
   • root-key.pem : clé racine
   • root-ca.conf : configuration nécessaire pour qu'openssl génère le certificat racine
   • root-cert.csr : demande CSR du certificat racine

3. Générez un certificat et une clé intermédiaires :

   make -f ../tools/certs/Makefile.selfsigned.mk cluster1-cacerts

   Cette opération génère les fichiers suivants dans un répertoire nommé cluster1 :

   • ca-cert.pem : certificats intermédiaires
   • ca-key.pem : clé intermédiaire
   • cert-chain.pem : chaîne de certificats utilisée par istiod
   • root-cert.pem : certificat racine
   Remarque : Vous pouvez remplacer cluster1 par un autre nom. Par exemple, make mycluster-certs crée un répertoire nommé mycluster.

   Si vous effectuez ces étapes à l'aide d'un ordinateur hors connexion, copiez le répertoire généré sur l'ordinateur sur lequel vous souhaitez exécuter le script.

4. Exécutez le script et ajoutez les fichiers que vous avez générés précédemment pour les certificats et la clé.

   ./install_asm \
     --project_id PROJECT_ID \
     --cluster_name CLUSTER_NAME \
     --cluster_location CLUSTER_LOCATION \
     --mode install \
     --ca citadel \
     --ca_cert FILE_PATH \
     --ca_key FILE_PATH \
     --root_cert FILE_PATH \
     --cert_chain FILE_PATH \
     --output_dir DIR_PATH \
     --enable_registration \
     --enable_all

Installation avec un fichier de superposition

Un fichier de superposition est un fichier YAML contenant une ressource personnalisée IstioOperator que vous transmettez à install_asm pour configurer le plan de contrôle. Vous pouvez ignorer la configuration par défaut du plan de contrôle et activer une fonctionnalité facultative en transmettant le fichier YAML à install_asm. Vous pouvez effectuer plusieurs couches de superpositions. Chaque fichier de superposition remplace la configuration dans les couches précédentes.

Si vous spécifiez plusieurs ressources personnalisées dans un fichier YAML, install_asm divise ce fichier en plusieurs fichiers YAML temporaires, un pour chaque ressource personnalisée. Le script divise les ressources personnalisées en fichiers distincts, car istioctl install applique uniquement la première ressource personnalisée dans un fichier YAML qui en contient plusieurs.

L'exemple suivant effectue une installation et inclut un fichier de superposition pour personnaliser la configuration du plan de contrôle. Dans la commande suivante, remplacez OVERLAY_FILE par le nom du fichier YAML.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --ca mesh_ca \
  --output_dir DIR_PATH \
  --enable_registration \
  --enable_all \
  --custom_overlay OVERLAY_FILE

Installation avec une option

L'exemple suivant effectue une installation et inclut le fichier egressgateways.yaml du package asm, ce qui active une passerelle de sortie. Notez que vous n'incluez pas l'extension .yaml. Le script extrait le fichier à votre place afin que vous n'ayez pas à télécharger le package asm au préalable.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --ca mesh_ca \
  --output_dir DIR_PATH \
  --enable_registration \
  --enable_all \
  --option egressgateways

Vous pouvez utiliser --option pour activer une fonctionnalité facultative. Si vous devez modifier des fichiers dans le répertoire asm/istio/options du package asm, téléchargez le package asm, apportez vos modifications et incluez le fichier à l'aide de --custom_overlay.

Pour télécharger le package asm dans le répertoire de travail actuel afin de pouvoir modifier les fichiers :

kpt pkg get \
https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.10-asm asm

Si vous avez exécuté l'exemple Only validate (Valider uniquement) avec l'option --output_dir, les fichiers de configuration se trouvent dans le répertoire de sortie spécifié sous asm/istio/options.

Activer Mesh CA avec le pool d'identités de charge de travail de la Fleet

Preview — Mesh CA with the fleet workload identity pool

Cette fonctionnalité est soumise aux "Conditions des offres de pré-DG" dans la section "Conditions d'utilisation générales" des Conditions spécifiques au service. Les fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

La version Bêta de Mesh CA avec le pool d'identités de charge de travail de la Fleet est limitée aux nouvelles installations d'Anthos Service Mesh sur GKE. Les mises à niveau et les migrations ne sont pas disponibles dans la version Bêta.

Cet exemple montre comment activer Mesh CA pour utiliser le pool d'identité de charge de travail de la Fleet. Mesh CA avec le pool d'identités de charge de travail vous permet de joindre des clusters dans des projets Google Cloud distincts au sein d'un même domaine d'approbation.

Pour activer Mesh CA avec le pool d'identités de charge de travail de la Fleet, procédez comme suit :

Si vous n'avez pas encore enregistré votre cluster, veillez à inclure l'option --enable_registration ou l'option --enable_all pour permettre au script d'enregistrer votre cluster au projet dans le projet qui l'héberge.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --enable_all \
  --option hub-meshca

Cette commande exécute le script pour une nouvelle installation, configure votre projet et votre cluster avec les options requises par Anthos Service Mesh, enregistre le cluster auprès du projet qui l'héberge et configure Mesh CA pour utiliser le pool d'identités de charge de travail de la Fleet.

Remarque : Si vous utilisez asmcli pour installer Anthos Service Mesh, vous n'avez pas besoin de spécifier l'option hub-meshca. Lorsque vous exécutez asmcli install, asmcli permet automatiquement à l'autorité de certification Mesh d'utiliser le pool d'identités de charge de travail du parc.

Déployer et redéployer des charges de travail

Anthos Service Mesh utilise des proxys side-car pour améliorer la sécurité, la fiabilité et l'observabilité du réseau. Avec Anthos Service Mesh, ces fonctions sont extraites du conteneur principal de l'application et mises en œuvre dans un proxy commun hors processus fourni par un conteneur séparé dans le même pod.

L'installation n'est terminée qu'une fois que vous avez activé l'injection automatique du proxy side-car (injection automatique) et que vous avez redémarré les pods de toutes les charges de travail exécutées sur votre cluster avant d'avoir installé Anthos Service Mesh.

Pour activer l'injection automatique, vous devez étiqueter vos espaces de noms avec le même libellé de révision que vous avez défini sur istiod lors de l'installation d'Anthos Service Mesh. Le libellé de révision est utilisé par le webhook d'injecteur side-car pour associer les side-cars injectés à une révision istiod particulière. Après avoir ajouté le libellé, tous les pods existants dans l'espace de noms doivent être redémarrés pour que les side-cars soient injectés.

Avant de déployer de nouvelles charges de travail dans un espace de noms que vous venez de créer, veillez à configurer l'injection automatique afin qu'Anthos Service Mesh puisse surveiller et sécuriser le trafic.

Pour activer l'injection automatique, procédez comme suit :

1. Exécutez la commande suivante pour localiser le libellé de révision sur istiod :

   kubectl -n istio-system get pods -l app=istiod --show-labels
   

   La sortie ressemble à ceci :

   NAME                                READY   STATUS    RESTARTS   AGE   LABELS
   istiod-asm-1106-2-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-1106-2,istio=istiod,pod-template-hash=5788d57586
   istiod-asm-1106-2-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-1106-2,istio=istiod,pod-template-hash=5788d57586

   Dans le résultat, sous la colonne LABELS, notez la valeur du libellé de révision istiod, qui suit le préfixe istio.io/rev=. Dans cet exemple, la valeur est asm-1106-2.

2. Appliquez le libellé de révision et supprimez le libellé istio-injection s'il existe. Dans la commande suivante, NAMESPACE est le nom de l'espace de noms dans lequel vous souhaitez activer l'injection automatique, et REVISION est le libellé de révision noté à l'étape précédente.

   kubectl label namespace NAMESPACE istio-injection- istio.io/rev=REVISION --overwrite
   

   Vous pouvez ignorer le message "istio-injection not found" dans le résultat. Cela signifie que l'espace de noms ne portait pas précédemment le libellé istio-injection, auquel on s'attend dans de nouvelles installations d'Anthos Service Mesh ou de nouveaux déploiements. Étant donné que l'injection automatique échoue si un espace de noms possède à la fois le istio-injection et le libellé de révision, toutes les commandes kubectl label de la documentation Anthos Service Mesh incluent la suppression du libellé istio-injection.

3. Si les charges de travail étaient en cours d'exécution sur votre cluster avant d'installer Anthos Service Mesh, redémarrez les pods pour déclencher une réinjection.

   La méthode de redémarrage des pods dépend de votre application et de l'environnement dans lequel se trouve le cluster. Par exemple, dans votre environnement de préproduction, vous pouvez simplement supprimer tous les pods, ce qui entraîne leur redémarrage. Toutefois, dans votre environnement de production, vous pouvez peut-être mettre en œuvre un déploiement bleu-vert afin de pouvoir redémarrer des pods en toute sécurité pour éviter l'interruption du trafic.

   Vous pouvez exécuter kubectl pour effectuer un redémarrage progressif :

   kubectl rollout restart deployment -n NAMESPACE
   

4. Vérifiez que vos pods sont configurés pour pointer vers la nouvelle version de istiod.

   kubectl get pods -n NAMESPACE -l istio.io/rev=REVISION
   

Afficher les tableaux de bord Anthos Service Mesh

Une fois que les charges de travail sont déployées sur votre cluster et que les proxys side-car ont été injectés, vous pouvez explorer les pages Anthos Service Mesh de la console Google Cloud pour consulter toutes les fonctionnalités d'observabilité offertes par Anthos Service Mesh. Notez qu'il faut environ une à deux minutes pour que les données de télémétrie soient affichées dans la console Google Cloud après le déploiement des charges de travail.

L'accès à Anthos Service Mesh dans la console Google Cloud est contrôlé par IAM (Identity and Access Management). Pour permettre l'accès aux pages Anthos Service Mesh, un propriétaire de projet doit accorder aux utilisateurs le rôle éditeur ou lecteur de projet, ou les rôles plus restrictifs décrits dans la section Contrôler l'accès à Anthos Service Mesh dans la console Google Cloud.

1. Dans Google Cloud Console, accédez à Anthos Service Mesh.

   Accéder à Anthos Service Mesh

2. Sélectionnez le projet Google Cloud dans la liste déroulante de la barre de menu.

3. Si vous avez plusieurs maillages de services, sélectionnez le maillage dans la liste déroulante Maillage de services.

Pour en savoir plus, consultez la page Explorer Anthos Service Mesh dans la console Google Cloud.

Outre les pages Anthos Service Mesh, les métriques liées à vos services (telles que le nombre de requêtes reçues par un service particulier) sont envoyées à Cloud Monitoring, où elles apparaissent dans l'explorateur de métriques.

Pour afficher les métriques, procédez comme suit :

1. Dans Google Cloud Console, accédez à la page Monitoring :

   Accéder à Monitoring

2. Sélectionnez Ressources > Explorateur de métriques.

Pour obtenir la liste complète des métriques, consultez la section Métriques Istio dans la documentation Cloud Monitoring.

Étapes suivantes

• Déployez l'exemple d'application Boutique en ligne.
• Configurer un maillage multicluster