Installer Anthos Service Mesh

Cette page explique comment effectuer les actions suivantes :

• Exécutez le script asmcli pour effectuer une nouvelle installation d'Anthos Service Mesh 1.11.8-asm.4.
• Vous pouvez éventuellement déployer une passerelle d'entrée.
• Déployez ou redéployez vos charges de travail pour injecter des proxys side-car.

Remarque : Bien que vous utilisiez asmcli pour déployer un service Anthos Service Mesh géré et installer Anthos Service Mesh sur GKE en vue d'ajouter des machines virtuelles Compute Engine au maillage de services, vous devez inclure des options de ligne de commande spécifiques lors de l'exécution de asmcli install. Vous devez tenir compte de certaines étapes supplémentaires et limites. Pour obtenir les instructions d'installation de ces fonctionnalités, consultez les pages suivantes :

• Configurer un service Anthos Service Mesh géré
• Ajouter des machines virtuelles Compute Engine au maillage de services

Remarque : Seul Anthos Service Mesh géré est compatible avec les clusters GKE Autopilot. Actuellement, la compatibilité d'Anthos Service Mesh pour GKE Autopilot est en version bêta et n'est disponible qu'avec le canal rapide GKE et les versions 1.21.3 et ultérieures.

Avant de commencer

Avant de commencer, veillez à suivre les étapes ci-dessous :

• Consultez les conditions préalables.
• Consultez les informations de la section Planifier l'installation.
• Installez les outils nécessaires.
• Téléchargez asmcli.
• Accordez des autorisations d'administrateur de cluster.
• Validez le projet et le cluster.

Avertissement : Pour qu'Anthos Service Mesh fonctionne correctement, vous devez déployer istiod et canonical-service-controller-manager sur votre cluster. Ils disposent d'autorisations de contrôle d'accès (RBAC) basées sur les rôles élevées, telles que la possibilité de modifier tous les déploiements et tous les secrets de cluster. Ces autorisations sont requises pour les fonctions Anthos Service Mesh telles que l'injection de side-cars, la détection de services, la sécurisation du trafic, la gestion des passerelles d'entrée et la présentation des tableaux de bord des services.

Installer Anthos Service Mesh

Vous trouverez ci-dessous la procédure à suivre pour installer Anthos Service Mesh :

1. Exécutez asmcli install pour installer le plan de contrôle intégré sur un cluster unique. Consultez les sections suivantes pour obtenir des exemples de ligne de commande. Les exemples contiennent à la fois des arguments obligatoires et des arguments facultatifs qui peuvent vous être utiles. Nous vous recommandons de toujours spécifier l'argument output_dir afin de pouvoir facilement trouver des exemples de passerelles et d'outils tels que istioctl. Consultez la barre de navigation située à droite pour obtenir la liste des exemples.

2. Les clusters GKE privés nécessitent une étape de configuration de pare-feu supplémentaire pour autoriser le trafic vers istiod.

3. Vous pouvez également installer une passerelle d'entrée. Par défaut, asmcli n'installe pas la passerelle istio-ingressgateway. Nous vous recommandons de déployer et de gérer le plan de contrôle et les passerelles séparément. Si vous avez besoin d'installer l'option istio-ingressgateway par défaut avec le plan de contrôle au sein du cluster, incluez l'argument --option legacy-default-ingressgateway.

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

5. Si vous installez Anthos Service Mesh sur plusieurs clusters, exécutez asmcli install sur chaque cluster. Lorsque vous exécutez asmcli install, veillez à utiliser le même FLEET_PROJECT_ID pour chaque cluster. Une fois Anthos Service Mesh installé, consultez la page "Configurer un maillage multicluster".

6. Si vos clusters se trouvent sur des réseaux différents (en mode île par exemple), vous devez transmettre un nom de réseau unique à asmcli en utilisant l'option --network_id.

Installer les fonctionnalités par défaut et Mesh CA

Cette section explique comment exécuter asmcli pour installer Anthos Service Mesh avec les fonctionnalités compatibles par défaut de votre plate-forme et activer l'autorité de certification Anthos Service Mesh (Mesh CA) comme autorité de certification.

Remarque concernant la plate-forme:Mesh CA n'est pas compatible avec GKE sur AWS ni Amazon EKS. Si vous exécutez asmcli install et spécifiez --ca mesh_ca sur ces plates-formes, l'installation échoue.

