Installer Anthos Service Mesh sur GKE

Ce guide explique comment installer, migrer ou mettre à niveau vers la version 1.7.8 du service Anthos Service Mesh pour un maillage contenant un ou plusieurs clusters GKE appartenant au même projet. Vous utilisez un script fourni par Google, qui configure votre projet et votre cluster, puis installe Anthos Service Mesh.

Vous pouvez utiliser ce guide et le script pour les cas d'utilisation suivants :

  • Nouvelles installations d'Anthos Service Mesh.

  • Mise à niveau depuis Anthos Service Mesh 1.6 ou une version de correctif 1.7. Les mises à niveau à partir de versions antérieures ne sont pas acceptées.

  • Migration depuis Open Source Istio 1.6 ou 1.7 vers Anthos Service Mesh. La migration depuis une version antérieure d'Istio n'est pas acceptée.

  • Migration depuis la version 1.6 du module complémentaire Istio sur GKE vers Anthos Service Mesh. Avant de pouvoir migrer vers Anthos Service Mesh, vous devez passer à Istio 1.6 avec l'opérateur. Pour obtenir les étapes de migration complètes à partir du module complémentaire, reportez-vous à la section Migrer vers Anthos Service Mesh dans la documentation Istio sur GKE.

Pour un maillage multi-cluster dans lequel les clusters se trouvent dans différents projets, consultez la page Installation et migration de plusieurs clusters/projets pour GKE.

Avant de commencer

Ce guide suppose que vous disposez des éléments suivants :

Si vous effectuez une migration depuis Istio, veillez à consulter la page Préparer la migration depuis Istio.

Différences entre Anthos et Anthos Service Mesh

  • Si vous êtes abonné à GKE Enterprise, veillez à activer l'API GKE Enterprise.

    Activer l'API

  • Si vous n'êtes pas abonné à GKE Enterprise, vous pouvez toujours installer Anthos Service Mesh, mais certains éléments et fonctionnalités de l'interface utilisateur de la console Google Cloud ne sont disponibles que pour les abonnés GKE Enterprise. Pour en savoir plus sur les fonctionnalités disponibles pour les abonnés et les non-abonnés, consultez la section Différences entre les interfaces utilisateur GKE Enterprise et Anthos Service Mesh. Pour en savoir plus sur la tarification d'Anthos Service Mesh pour les non-abonnés, consultez la page Tarifs.

Le script active toutes les autres API Google requises à votre place.

Conditions requises

  • Votre cluster GKE doit répondre aux exigences suivantes :

    • Type de machine comportant au moins quatre processeurs virtuels, par exemple e2-standard-4. Si le type de machine de votre cluster ne comporte pas au moins quatre processeurs virtuels, modifiez le type de machine comme décrit dans la section Migrer des charges de travail vers différents types de machines.

    • Le nombre minimal de nœuds dépend du type de machine. Anthos Service Mesh nécessite au moins huit processeurs virtuels. Si le type de machine comporte quatre processeurs virtuels, votre cluster doit comporter au moins deux nœuds. Si le type de machine comporte huit processeurs virtuels, le cluster n'a besoin que d'un nœud. Si vous devez ajouter des nœuds, consultez la page Redimensionner un cluster.

    • Le script active Workload Identity sur votre cluster. Workload Identity est la méthode recommandée pour appeler les API Google. L'activation de Workload Identity modifie la manière dont les appels de vos charges de travail vers les API Google sont sécurisés, comme décrit dans la section Limites de Workload Identity.

    • Nous vous recommandons d'inscrire le cluster dans une version disponible, mais cela n'est pas obligatoire. Nous vous recommandons de vous inscrire à la version disponible standard, car d'autres versions peuvent être basées sur une version de GKE non compatible avec Anthos Service Mesh 1.7.8. Pour plus d'informations, consultez la section Environnements compatibles. Suivez les instructions de la page Enregistrer un cluster existant dans une version disponible si vous disposez d'une version GKE statique.

  • Pour être inclus dans le maillage de services, les ports de service doivent être nommés et le nom de protocole du port doit respecter la syntaxe suivante : name: protocol[-suffix], où les crochets indiquent un suffixe facultatif qui doit commencer par un tiret. Pour plus d'informations, consultez la section Nommer les ports de service.

  • 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 avez créé un périmètre de service dans votre organisation, vous devrez peut-être ajouter le service Mesh CA au périmètre. Pour en savoir plus, consultez la section Ajouter l'autorité de certification Mesh CA à un périmètre de service.

  • Pour les migrations, istiod doit être installé dans l'espace de noms istio-system, ce qui est généralement le cas.

