Installation et migration sur GKE

Ce guide explique comment installer ou migrer vers la version 1.6.14 d'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 pour les cas d'utilisation suivants :

  • Nouvelles installations d'Anthos Service Mesh. Si une version précédente d'Anthos Service Mesh est installée, consultez la page Mettre à niveau Anthos Service Mesh sur GKE. Le script 1.6 ne gère pas les mises à niveau.

  • Migration du logiciel Open Source Istio 1.6 vers Anthos Service Mesh. La migration depuis une version antérieure d'Istio n'est pas possible. La version 1.7 du script permet de migrer d'Istio 1.6 ou 1.7 vers Anthos Service Mesh 1.7. Comme vous procédez à la migration, vous préférerez peut-être effectuer la migration vers Anthos Service Mesh 1.7.

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

Vous devez utiliser le guide Installation et migration avancées sur GKE pour les cas d'utilisation suivants :

  • Lorsque vous devez personnaliser l'installation pour remplacer les paramètres du profil asm-gcp et que vous disposez de plusieurs fichiers YAML IstioOperator en superposition. Le script vous permet de ne spécifier qu'un seul fichier YAMl.

  • Pour un réseau maillé multicluster dans lequel les clusters se trouvent dans des projets différents.

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.

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.6.14. 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 effectuez une migration depuis Istio ou le module complémentaire Istio sur GKE.

    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 le trafic mTLS échoue jusqu'à ce que vous redémarriez tous les pods dans tous les espaces de noms.

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

Installer les outils requis

Vous pouvez exécuter le script sur Cloud Shell ou sur votre machine locale exécutant Linux ou macOS. Cloud Shell préinstalle tous les outils requis.

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.

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 le script dans le répertoire de travail actuel :

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

  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.6.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 est install ou migrate.
    • 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.

  1. Créez un répertoire appelé asm-packages.

    mkdir asm-packages

  2. 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 asm-packages :

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

En cas de réussite, le script génère les éléments suivants :

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

Nouvelle 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

Nouvelle installation avec un fichier superposé

L'exemple suivant effectue une nouvelle installation et inclut un fichier YAML qui active une fonctionnalité facultative.

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

Migration depuis Istio

Si vous effectuez une migration à partir d'Istio Open Source, vous utilisez Citadel en tant qu'autorité de certification. La commande suivante exécute le script pour une migration vers Anthos Service Mesh 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 elle n'interrompt pas vos charges de travail existantes.

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

Options et indicateurs

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}
Saisissez install si vous effectuez une nouvelle installation d'Anthos Service Mesh. Saisissez migrate si vous effectuez une migration depuis Istio ou le module complémentaire Istio sur GKE vers Anthos Service Mesh.
-c|--ca {mesh_ca|citadel}
Si vous effectuez une nouvelle installation, ce paramètre est défini par défaut sur Mesh CA. Vous n'avez donc pas besoin de l'inclure. Si vous effectuez une migration depuis Istio, 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. Dans le cas contraire, utilisez citadel.
-o|--operator_overlay YAML_FILE
Nom du fichier YAML permettant d'activer une fonctionnalité qui n'est pas activée dans le profil asm-gcp. Le script doit pouvoir localiser le fichier YAML. Le fichier doit donc se trouver dans le même répertoire que le script, ou vous pouvez spécifier un chemin d'accès relatif tel que : ../manifests/asm-features.yaml
-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.6.14-asm.2. Le répertoire asm contient la configuration pour l'installation. Le répertoire istio-1.6.14-asm.2 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.
--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, les indicateurs et la sortie.

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 de Anthos Service Mesh.

  • Les migrations depuis Istio suivent le processus de mise à niveau du plan de contrôle double (appelé "mises à jour 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-1614-2 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 :

    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-1614-2-85d86774f7-flrt2   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-1614-2,istio=istiod,pod-template-hash=85d86774f7
istiod-asm-1614-2-85d86774f7-tcwtn   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-1614-2,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-1614-2, mais votre valeur peut être différente.

    Pour 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 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 et migrations afin d'activer l'injection automatique.

  1. Récupérez la valeur figurant dans l'étiquette 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 :

Terminer la transition

Pour les migrations, 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 l'étiquette 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, 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. Mettez à jour les charges de travail à injecter avec la version précédente de istiod :

    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.

Afficher les tableaux de bord Anthos Service Mesh

Cette section ne s'applique que si vous avez installé Anthos Service Mesh avec le profil de configuration asm-gcp. Si vous avez utilisé le profil asm-gcp-multiproject pour installer Anthos Service Mesh, les données de télémétrie ne seront pas disponibles sur les tableaux de bord Anthos Service Mesh dans la console Google Cloud.

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,

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

  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_expected_control_plane
  if [[ "${MODE}" = "migrate" ]]; then
    validate_istio_version
  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
EOF
}