GKE

Exécutez la commande suivante pour installer le plan de contrôle avec les fonctionnalités par défaut et Mesh CA. Saisissez vos valeurs dans les espaces réservés fournis.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca

• --project_id, --cluster_name et --cluster_location : spécifiez l'ID du projet dans lequel se trouve le cluster, son nom, ainsi que la zone ou la région du cluster.
• --fleet_id : ID du projet du projet hôte du parc. Si vous n'incluez pas cette option, asmcli utilise le projet dans lequel le cluster a été créé lors de son enregistrement.
• --output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp. Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.
  Remarque:Notez ce répertoire --output_dir. Vous devrez le référencer lors du déploiement de passerelles.
• --enable_all : permet au script d'effectuer les opérations suivantes :
  • Accorder les autorisations IAM requises.
  • Activer les API Google requises.
  • Définir un libellé sur le cluster qui identifie le réseau maillé.
  • Enregistrer le cluster dans le parc si ce n'est déjà fait.
• --ca mesh_ca : utiliser Mesh CA comme autorité de certification. asmcli configure Mesh CA pour utiliser l'identité de charge de travail de parc.

Sur site

Exécutez les commandes suivantes sur GKE sur VMware ou Google Distributed Cloud Virtual pour Bare Metal afin d'installer le plan de contrôle avec les fonctionnalités par défaut et Mesh CA. Saisissez vos valeurs dans les espaces réservés fournis.

1. Définissez le contexte actuel sur votre cluster d'utilisateur :

   kubectl config use-context CLUSTER_NAME
   

2. Exécutez asmcli install :

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca mesh_ca
   

   • --fleet_id : ID du projet du projet hôte du parc.
   • --kubeconfig : chemin d'accès complet au fichier kubeconfig. La variable d'environnement $PWD ne fonctionne pas ici. De plus, les emplacements de fichiers kubeconfig relatifs qui utilisent une valeur `~` ne fonctionneront pas.
   • --output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp. Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.
   • --platform multicloud spécifie que la plate-forme est une plate-forme autre que Google Cloud, par exemple une plate-forme sur site ou multicloud.
   • --enable_all : permet au script d'effectuer les opérations suivantes :
     • Accorder les autorisations IAM requises.
     • Activer les API Google requises.
     • Définir un libellé sur le cluster qui identifie le réseau maillé.
     • Enregistrer le cluster dans le parc si ce n'est déjà fait.
   • --ca mesh_ca : utiliser Mesh CA comme autorité de certification. asmcli configure Mesh CA pour utiliser l'identité de charge de travail de parc.

Installer les fonctionnalités par défaut et le service Certificate Authority (CA)

Cette section explique comment exécuter asmcli pour installer Anthos Service Mesh avec les fonctionnalités compatibles par défaut de votre plate-forme et activer le service d'autorité de certification comme autorité de certification.

Remarque sur la plate-forme : Le service d'autorité de certification n'est compatible qu'avec les clusters GKE sur Google Cloud. Si vous exécutez asmcli install et spécifiez --ca gcp_cas sur d'autres plates-formes, l'installation échoue.

Outre Mesh CA, vous pouvez configurer Anthos Service Mesh pour qu'il utilise le Certificate Authority Service. Ce guide vous offre l'occasion d'intégrer le service CA, qui est recommandé pour les cas d'utilisation suivants :

• Vous avez besoin de plusieurs autorités de certification différentes pour signer des certificats de charge de travail sur différents clusters.
• Vous souhaitez utiliser des certificats de plug-in d'autorités de certification personnalisées istiod.
• Vous devez sauvegarder vos clés de signature dans un HSM géré par Google.
• Vous travaillez dans un secteur hautement réglementé et vous êtes soumis à des exigences de conformité.
• Vous souhaitez associer votre autorité de certification Anthos Service Mesh à un certificat racine d'entreprise personnalisé pour signer les certificats de charge de travail.

Les coûts liés à l'utilisation de Mesh CA sont inclus dans la tarification d'Anthos Service Mesh. Le service d'autorité de certification n'est pas inclus dans le prix de base d'Anthos Service Mesh et est facturé séparément. En outre, le service d'autorité de certification est fourni avec un contrat de niveau de service explicite, contrairement à Mesh CA.