Restrictions

Un projet Google Cloud ne peut être associé qu'à un seul réseau maillé.

Choisir une autorité de certification

Pour les nouvelles installations et les migrations, vous pouvez utiliser l'autorité de certification Anthos Service Mesh (Mesh CA) ou Citadel (désormais intégrée à istiod) en tant qu'autorité de certification (CA) pour émettre des certificats TLS mutuels (mTLS).

Nous vous recommandons généralement d'utiliser Mesh CA pour les raisons suivantes :

  • Mesh CA est un service hautement fiable et évolutif, optimisé pour les charges de travail à scaling dynamique sur Google Cloud.
  • Avec Mesh CA, Google gère la sécurité et la disponibilité du backend CA.
  • Mesh CA vous permet de dépendre d'une seule racine de confiance dans les clusters.
Pour les nouvelles installations d'Anthos Service Mesh, le script active par défaut Mesh CA.

Vous pouvez cependant envisager d'utiliser Citadel dans certains cas :

  • Si vous disposez d'une autorité de certification personnalisée.

  • Si vous migrez depuis Istio.

    Si vous choisissez Citadel, il n'y a pas d'interruption, car le trafic mTLS n'est pas interrompu pendant la migration. Si vous choisissez Mesh CA, vous devez planifier un temps d'arrêt pour la migration, car la racine de confiance passe de Citadel à Mesh CA. Pour migrer vers la racine de confiance de Mesh CA, vous devez redémarrer l'ensemble des pods dans tous les espaces de noms. Pendant ce processus, les anciens pods ne peuvent pas établir de connexions mTLS avec les nouveaux pods.

Les certificats émis par l'autorité de certification d'Anthos Service Mesh (Mesh CA) incluent les données suivantes sur les services de votre application :

  • L'ID de projet Google Cloud
  • L'espace de noms GKE
  • Le nom du compte de service GKE

Préparer une migration ou une mise à niveau

Si vous effectuez une migration depuis Istio, veillez à consulter la page Préparer la migration depuis Istio.

Si vous avez personnalisé l'installation précédente, vous avez besoin des mêmes personnalisations lors de la migration ou de la mise à niveau vers Anthos Service Mesh. Si vous avez personnalisé l'installation en ajoutant l'option --set values, nous vous recommandons d'ajouter ces paramètres à un fichier de configuration IstioOperator. Vous spécifiez le fichier de configuration à l'aide de --custom_overlay avec le fichier de configuration lorsque vous exécutez le script.

Installer les outils requis

Vous pouvez exécuter le script sur Cloud Shell ou sur votre ordinateur local exécutant Linux.

Pour exécuter le script localement :

  1. Assurez-vous que les outils suivants sont installés :

  2. Authentifiez-vous en utilisant gcloud CLI :

    gcloud auth login

  3. Mettez à jour les composants :

    gcloud components update

  4. Assurez-vous que git se trouve dans votre chemin pour que kpt puisse le trouver.

  5. Téléchargez la version requise de kpt.

Exécuter le script

