Anthos Service Mesh et Traffic Director sont désormais Cloud Service Mesh. Pour en savoir plus, consultez la page Présentation de Cloud Service Mesh.

Cette page a été traduite par l'API Cloud Translation.

Définir des configurations avancées

Ce document contient des notes qui peuvent être utiles lors de la configuration de Cloud Service Mesh.

Configurer une seule VM Compute Engine pour le maillage de services Cloud

Utilisez cette procédure comme exemple de mise en œuvre du déploiement du proxy side-car et de l'interception du trafic pour permettre à une VM d'accéder aux services Cloud Service Mesh.

Pour utiliser cette procédure, Docker doit être installé. Suivez les instructions de Docker pour installer Docker Engine.

Si vous suivez ce processus pour configurer Cloud Service Mesh sur une VM unique, certaines tâches de configuration nécessitent que vous ayez accès à un hôte Linux. Cet hôte peut être une machine locale ou une VM exécutée sur votre réseau cloud privé virtuel.

Commencez par télécharger et préparer les fichiers de configuration et les exemples de scripts.

Connectez-vous à l'hôte Linux que vous allez utiliser lors du processus de configuration.
Téléchargez l'archive contenant les fichiers requis sur l'hôte Linux et décompressez-la :
```
wget https://storage.googleapis.com/traffic-director/traffic-director-xdsv3.tar.gz
tar -xzvf traffic-director-xdsv3.tar.gz; cd traffic-director-xdsv3
```
L'archive contient les fichiers suivants :
- sidecar.env : fichier de configuration comprenant les variables d'environnement.
- iptables.sh : script de configuration des règles Netfilter.
- bootstrap_template.yaml : fichier du modèle d'amorçage pour Envoy.
- run.sh : script de premier niveau qui utilise le fichier de configuration sidecar.env afin de configurer iptables pour l'interception et d'exécuter le proxy side-car Envoy.
Sur chaque hôte exécutant un proxy side-car, créez un utilisateur système servant à exécuter le processus associé au proxy Envoy. Il s'agit de l'utilisateur proxy Envoy. La connexion est désactivée pour cet utilisateur proxy Envoy.
```
sudo adduser --system --disabled-login envoy
```
Ouvrez le fichier sidecar.env pour modifier la configuration. Lisez les commentaires intégrés au fichier de configuration pour obtenir une description détaillée de chaque variable.
1. Dans le fichier sidecar.env, définissez la variable ENVOY_USER sur le nom d'utilisateur que vous avez choisi pour l'utilisateur proxy Envoy.

Ensuite, pour chaque hôte de VM qui exécute des applications à l'aide de Cloud Service Mesh, procédez comme suit:

Copiez l'intégralité du répertoire traffic-director-xdsv3 contenant le fichier sidecar.env modifié sur chaque hôte de VM exécutant des applications qui devraient utiliser Cloud Service Mesh.
Ajoutez le script run.sh au script de démarrage de votre système afin de garantir qu'il s'exécute après chaque redémarrage de la VM.
Sur chacun des hôtes de VM, exécutez le script run.sh :
```
cd traffic-director-xdsv3
sudo ./run.sh start
```

Vérifiez que le proxy Envoy a correctement démarré.

sudo ./run.sh status

Vous devriez obtenir le résultat suivant :

OK: Envoy seems to be running.
OK: Traffic interception seems to be enabled.

Vous pouvez vérifier dans quelle direction s'effectue l'interception du trafic à l'aide de la commande suivante :

sudo iptables -S -t nat | grep ISTIO_REDIRECT

Le résultat attendu est :