Pour cette intégration, toutes les charges de travail dans Anthos Service Mesh disposent de deux rôles IAM :

• privateca.workloadCertificateRequester
• privateca.auditor

Configurer le service d'autorité de certification

1. Créez le pool d'autorités de certification. Vous devez disposer d'au moins une autorité de certification active dans le même projet que le cluster GKE. Utilisez des autorités de certification subordonnées pour signer les certificats de charge de travail Anthos Service Mesh. Notez le pool d'autorités de certification correspondant à l'autorité de certification subordonnée.
2. Assurez-vous que le pool d'autorités de certification est au niveau DevOps et situé dans la même région que le cluster qu'il dessert, afin d'éviter des problèmes de latence excessive ou des pannes interrégionales potentielles. Pour en savoir plus, consultez la page Niveaux optimisés pour les charges de travail.

3. S'il est seulement destiné aux certificats de service pour les charges de travail Anthos Service Mesh, configurez la stratégie d'émission suivante pour le pool d'autorités de certification : pour les réseaux maillés multicluster, il est recommandé de créer un pool d'autorités de certification subordonné par région de cluster unique. Tous les pools d'autorités de certification subordonnés doivent être reliés au même pool d'autorités de certification racine.

   policy.yaml

   baselineValues:
     keyUsage:
       baseKeyUsage:
         digitalSignature: true
         keyEncipherment: true
       extendedKeyUsage:
         serverAuth: true
         clientAuth: true
     caOptions:
       isCa: false
   identityConstraints:
     allowSubjectPassthrough: false
     allowSubjectAltNamesPassthrough: true
     celExpression:
       expression: subject_alt_names.all(san, san.type == URI && san.value.startsWith("spiffe://PROJECT_ID.svc.id.goog/ns/") )
   

4. Pour mettre à jour la stratégie d'émission du pool d'autorités de certification, exécutez la commande suivante :

   gcloud privateca pools update CA_POOL --location ca_region --issuance-policy policy.yaml
   

Pour en savoir plus sur la définition d'une stratégie sur un pool, consultez la section Utiliser une stratégie d'émission de certificat.

Configurer Anthos Service Mesh pour utiliser le service CA

1. Installez le plan de contrôle Anthos Service Mesh qui utilise Certificate Authority Service en tant qu'autorité de certification :

   ./asmcli install \
     --project_id PROJECT_ID \
     --cluster_name CLUSTER_NAME \
     --cluster_location CLUSTER_LOCATION \
     --enable_all \
     --ca gcp_cas \
     --ca_pool projects/PROJECT_NAME/locations/ca_region/caPools/CA_POOL
   

2. Installez une passerelle d'entrée pour recevoir les connexions HTTP/TCP entrantes ou sortantes. Pour en savoir plus, consultez la section Installer des passerelles.

3. Terminez l'installation d'Anthos Service Mesh pour activer l'injection automatique de proxy sidecar sur vos charges de travail. Pour en savoir plus, consultez la page Déployer et redéployer des charges de travail.

Installer les fonctionnalités par défaut avec Istio CA

Cette section explique comment effectuer les opérations suivantes :

• Générez des certificats et des clés pour l'autorité de certification Istio utilisée par Anthos Service Mesh pour signer vos charges de travail.
• Exécutez asmcli pour installer Anthos Service Mesh avec les fonctionnalités par défaut et activer Istio CA.

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 (CA). Chaque autorité de certification Anthos Service Mesh utilise une clé et un certificat de signature CA intermédiaires, signés par l'autorité de certification racine. Lorsque plusieurs autorités de certification existent dans un maillage, cela établit une hiérarchie de confiance entre les autorités de certification. Vous pouvez répéter ces étapes pour provisionner les certificats et les clés d'un nombre illimité d'autorités de certification.

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

Le fichier Makefile pour générer les certificats se trouve dans le sous-répertoire istio-1.11.8-asm.4 du répertoire --output_dir que vous avez spécifié dans la commande asmcli validate. Si vous n'avez pas exécuté asmcli validate, ou si vous ne disposez pas du répertoire téléchargé localement, vous pouvez obtenir le fichier Makefile en téléchargeant le fichier d'installation d'Anthos Service Mesh et en extrayant le contenu.