Cette section explique comment télécharger le script, définir les paramètres obligatoires et facultatifs, et exécuter le script. Pour obtenir une explication détaillée de l'utilisation du script, consultez la section Comprendre le script.

  1. Téléchargez la version du script qui installe Anthos Service Mesh 1.7.8 dans le répertoire de travail actuel :

    curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.7 > install_asm

    Même si vous téléchargez le script à partir d'un emplacement sécurisé de Cloud Source Repositories, le script est également disponible sur GitHub dans le dépôt anthos-service-mesh-packages afin que vous puissiez voir ce qu'il fait avant de le télécharger. La version du script install_asm sur la branche release-1.7-asm installe Anthos Service Mesh 1.7.8.

  2. Téléchargez le hachage SHA-256 du fichier dans le répertoire de travail actuel :

    curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.7.sha256 > install_asm.sha256

  3. Une fois les deux fichiers dans le même répertoire, validez le téléchargement avec la commande suivante :

    sha256sum -c --ignore-missing install_asm.sha256

    Si la validation réussit, la commande affiche le résultat suivant : install_asm: OK

    Pour assurer la compatibilité, le fichier install_asm.sha256 inclut la somme de contrôle deux fois pour permettre de renommer n'importe quelle version du script en install_asm. Si vous obtenez une erreur indiquant que --ignore-missing n'existe pas, réexécutez la commande précédente sans l'option --ignore-missing.

  4. Rendez le script exécutable :

    chmod +x install_asm

  5. Définissez les options permettant d'exécuter le script. Vous incluez toujours les options suivantes : project_id, cluster_name, cluster_location et mode. Selon mode, vous devrez peut-être inclure l'option ca.

    • Les options project_id, cluster_name et cluster_location identifient le cluster sur lequel installer Anthos Service Mesh.
    • L'élément mode correspond à install, migrate ou upgrade.
    • Le paramètre ca spécifie l'autorité de certification à mesh_ca ou citadel.

    La section suivante fournit des exemples typiques d'exécution du script. Pour obtenir une description complète des arguments du script, consultez la section Option et indicateurs.

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

Examples

Cette section présente des exemples d'exécution du script dans chaque mode, 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 cluster et il n'installe pas Anthos Service Mesh. 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 existant 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
re-run the script with the '--enable_apis' flag to allow the script to enable
them on your behalf.

Installation

La commande suivante exécute le script pour une nouvelle installation, active l'autorité de certification Mesh (l'autorité de certification par défaut pour les nouvelles installations ; vous n'avez donc pas besoin de l'option ca dans ce cas) et permet au script d'activer les API Google requises.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --enable_apis

Installation avec Citadel comme autorité de certification

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 pour une installation et activer Citadel comme autorité de certification

Nous vous recommandons d'utiliser Citadel comme autorité de certification seulement 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.

  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

    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 \
  --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 \
  --enable_apis \
  --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 \
  --enable_apis \
  --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.7-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.

Migration depuis Istio

Si vous effectuez une migration depuis Istio avec Citadel en tant qu'autorité de certification, vous pouvez continuer à utiliser Citadel après la migration vers Anthos Service Mesh. La commande suivante exécute le script pour une migration et active Citadel en tant qu'autorité de certification : Cette migration ne déploie que le plan de contrôle. Elle ne modifie pas l'autorité de certification racine et ne perturbe pas vos charges de travail existantes.

./install_asm \
  -p PROJECT_ID \
  -n CLUSTER_NAME \
  -l CLUSTER_LOCATION \
  -m migrate \
  -c citadel \
  --enable_apis

Effectuer la migration en utilisant un fichier superposé

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 migration 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 migrate \
  --ca citadel \
  --enable_all \
  --custom_overlay OVERLAY_FILE

Mise à niveau

La commande suivante exécute le script pour effectuer la mise à niveau. Ce script ne vous permet pas de passer à une autre autorité de certification. Vous n'avez donc pas besoin d'inclure l'option ca.

./install_asm \
  -p PROJECT_ID \
  -n CLUSTER_NAME \
  -l CLUSTER_LOCATION \
  -m upgrade \
  --enable_apis

Mettre à niveau avec un fichier superposé

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 mise à niveau 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 upgrade \
  --enable_all \
  --custom_overlay OVERLAY_FILE

Options et indicateurs

Cette section décrit les arguments disponibles pour le script.

Options

