Anthos Service Mesh et Traffic Director sont désormais Cloud Service Mesh. Pour en savoir plus, consultez la 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 remarques qui peuvent vous être utiles lors de la configuration de Cloud Service Mesh.

Configurer une seule VM Compute Engine pour Cloud Service Mesh

Utilisez cette procédure comme exemple de mise en œuvre du déploiement d'un proxy side-car et de l'interception du trafic pour autoriser une VM à 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 ces instructions pour configurer Cloud Service Mesh sur une seule VM, 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, effectuez procédez comme suit:

Copiez l'intégralité du répertoire traffic-director-xdsv3 contenant le fichier sidecar.env vers chaque hôte de VM qui exécute les 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. Reportez-vous à la section Configurer une seule VM Compute Engine pour Cloud Service Mesh pour obtenir des informations complètes sur la configuration de l'hôte.

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 qui ont besoin d'accéder aux services configurés par Cloud Service Mesh, vous devez installer un proxy side-car et configurer l'interception du trafic sur les VM. Cela permet 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 Configuration de Cloud Service Mesh avec des VM et déploiement Envoy manuel comme suit:

Déterminer la plage d'adresses IP contrôlée par Cloud Service Mesh doivent être résolus. 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 à destination de 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})"
```