1. Accédez au répertoire istio-1.11.8-asm.4.

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

   mkdir -p certs && \
   pushd certs

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

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

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

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

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

   Si vous effectuez ces étapes en utilisant un ordinateur hors connexion, copiez le répertoire généré sur un ordinateur qui a accès aux clusters.

5. Revenez au répertoire précédent :

   popd

6. Exécutez asmcli pour installer un réseau maillé à l'aide de l'autorité de certification Istio :

   GKE

   Exécutez la commande suivante pour installer le plan de contrôle avec les fonctionnalités par défaut et Istio CA. Saisissez vos valeurs dans les espaces réservés fournis.

    ./asmcli install \
      --project_id PROJECT_ID \
      --cluster_name CLUSTER_NAME \
      --cluster_location CLUSTER_LOCATION \
      --fleet_id FLEET_PROJECT_ID \
      --output_dir DIR_PATH \
      --enable_all \
      --ca citadel \
      --ca_cert CA_CERT_FILE_PATH \
      --ca_key CA_KEY_FILE_PATH \
      --root_cert ROOT_CERT_FILE_PATH \
      --cert_chain CERT_CHAIN_FILE_PATH
   

   • --project_id, --cluster_name et --cluster_location : spécifiez l'ID du projet dans lequel se trouve le cluster, son nom, ainsi que la zone ou la région du cluster.
   • --fleet_id : ID du projet du projet hôte du parc. Si vous n'incluez pas cette option, asmcli utilise le projet dans lequel le cluster a été créé lors de son enregistrement.
   • --output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp. Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.
     Remarque:Notez ce répertoire --output_dir. Vous devrez le référencer lors du déploiement de passerelles.
   • --enable_all : permet au script d'effectuer les opérations suivantes :
     • Accorder les autorisations IAM requises.
     • Activer les API Google requises.
     • Définir un libellé sur le cluster qui identifie le réseau maillé.
     • Enregistrer le cluster dans le parc si ce n'est déjà fait.

   • -ca citadel : utiliser l'autorité de certification Istio comme autorité de certification.
   • --ca_cert : le certificat intermédiaire
   • --ca_key : la clé du certificat intermédiaire
   • --root_cert : le certificat racine
   • --cert_chain : la chaîne de certificats

   Sur site

   Exécutez les commandes suivantes sur GKE sur VMware ou Google Distributed Cloud Virtual pour Bare Metal afin d'installer le plan de contrôle avec les fonctionnalités par défaut et l'autorité de certification Istio. Saisissez vos valeurs dans les espaces réservés fournis.

   1. Définissez le contexte actuel sur votre cluster d'utilisateur :

      kubectl config use-context CLUSTER_NAME
      

   2. Exécutez asmcli install :

      ./asmcli install \
        --fleet_id FLEET_PROJECT_ID \
        --kubeconfig KUBECONFIG_FILE \
        --output_dir DIR_PATH \
        --platform multicloud \
        --enable_all \
        --ca citadel \
        --ca_cert CA_CERT_FILE_PATH \
        --ca_key CA_KEY_FILE_PATH \
        --root_cert ROOT_CERT_FILE_PATH \
        --cert_chain CERT_CHAIN_FILE_PATH
      

      • --fleet_id : ID du projet du projet hôte du parc.
      • --kubeconfig : chemin d'accès complet au fichier kubeconfig. La variable d'environnement $PWD ne fonctionne pas ici. De plus, les emplacements de fichiers kubeconfig relatifs qui utilisent une valeur `~` ne fonctionneront pas.
      • --output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp. Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.
      • --platform multicloud spécifie que la plate-forme est une plate-forme autre que Google Cloud, par exemple une plate-forme sur site ou multicloud.
      • --enable_all : permet au script d'effectuer les opérations suivantes :
        • Accorder les autorisations IAM requises.
        • Activer les API Google requises.
        • Définir un libellé sur le cluster qui identifie le réseau maillé.
        • Enregistrer le cluster dans le parc si ce n'est déjà fait.
      • -ca citadel : utiliser l'autorité de certification Istio comme autorité de certification.
      • --ca_cert : le certificat intermédiaire
      • --ca_key : la clé du certificat intermédiaire
      • --root_cert : le certificat racine
      • --cert_chain : la chaîne de certificats

   AWS

   Exécutez les commandes suivantes sur GKE sur AWS pour installer le plan de contrôle avec les fonctionnalités par défaut et l'autorité de certification Istio. Saisissez vos valeurs dans les espaces réservés fournis. Vous pouvez choisir d'activer l'entrée du sous-réseau public ou du sous-réseau privé.

   Publique

   1. Définissez le contexte actuel sur votre cluster d'utilisateur :

      kubectl config use-context CLUSTER_NAME
      

   2. Exécutez asmcli install :

      ./asmcli install \
        --fleet_id FLEET_PROJECT_ID \
        --kubeconfig KUBECONFIG_FILE \
        --output_dir DIR_PATH \
        --platform multicloud \
        --enable_all \
        --ca citadel \
        --ca_cert CA_CERT_FILE_PATH \
        --ca_key CA_KEY_FILE_PATH \
        --root_cert ROOT_CERT_FILE_PATH \
        --cert_chain CERT_CHAIN_FILE_PATH
      

      • --fleet_id : ID du projet du projet hôte du parc.
      • --kubeconfig : chemin d'accès complet au fichier kubeconfig. La variable d'environnement $PWD ne fonctionne pas ici. De plus, les emplacements de fichiers kubeconfig relatifs qui utilisent une valeur `~` ne fonctionneront pas.
      • --output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp. Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.
      • --platform multicloud spécifie que la plate-forme est une plate-forme autre que Google Cloud, par exemple une plate-forme sur site ou multicloud.
      • --enable_all : permet au script d'effectuer les opérations suivantes :
        • Accorder les autorisations IAM requises.
        • Activer les API Google requises.
        • Définir un libellé sur le cluster qui identifie le réseau maillé.
        • Enregistrer le cluster dans le parc si ce n'est déjà fait.
      • -ca citadel : utiliser l'autorité de certification Istio comme autorité de certification.
      • --ca_cert : le certificat intermédiaire
      • --ca_key : la clé du certificat intermédiaire
      • --root_cert : le certificat racine
      • --cert_chain : la chaîne de certificats

   Privée

   1. Définissez le contexte actuel sur votre cluster d'utilisateur :

      kubectl config use-context CLUSTER_NAME
      

   2. Enregistrez le fichier YAML suivant dans un fichier appelé istio-operator-internal-lb.yaml :

      apiVersion: install.istio.io/v1alpha1
      kind: IstioOperator
      spec:
        components:
          ingressGateways:
          - enabled: true
            k8s:
              serviceAnnotations:
                service.beta.kubernetes.io/aws-load-balancer-internal: "true"
            name: istio-ingressgateway
      

   3. Exécutez asmcli install :

      ./asmcli install \
        --fleet_id FLEET_PROJECT_ID \
        --kubeconfig KUBECONFIG_FILE \
        --output_dir DIR_PATH \
        --platform multicloud \
        --enable_all \
        --ca citadel \
        --ca_cert CA_CERT_FILE_PATH \
        --ca_key CA_KEY_FILE_PATH \
        --root_cert ROOT_CERT_FILE_PATH \
        --cert_chain CERT_CHAIN_FILE_PATH \
        --custom_overlay istio-operator-internal-lb.yaml
      

      • --fleet_id : ID du projet du projet hôte du parc.
      • --kubeconfig : chemin d'accès complet au fichier kubeconfig. La variable d'environnement $PWD ne fonctionne pas ici. De plus, les emplacements de fichiers kubeconfig relatifs qui utilisent une valeur `~` ne fonctionneront pas.
      • --output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp. Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.
      • --platform multicloud spécifie que la plate-forme est une plate-forme autre que Google Cloud, par exemple une plate-forme sur site ou multicloud.
      • --enable_all : permet au script d'effectuer les opérations suivantes :
        • Accorder les autorisations IAM requises.
        • Activer les API Google requises.
        • Définir un libellé sur le cluster qui identifie le réseau maillé.
        • Enregistrer le cluster dans le parc si ce n'est déjà fait.
      • -ca citadel : utiliser l'autorité de certification Istio comme autorité de certification.
      • --ca_cert : le certificat intermédiaire
      • --ca_key : la clé du certificat intermédiaire
      • --root_cert : le certificat racine
      • --cert_chain : la chaîne de certificats

   Amazon EKS

   Exécutez les commandes suivantes sur Amazon EKS pour installer le plan de contrôle avec les fonctionnalités par défaut et Istio CA. Saisissez vos valeurs dans les espaces réservés fournis.

   1. Définissez le contexte actuel sur votre cluster d'utilisateur :

      kubectl config use-context CLUSTER_NAME
      

   2. Exécutez asmcli install :

      ./asmcli install \
        --fleet_id FLEET_PROJECT_ID \
        --kubeconfig KUBECONFIG_FILE \
        --output_dir DIR_PATH \
        --platform multicloud \
        --enable_all \
        --ca citadel \
        --ca_cert CA_CERT_FILE_PATH \
        --ca_key CA_KEY_FILE_PATH \
        --root_cert ROOT_CERT_FILE_PATH \
        --cert_chain CERT_CHAIN_FILE_PATH
      

      • --fleet_id : ID du projet du projet hôte du parc.
      • --kubeconfig : chemin d'accès complet au fichier kubeconfig. La variable d'environnement $PWD ne fonctionne pas ici. De plus, les emplacements de fichiers kubeconfig relatifs qui utilisent une valeur `~` ne fonctionneront pas.
      • --output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp. Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.
      • --platform multicloud spécifie que la plate-forme est une plate-forme autre que Google Cloud, par exemple une plate-forme sur site ou multicloud.
      • --enable_all : permet au script d'effectuer les opérations suivantes :
        • Accorder les autorisations IAM requises.
        • Activer les API Google requises.
        • Définir un libellé sur le cluster qui identifie le réseau maillé.
        • Enregistrer le cluster dans le parc si ce n'est déjà fait.
      • -ca citadel : utiliser l'autorité de certification Istio comme autorité de certification.
      • --ca_cert : le certificat intermédiaire
      • --ca_key : la clé du certificat intermédiaire
      • --root_cert : le certificat racine
      • --cert_chain : la chaîne de certificats