-p|--project_id CLUSTER_PROJECT_ID
ID du projet dans lequel le cluster a été créé.
-n|--cluster_name CLUSTER_NAME
Nom du cluster.
-l|--cluster_location CLUSTER_LOCATION
Zone (pour les clusters à zone unique) ou région (pour les clusters régionaux) dans laquelle le cluster a été créé.
-m|--mode {install|migrate|upgrade}
Saisissez install si vous effectuez une installation d'Anthos Service Mesh. Saisissez migrate si vous effectuez une migration depuis Istio. Saisissez upgrade pour mettre à niveau une installation Anthos Service Mesh existante vers une nouvelle version.
-c|--ca {mesh_ca|citadel}
Pour les installations, si vous souhaitez utiliser Mesh CA, vous n'avez pas besoin d'inclure cette option, car le script est défini par défaut sur Mesh CA. Pour les mises à niveau, vous n'avez pas besoin d'inclure cette option, car le script ne vous permet pas de modifier l'autorité de certification. Pour les migrations, vous devez spécifier citadel ou mesh_ca. Si vous pouvez planifier un temps d'arrêt pour la migration, nous vous recommandons d'utiliser mesh_ca. Pour en savoir plus sur l'autorité de certification à utiliser, consultez la page Choisir une autorité de certification. Pour connaître les options supplémentaires que vous devez spécifier lors de l'utilisation de Citadel, consultez la section Options pour un certificat personnalisé pour Citadel.
--co|--custom_overlay YAML_FILE
Nom du fichier YAML de la ressource personnalisée IstioOperator pour activer une fonctionnalité qui n'est pas activée par défaut. Le script doit pouvoir localiser le fichier YAML. Par conséquent, celui-ci doit se trouver dans le même répertoire que le script, ou vous pouvez spécifier un chemin d'accès relatif. Pour ajouter plusieurs fichiers, spécifiez --co|--custom_overlay et le nom du fichier, par exemple : --co overlay_file1.yaml --co overlay_file2.yaml --co overlay_file3.yaml
-o|--option OPTION_FILE
Nom d'un fichier YAML du package anthos-service-mesh contenant la ressource personnalisée IstioOperator pour activer une fonctionnalité facultative. Lorsque vous incluez l'un de ces fichiers, vous n'avez pas besoin de télécharger le package anthos-service-mesh au préalable, et vous ne spécifiez pas l'extension .yaml. Si vous devez modifier l'un des fichiers, téléchargez le package anthos-service-mesh, apportez vos modifications et utilisez l'option --custom_overlay. Pour ajouter plusieurs fichiers, spécifiez -o|--option et le nom du fichier, par exemple : -o option_file1 -o option_file2 -o option_file3
-s|--service_account ACCOUNT
Nom d'un compte de service permettant d'installer Anthos Service Mesh. S'il n'est pas spécifié, le compte utilisateur actif dans la configuration gcloud actuelle est utilisé. Si vous devez modifier le compte utilisateur actif, exécutez la commande gcloud auth login.
-k|--key_file FILE_PATH
Fichier de clé d'un compte de service. Ne renseignez pas cette option si vous n'utilisez pas de compte de service.
-D|--output_dir DIR_PATH
S'il n'est pas spécifié, le script crée un répertoire temporaire dans lequel il télécharge les fichiers et les configurations nécessaires à l'installation d'Anthos Service Mesh. Spécifiez l'option --output-dir pour désigner un répertoire existant à utiliser à la place. Une fois l'opération terminée, le répertoire spécifié contient les sous-répertoires asm et istio-1.7.8-asm.10. Le répertoire asm contient la configuration pour l'installation. Le répertoire istio-1.7.8-asm.10 contient le contenu extrait du fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes.

Options

-e|--enable_apis
Permet au script d'activer les API Google requises par Anthos Service Mesh. Sans cette option, le script se ferme si les API requises ne sont pas déjà activées. Pour obtenir la liste des API activées par le script, utilisez set_up_project.
-v|--verbose
Imprimez les commandes avant et après l'exécution.
--dry_run
Imprimez les commandes, mais ne les exécutez pas.
--only_validate
Exécutez la validation, mais n'installez pas Anthos Service Mesh.
--print_config
Au lieu d'installer Anthos Service Mesh, imprimez tout le fichier YAML compilé en sortie standard (stdout). Toutes les autres sorties sont générées pour les erreurs standards (stderr), même si elles se rendent normalement dans stdout. Le script ignore toutes les validations et la configuration lorsque vous spécifiez cette option.
--disable_canonical_service
Par défaut, le script déploie le contrôleur de service canonique sur votre cluster. Si vous ne souhaitez pas que le script déploie le contrôleur, spécifiez l'option --disable_canonical_service. Pour en savoir plus, consultez la page Activer et désactiver le contrôleur de service canonique.
-h|--help
Affiche un message d'aide décrivant les options, puis ferme.
--version
Imprimez la version de install_asm, puis quittez. Si la commande ne génère pas de version, téléchargez la version la plus récente de install_asm_1.7.

