Anthos Service Mesh 1.10 est arrivé en fin de vie et n'est plus pris en charge. Consultez la section Mettre à niveau à partir de versions antérieures.

Accédez à la documentation la plus récente ou sélectionnez une autre version disponible :

Versions disponibles

1.20 (dernière version)
1.19
1.18
1.17
1.16
1.15
1.14
1.13
1.12

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.10.6-asm.2.
Déployez ou redéployez vos charges de travail pour injecter des proxys side-car.

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écharger asmcli
Accordez des autorisations d'administrateur de cluster.
Validez le projet et le cluster

Installer Anthos Service Mesh

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

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.
Vous pouvez également installer une passerelle d'entrée.
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.
Si vous installez Anthos Service Mesh sur plusieurs clusters, exécutez asmcli install sur chaque cluster. Une fois qu'Anthos Service Mesh est installé sur tous les clusters, consultez la page Configurer un réseau maillé multicluster sur site.
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.

GKE

Exécutez la commande suivante pour installer le nouveau plan de contrôle avec les fonctionnalités par défaut. 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.
--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

Définissez le contexte actuel sur votre cluster d'utilisateur :
```
kubectl config use-context CLUSTER_NAME
```
Exécutez la commande suivante pour installer le nouveau plan de contrôle avec les fonctionnalités par défaut. Saisissez vos valeurs dans les espaces réservés fournis.
```
./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 au fichier kubeconfig. Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.
- --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 sur site est utilisée.
- --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 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.

Créez un répertoire pour les certificats et les clés :
```
mkdir -p certs && \
pushd certs
```
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
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.
Revenez au répertoire précédent :
```
popd
```
Exécutez asmcli pour installer un réseau maillé à l'aide de l'autorité de certification Istio :
GKE
```
 ./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.
- --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
1. Définissez le contexte actuel sur votre cluster d'utilisateur :
```
kubectl config use-context CLUSTER_NAME
```
2. Exécutez la commande suivante pour installer Anthos Service Mesh avec les fonctionnalités par défaut et Istio CA :
```
./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 au fichier kubeconfig. Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.
  - --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 sur site est utilisée.
  - --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.

GKE

Exécutez la commande suivante pour installer le nouveau plan de contrôle avec les fonctionnalités par défaut. 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.
--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.

Sur site

Définissez le contexte actuel sur votre cluster d'utilisateur :
```
kubectl config use-context CLUSTER_NAME
```
Exécutez la commande suivante pour installer le nouveau plan de contrôle avec les fonctionnalités par défaut. Saisissez vos valeurs dans les espaces réservés fournis.
```
./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 au fichier kubeconfig. Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.
- --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 sur site est utilisée.
- --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é.

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
```
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. Le libellé de révision que vous utilisez varie selon que vous avez déployé Anthos Service Mesh géré ou le plan de contrôle dans le cluster.
1. Exécutez la commande suivante pour localiser le libellé de révision sur istiod :
```
kubectl -n istio-system get pods -l app=istiod --show-labels
```
  La sortie ressemble à ceci :
```
NAME                                READY   STATUS    RESTARTS   AGE   LABELS
istiod-asm-1106-2-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-1106-2,istio=istiod,pod-template-hash=5788d57586
istiod-asm-1106-2-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-1106-2,istio=istiod,pod-template-hash=5788d57586
```
  Dans le résultat, sous la colonne LABELS, notez la valeur du libellé de révision istiod, qui suit le préfixe istio.io/rev=. Dans cet exemple, la valeur est asm-1106-2.
2. Appliquez le libellé de révision à 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-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.
Accédez au répertoire que vous avez spécifié dans --output_dir.
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 samples/gateways/istio-ingressgateway
```

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 :

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

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

La sortie ressemble à ceci :

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

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

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

Étape suivante

GKE : Configurer un réseau multimaillage
Sur site :
- Configurer une adresse IP externe
- Configurer un maillage multicluster