Installer avec des fonctionnalités facultatives

Un fichier de superposition est un fichier YAML contenant une ressource personnalisée IstioOperator que vous transmettez à asmcli 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 à asmcli. Vous pouvez effectuer plusieurs couches de superpositions. Chaque fichier de superposition remplace la configuration dans les couches précédentes. Nous vous conseillons d'enregistrer les fichiers superposés dans votre système de contrôle des versions.

GKE

Exécutez la commande suivante pour installer le plan de contrôle avec une fonctionnalité facultative. Pour ajouter plusieurs fichiers, spécifiez --custom_overlay et le nom du fichier, par exemple : --custom_overlayoverlay_file1.yaml --custom_overlay overlay_file2.yaml --custom_overlay overlay_file3.yaml. Saisissez vos valeurs dans les espaces réservés fournis.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca \
  --custom_overlay OVERLAY_FILE

• --project_id, --cluster_name et --cluster_location : spécifiez l'ID du projet dans lequel se trouve le cluster, son nom, ainsi que la zone ou la région du cluster.
• --fleet_id : ID du projet du projet hôte du parc. Si vous n'incluez pas cette option, asmcli utilise le projet dans lequel le cluster a été créé lors de son enregistrement.
• --output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp. Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.
  Remarque:Notez ce répertoire --output_dir. Vous devrez le référencer lors du déploiement de passerelles.