Options pour un certificat personnalisé pour Citadel

Si vous avez spécifié citadel et que vous utilisez une autorité de certification personnalisée, incluez les options suivantes :

  • --ca_cert FILE_PATH : le certificat intermédiaire
  • --ca_key FILE_PATH : la clé du certificat intermédiaire
  • --root_cert FILE_PATH : le certificat racine
  • --cert_chain FILE_PATH : la chaîne de certificats

Pour en savoir plus, consultez la page Connecter des certificats CA existants.

Déployer et redéployer des charges de travail

Votre installation n'est pas terminée tant que vous n'avez pas activé l'injection automatique du proxy side-car (injection automatique).

  • Pour les nouvelles installations, vous devez activer l'injection automatique et redémarrer les pods pour toutes les charges de travail qui s'exécutaient sur votre cluster avant l'installation d'Anthos Service Mesh.

  • Les migrations et mises à niveau suivent le processus de mise à niveau du plan de contrôle double (appelé "mises à niveau Canary" dans la documentation d'Istio). Avec une mise à niveau du plan de contrôle double, le script installe une nouvelle version de istiod avec l'image istiod existante. Vous déplacez ensuite certaines de vos charges de travail vers la nouvelle version. Ce processus vous permet de surveiller l'effet de la nouvelle version avec un faible pourcentage des charges de travail avant de migrer tout votre trafic vers la nouvelle version.

  • Avant de déployer de nouvelles charges de travail, veillez à activer l'injection automatique afin qu'Anthos Service Mesh puisse surveiller et sécuriser le trafic.

Pour activer l'injection automatique, vous obtenez le libellé de révision appliqué par le script à istiod et l'ajoutez à vos espaces de noms. Vous trouverez des informations détaillées dans les sections suivantes.

Obtenir le libellé de révision

Le script ajoute un libellé de révision au format istio.io/rev=asm-178-10 dans istiod. Pour activer l'injection automatique, vous devez ajouter un libellé de révision correspondant à votre ou vos espaces de noms. Le libellé de révision est utilisé par le webhook d'injecteur de 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.

  1. Définissez le contexte actuel de kubectl :

    gcloud container clusters get-credentials CLUSTER_NAME \
    --project=PROJECT_ID

  2. Affichez les libellés sur istiod pour obtenir le libellé de révision défini par le script :

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

    La sortie de la commande ressemble à ceci : Notez que le résultat pour les nouvelles installations, migrations et mises à niveau est légèrement différent. L'exemple de résultat suivant provient d'une migration.

    NAME                                READY   STATUS    RESTARTS   AGE   LABELS
istiod-7744bc8dd7-qhlss             1/1     Running   0          49m   app=istiod,istio.io/rev=default,istio=pilot,pod-template-hash=7744bc8dd7
istiod-asm-178-10-85d86774f7-flrt2   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-178-10,istio=istiod,pod-template-hash=85d86774f7
istiod-asm-178-10-85d86774f7-tcwtn   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-178-10,istio=istiod,pod-template-hash=85d86774f7

    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-178-10, mais votre valeur peut être différente.

    Pour les mises à niveau et les migrations, notez également la valeur du libellé de révision pour l'ancienne version de istiod. Vous en aurez besoin pour supprimer l'ancienne version de istiod une fois la migration ou la mise à niveau terminée. Dans l'exemple de résultat, la valeur du libellé de révision de l'ancienne version de istiod est default, mais la valeur affichée peut être différente.

Activer l'injection automatique

Suivez ces étapes pour les nouvelles installations, migrations et mises à niveau afin d'activer l'injection automatique.

  1. Récupérez la valeur figurant dans le libellé de révision pour istiod.

  2. Ajoutez le libellé de révision à un espace de noms et supprimez le libellé istio-injection. Dans la commande suivante, remplacez REVISION par la valeur correspondant à la révision sur istiod.

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

  3. Redémarrez les pods pour déclencher la réinjection :

    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

  5. Testez votre application pour vérifier que les charges de travail fonctionnent correctement.

  6. Si vous avez des charges de travail dans d'autres espaces de noms, répétez les étapes pour leur ajouter des libellés et redémarrer les pods.

Pour la migration et les mises à niveau :

Terminer la transition

Pour les migrations et les mises à niveau, vous devez supprimer l'ancienne version de istiod. Si vous êtes sûr que votre application fonctionne comme prévu, supprimez l'ancien plan de contrôle pour terminer la transition vers la nouvelle version.

  1. Récupérez la valeur figurant dans le libellé de révision pour l'ancienne version de istiod.

  2. Supprimez l'ancienne version de istiod. Dans la commande suivante, remplacez OLD_REVISION par la révision de l'étape précédente.

    kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION  -n istio-system --ignore-not-found=true

Restaurer la version précédente

Pour les migrations et les mises à niveau, si vous avez rencontré un problème lors du test de votre application avec la nouvelle version de istiod, procédez comme suit pour effectuer un rollback vers la version précédente :

  1. Modifier les libellés à votre espace de noms afin d'activer l'injection automatique avec la version précédente de istiod. La commande que vous utilisez varie selon que vous avez utilisé une étiquette de révision ou istio-injection=enabled avec la version précédente.

    • Si vous avez utilisé un libellé de révision pour l'injection automatique :

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

    • Si vous avez utilisé istio-injection=enabled :

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

  2. Redémarrez les pods pour déclencher une réinjection afin que les proxys disposent de la version précédente : 

    kubectl rollout restart deployment -n NAMESPACE

  3. Redéployez la version précédente du fichier istio-ingressgateway :

    kubectl -n istio-system rollout undo deploy istio-ingressgateway

  4. Supprimez le nouveau fichier istiod :

    kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION -n istio-system --ignore-not-found=true

  5. Si vous n'avez pas ajouté l'option --disable_canonical_service, le script a activé le contrôleur de service canonique. Pour le désactiver, suivez la procédure décrite sur la page Activer et désactiver le contrôleur de service canonique.

Réinstaller la même version

Le script install_asm appelle istioctl install afin de déployer les composants du plan de contrôle Anthos Service Mesh (istiod et istio-ingressgateway) pour les installations, les mises à niveau et les migrations Istio. Comme le script utilise istioctl install, si vous devez personnaliser Anthos Service Mesh pour activer une fonctionnalité facultative, vous devez réinstaller le plan de contrôle avec la nouvelle configuration.

Une modification a été apportée au script install_asm afin que vous puissiez réinstaller la même version d'Anthos Service Mesh. Lorsque vous réinstallez la même version afin d'activer une fonctionnalité facultative, la configuration du plan de contrôle existant est écrasée. De ce fait, si vous avez personnalisé l'installation existante, vous devez inclure les mêmes options --option et/ou --custom_overlay de l'installation précédente, ainsi que les options --option et/ou --custom_overlay pour les nouvelles fonctionnalités que vous souhaitez activer.

Sachez que si vous activez Cloud Trace ou modifiez un paramètre de traçage, vous devez également redéployer les charges de travail afin que les proxys side-car soient réinjectés avec la configuration mise à jour du plan de contrôle.

Lorsque vous réinstallez la même version, vous devez spécifier --mode install, comme pour les installations. Pour en savoir plus sur l'installation à l'aide du script, consultez la page Installer Anthos Service Mesh.

Si vous spécifiez plusieurs ressources personnalisées IstioOperator 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.

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.

Enregistrer votre cluster

Vous devez enregistrer votre cluster auprès de l'Environ du projet pour accéder à l'interface utilisateur unifiée dans la console Google Cloud. Un parc constitue un moyen unifié d'afficher et de gérer les clusters et leurs charges de travail, y compris les clusters extérieurs à Google Cloud.

Consultez la section Enregistrer des clusters dans le parc pour en savoir plus sur l'enregistrement de votre cluster.

Comprendre le script

Même si vous téléchargez le script à partir d'un emplacement sécurisé de Cloud Source Repositories, le script est également disponible sur GitHub afin que vous puissiez voir ce qu'il fait avant de le télécharger. Le script valide que votre cluster remplit les exigences et automatise toutes les étapes que vous devrez effectuer manuellement dans l'article Installer Anthos Service Mesh sur GKE.

Avec Anthos Service Mesh 1.7.8, vous utilisez la version du script install_asm sur la branche release-1.7-asm. Pour obtenir une explication du processus de gestion et de lancement des versions, consultez la page Gestion des versions/Lancement.

validate_args et validate_dependencies

validate_args() {
  if [[ "${MODE}" == "install" && -z "${CA}" ]]; then
    CA="mesh_ca"
  fi

  local MISSING_ARGS=0
  while read -r REQUIRED_ARG; do
    if [[ -z "${!REQUIRED_ARG}" ]]; then
      MISSING_ARGS=1
      warn "Missing value for ${REQUIRED_ARG}"
    fi
    readonly "${REQUIRED_ARG}"
  done <<EOF
validate_dependencies() {
  validate_cli_dependencies
  if [[ "${PRINT_CONFIG}" -eq 1 ]]; then
    return 0
  fi

  validate_gcp_resources
  # configure kubectl does have side effects but we've generated a temprorary
  # kubeconfig so we're not breaking the promise that --only_validate gives
  configure_kubectl
  validate_k8s
  validate_expected_control_plane

  if [[ "${MODE}" = "migrate" ]]; then
    validate_istio_version
  elif [[ "${MODE}" = "upgrade" ]]; then
    validate_asm_version
    validate_ca_consistency
  fi

  if [[ "${ENABLE_APIS}" -eq 0 || "${ONLY_VALIDATE}" -eq 1 ]]; then
    exit_if_apis_not_enabled
  fi
}

Les fonctions validate_args et validate_dependencies :

  • vérifient que tous les outils requis sont installés ;
  • vérifient que l'ID du projet, le nom du cluster et l'emplacement du cluster que vous avez saisis en tant que valeurs de paramètre sont valides ;
  • s'assurent que le cluster respecte le minimum requis pour le type de machine et le nombre de nœuds.

set_up_project

Si vous avez inclus l'option --enable_apis, la fonction set_up_project active les API requises :

required_apis() {
    cat << EOF
container.googleapis.com
compute.googleapis.com
monitoring.googleapis.com
logging.googleapis.com
cloudtrace.googleapis.com
meshca.googleapis.com
meshtelemetry.googleapis.com
meshconfig.googleapis.com
iamcredentials.googleapis.com
gkeconnect.googleapis.com
gkehub.googleapis.com
cloudresourcemanager.googleapis.com
stackdriver.googleapis.com
EOF
}

set_up_cluster

set_up_cluster(){
  if [[ "${PRINT_CONFIG}" -eq 1 ]]; then
    return 0
  fi
  add_cluster_labels
  enable_workload_identity

  init_meshconfig

  enable_stackdriver_kubernetes
  bind_user_to_cluster_admin
  ensure_istio_namespace_exists
}

La fonction set_up_cluster effectue les mises à jour suivantes sur votre cluster :

  • Active Workload Identity, la méthode recommandée pour accéder en toute sécurité aux services Google Cloud à partir d'applications GKE.

  • Active Cloud Monitoring et Cloud Logging sur GKE.

  • Définit le libellé mesh_id sur le cluster, qui est nécessaire pour que les métriques s'affichent sur les pages Anthos Service Mesh de la console Google Cloud.

  • Elle définit un libellé tel que asmv=asm-178-10 pour indiquer que le cluster a été modifié par le script.

  • Liez l'utilisateur ou le compte de service GCP qui exécute le script au rôle cluster-admin sur votre cluster.

install_asm

install_asm() {

  local PARAMS
  PARAMS="-f ${OPERATOR_MANIFEST} -f ${MULTICLUSTER_MANIFEST}"
  while read -d ',' -r yaml_file; do
    PARAMS="${PARAMS} -f ${yaml_file}"
  done <<EOF

Fonction install_asm :

  • Elle télécharge le package kpt dans un répertoire temporaire.
  • Elle exécute les setters kpt pour configurer le fichier istio-operator.yaml.
  • Elle installe Anthos Service Mesh.

Étapes suivantes