set_up_cluster

set_up_cluster(){
  add_cluster_labels
  enable_workload_identity

  # this is project scope but requires workload identity
  if [[ "${CA}" = "mesh_ca" ]]; then
    init_meshca
  fi

  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-1614-2 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 CA_OPT
  CA_OPT=""
  if [[ "${CA}" = "citadel" ]]; then
    CA_OPT="-citadel"
  fi

  info "Configuring kpt package..."
  run kpt cfg set asm gcloud.container.cluster "${CLUSTER_NAME}"
  run kpt cfg set asm gcloud.core.project "${PROJECT_ID}"
  run kpt cfg set asm gcloud.project.environProjectNumber "${PROJECT_NUMBER}"
  run kpt cfg set asm gcloud.compute.location "${CLUSTER_LOCATION}"
  run kpt cfg set asm anthos.servicemesh.rev "${REVISION_LABEL}"
  if [[ -n "${_CI_ASM_IMAGE_LOCATION}" ]]; then
    run kpt cfg set asm anthos.servicemesh.hub "${_CI_ASM_IMAGE_LOCATION}"
    run kpt cfg set asm anthos.servicemesh.tag "${RELEASE}"
  fi

  local PARAMS
  PARAMS="-f ${OPERATOR_MANIFEST}"
  if [[  -f "$CUSTOM_OVERLAY" ]]; then
    PARAMS="${PARAMS} -f ${CUSTOM_OVERLAY}"
  fi
  PARAMS="${PARAMS} --set revision=${REVISION_LABEL}"
  PARAMS="${PARAMS} -c ${KUBECONFIG}"

  info "Installing ASM control plane..."
  # shellcheck disable=SC2086
  retry 5 run ./"${ISTIOCTL_REL_PATH}" install $PARAMS

  # Prevent the stderr buffer from ^ messing up the terminal output below
  sleep 1
  info "...done!"

  if ! does_istiod_exist; then
    info "Installing validation webhook fix..."
    retry 3 run kubectl apply -f "${VALIDATION_FIX_SERVICE}"
  fi

  if [[ "$DISABLE_CANONICAL_SERVICE" -ne 1 ]]; then
    info "Installing ASM CanonicalService controller in asm-system namespace..."
    retry 3 run kubectl apply -f asm/canonical-service/controller.yaml
    info "Waiting for deployment..."
    retry 3 run kubectl wait --for=condition=available --timeout=600s \
        deployment/canonical-service-controller-manager -n asm-system
    info "...done!"
  fi

  outro
}

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.

Différences avec le script 1.7

Script 1.7 Script 1.6
Compatible avec les mises à niveau. N'effectue pas de mises à niveau.
Accepte les migrations depuis Istio 1.6 et Istio 1.7. Compatible avec la migration depuis Istio 1.6
--print_config
Fournit la configuration que vous avez utilisée lors de l'installation à l'aide du script install_asm. Cette option vous permet d'installer de nouveau la même version d'Anthos Service Mesh (que le script n'autorise pas) avec la même configuration que celle que vous avez utilisée lors de l'installation précédente.		 Non disponible
--custom_overlay
Autorise plusieurs fichiers superposés.		 --custom_overlay
Autorise un seul fichier superposé.
--option
Extrayez des fichiers superposés à partir du package asm sur GitHub. 		Non disponible.
Compatibilité avec les autorités de certification personnalisées avec les options suivantes :

--ca_cert
--ca_key
--root_cert
--cert_chain

Non disponible.