• --enable_all : permet au script d'effectuer les opérations suivantes :
  • Accorder les autorisations IAM requises.
  • Activer les API Google requises.
  • Définir un libellé sur le cluster qui identifie le réseau maillé.
  • Enregistrer le cluster dans le parc si ce n'est déjà fait.
• --ca mesh_ca : utiliser Mesh CA comme autorité de certification. Notez que asmcli configure Mesh CA pour utiliser l'identité de charge de travail de parc.
• --custom_overlay : spécifier le nom du fichier de superposition.

En dehors de Google Cloud

Exécutez les commandes suivantes sur GKE sur VMware, Google Distributed Cloud Virtual pour Bare Metal, GKE sur AWS ou Amazon EKS. Saisissez vos valeurs dans les espaces réservés fournis.

1. Définissez le contexte actuel sur votre cluster d'utilisateur :

   kubectl config use-context CLUSTER_NAME
   

2. Exécutez asmcli install pour installer le plan de contrôle avec une fonctionnalité facultative. Pour ajouter plusieurs fichiers, spécifiez --custom_overlay et le nom du fichier, par exemple : --custom_overlayoverlay_file1.yaml --custom_overlay overlay_file2.yaml --custom_overlay overlay_file3.yaml

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca mesh_ca \
     --custom_overlay OVERLAY_FILE
   

   • --fleet_id : ID du projet du projet hôte du parc.
   • --kubeconfig : chemin d'accès complet au fichier kubeconfig. La variable d'environnement $PWD ne fonctionne pas ici. De plus, les emplacements de fichiers kubeconfig relatifs qui utilisent une valeur `~` ne fonctionneront pas.
   • --output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp. Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.
   • --platform multicloud spécifie que la plate-forme est une plate-forme autre que Google Cloud, par exemple une plate-forme sur site ou multicloud.
   • --enable_all : permet au script d'effectuer les opérations suivantes :
     • Accorder les autorisations IAM requises.
     • Activer les API Google requises.
     • Définir un libellé sur le cluster qui identifie le réseau maillé.
     • Enregistrer le cluster dans le parc si ce n'est déjà fait.
   • --ca mesh_ca : utiliser Mesh CA comme autorité de certification. Notez que asmcli configure Mesh CA pour utiliser l'identité de charge de travail de parc.
   • --custom_overlay : spécifier le nom du fichier de superposition.

