Installer Anthos Service Mesh

Cette page explique comment exécuter le script permettant d'installer la version 1.8.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 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.

Cette page concerne les installations d'Anthos Service Mesh, qu'il s'agisse d'une nouvelle installation ou de la réinstallation de la même version avec une autre configuration.

Bien que l'exécution du script pour les nouvelles installations soit similaire pour les réinstallation de la même version, les mises à niveau et les migrations depuis Istio, ces cas d'utilisation impliquent une planification supplémentaire. Pour en savoir plus, consultez les pages suivantes :

Avant de commencer

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

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 Citadel comme autorité de certification, vous devez spécifier l'option --ca et d'autres options, comme décrit dans la section Installation avec Citadel comme autorité de certification. 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 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 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 la nécessité d'utiliser le script avec une option d'activation, vous pouvez inclure l'option spécifique du message d'erreur ou l'option --enable_all lors de l'exécution du script sans --only_validate. Si vous préférez, vous pouvez mettre à jour vous-même votre projet et votre cluster avant d'exécuter le script, comme décrit sur les pages Configurer le projet et Configurer un cluster du guide d'installation sur plusieurs projets.

Installation

La commande suivante exécute le script pour une nouvelle installation et active Mesh CA, qui est l'autorité de certification par défaut pour les installations. Vous n'avez donc pas besoin de l'option --ca dans ce cas. L'option --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 la fonctionnalité Workload Identity de GKE.

Si vous envisagez d'utiliser Mesh CA, vous pouvez utiliser le pool d'identités de charge de travail de la Fleet en remplacement de la fonctionnalité Workload Identity de GKE. Pour obtenir un exemple, consultez la section Activer Mesh CA avec le pool d'identités de charge de travail de la Fleet.

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

Vous pouvez également inclure les informations suivantes :

  • --output_dir DIR_PATH Si vous n'avez pas exécuté l'exemple "only validate" (valider uniquement), indiquez cette option pour spécifier un répertoire existant dans lequel le script télécharge le package asm et le fichier d'installation d'Anthos Service Mesh, qui contient 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.

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_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 \
  --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.8-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 la Fleet

La version Bêta de Mesh CA avec 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 la Fleet vous permet de joindre des clusters situés dans des projets Google Cloud distincts au sein d'un même domaine d'approbation correspondant à la Fleet.

Pour activer Mesh CA avec la Fleet, procédez comme suit :

Si vous n'avez pas encore enregistré votre cluster, veillez à inclure l'option --enable-registration comme indiqué dans l'exemple suivant :

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --enable_all \
  --enable-registration \
  --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.

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-186-8-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-186-8,istio=istiod,pod-template-hash=5788d57586
istiod-asm-186-8-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-186-8,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-186-8.

  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