-N ISTIO_REDIRECT
-A ISTIO_OUTPUT -j ISTIO_REDIRECT
-A ISTIO_REDIRECT -p tcp -j REDIRECT --to-ports 15001`

Cartes des règles de routage

Il existe deux manières de configurer un routage dans une carte de règles de routage.

Vous pouvez activer le routage en fonction de l'adresse IP virtuelle et du port de destination du service. Si vous configurez une adresse IP virtuelle pour votre service en tant que paramètre IPAddress de la règle de transfert, seul le trafic à destination de cette adresse et du port associé est mis en correspondance et acheminé en fonction des paramètres d'hôte et de chemin spécifiés dans le mappage d'URL.

Vous pouvez également définir l'adresse de votre règle de transfert sur 0.0.0.0. Cela permet de configurer les proxys de sorte qu'ils ciblent le trafic uniquement en fonction du port de destination, quelle que soit l'adresse IP de destination de la requête. Le trafic est ensuite acheminé en fonction des paramètres d'hôte et de chemin d'accès spécifiés dans le mappage d'URL.

En conséquence de ces deux approches, les noms d'hôte tels qu'ils sont configurés dans les règles d'hôte doivent, s'ils sont associés à une adresse IP virtuelle et à une paire de ports ou à un port de destination unique (lorsque l'adresse IP virtuelle est 0.0.0.0), être uniques dans votre configuration du maillage de services. Autrement dit, vous ne pouvez pas disposer de deux services différents utilisant des ensembles de backends différents avec un même nom d'hôte.

Quelle que soit la méthode choisie, le trafic à destination de l'adresse IP virtuelle résolue à partir du nom d'hôte ou du nom de domaine complet du service et à destination du port sur lequel votre service écoute doit être intercepté et redirigé vers le proxy side-car. Pour obtenir des informations complètes sur la configuration de l'hôte, consultez la page Configurer une seule VM Compute Engine pour Cloud Service Mesh.

Chaque règle de transfert d'un réseau VPC doit avoir une combinaison unique d'adresse IP et de port par réseau VPC, ce qui inclut également l'adresse 0.0.0.0. Si vous créez plusieurs règles de transfert avec la même adresse IP et le même port dans un réseau VPC particulier, seule la première règle de transfert est valide. Les autres sont ignorées.

Pour éviter de perdre du trafic, suivez les instructions de la section Configuration avancée de l'interception du trafic ci-dessous.

Configuration avancée de l'interception du trafic

Si vos VM exécutent des applications nécessitant un accès aux services configurés par Cloud Service Mesh, vous devez installer un proxy side-car et configurer l'interception du trafic sur les VM pour permettre au proxy side-car de gérer le routage du trafic vers les backends de ces services.

Si l'interception de l'intégralité du trafic sortant d'une VM n'est pas acceptable pour votre déploiement, vous pouvez rediriger un trafic spécifique vers le proxy side-car, tandis que le reste du trafic suit la route standard définie par la configuration de mise en réseau des hôtes.

Pour ce faire, modifiez la configuration de l'hôte de la VM Compute Engine dans la procédure Configuration de Cloud Service Mesh avec des VM et un déploiement Envoy manuel comme suit:

Déterminez la plage d'adresses IP vers laquelle les services contrôlés par Cloud Service Mesh doivent se résoudre. Le trafic destiné à ces adresses IP est intercepté et redirigé vers le proxy side-car. La plage est spécifique à votre déploiement.
Dans le fichier sidecar.env, définissez la valeur de SERVICE_CIDR sur cette plage. Le trafic vers ces adresses IP est redirigé par Netfilter vers un proxy side-car et fait l'objet d'un équilibrage de charge en fonction de la configuration fournie par Cloud Service Mesh.
L'exécution du proxy side-car n'a pas strictement besoin d'être associée à un utilisateur dédié exclu de l'interception du trafic. Toutefois, cela reste recommandé.
Après avoir exécuté le script run.sh, comme indiqué dans la procédure principale, iptables est configuré pour intercepter et rediriger uniquement cette plage spécifique.
Exécutez la commande suivante pour vérifier que netfilter est correctement configuré. Remplacez ${SERVICE_CIDR} par la valeur que vous avez configurée comme plage d'adresses IP interceptée.
```
sudo iptables -L -t nat | grep -E "(ISTIO_REDIRECT).+${SERVICE_CIDR})"
```