Installer les passerelles

Anthos Service Mesh vous permet de déployer et de gérer des passerelles avec votre maillage de services. Une passerelle décrit un équilibreur de charge fonctionnant à la périphérie du réseau maillé recevant des connexions HTTP/TCP entrantes ou sortantes. Les passerelles sont des proxys Envoy qui vous permettent de contrôler avec précision le trafic entrant et sortant du réseau maillé.

1. Créez un espace de noms pour la passerelle d'entrée si vous n'en possédez pas déjà un. Les passerelles sont des charges de travail d'utilisateur. Il est déconseillé de les déployer dans l'espace de noms du plan de contrôle. Remplacez GATEWAY_NAMESPACE par le nom de votre espace de noms.

   kubectl create namespace GATEWAY_NAMESPACE
   

   Résultat attendu :

   namespace/GATEWAY_NAMESPACE created
   

2. Activez l'injection automatique sur la passerelle en appliquant un libellé de révision sur l'espace de noms de la passerelle. Le libellé de révision est utilisé par le webhook d'injecteur side-car pour associer les proxys injectés à une révision du plan de contrôle particulière.

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

      kubectl get deploy -n istio-system -l app=istiod -o \
        "jsonpath={.items[*].metadata.labels['istio\.io/rev']}{'\n'}"
      

      La commande génère le libellé de révision correspondant à la version d'Anthos Service Mesh, par exemple : asm-1118-4

   2. Appliquez le libellé de révision à l'espace de noms. Dans la commande suivante, REVISION correspond à la valeur du libellé de révision istiod que vous avez notée à l'étape précédente.

      kubectl label namespace GATEWAY_NAMESPACE \
        istio.io/rev=REVISION --overwrite
      

      Résultat attendu :

      namespace/GATEWAY_NAMESPACE labeled
      

3. Vous pouvez déployer l'exemple de configuration de passerelle d'entrée situé dans le répertoire samples/gateways/istio-ingressgateway/ ou le modifier si nécessaire.

   kubectl apply -n GATEWAY_NAMESPACE \
     -f DIR_PATH/samples/gateways/istio-ingressgateway
   

   Résultat attendu :

   deployment.apps/istio-ingressgateway created
   poddisruptionbudget.policy/istio-ingressgateway created
   horizontalpodautoscaler.autoscaling/istio-ingressgateway created
   role.rbac.authorization.k8s.io/istio-ingressgateway created
   rolebinding.rbac.authorization.k8s.io/istio-ingressgateway created
   service/istio-ingressgateway created
   serviceaccount/istio-ingressgateway created
   

Découvrez les bonnes pratiques liées aux passerelles.

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

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
   

Étapes suivantes

• Découvrez comment configurer un maillage multicluster :

  • Si votre maillage ne comprend que des clusters GKE, consultez la page Configurer un maillage multicluster sur GKE.

  • Si votre maillage contient des clusters en dehors de Google Cloud, consultez la page Configurer un maillage multicluster en dehors de Google Cloud.

• Configurez une adresse IP externe sur site.

• Déployez l'exemple d'application Boutique en ligne.