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.

Configurer des pods Google Kubernetes Engine avec injection Envoy automatique

Présentation

Dans un maillage de services, le code de votre application n'a pas besoin de connaître la configuration de votre réseau. Pour communiquer, vos applications utilisent à la place un plan de données configuré par un plan de contrôle, lequel gère la mise en réseau du service. Dans ce guide, Cloud Service Mesh est votre plan de contrôle, et les proxys side-car Envoy sont votre plan de données.

L'injecteur de side-car Envoy géré par Google ajoute des proxys side-car Envoy à vos pods Google Kubernetes Engine. Lorsque l'injecteur de side-car Envoy ajoute un proxy, il configure également ce proxy pour gérer le trafic des applications et se connecter à Cloud Service Mesh pour la configuration.

Ce guide vous explique comment configurer simplement Cloud Service Mesh avec Google Kubernetes Engine. Ces étapes constituent la base que vous pouvez étendre à des cas d'utilisation avancés, tels qu'un maillage de services couvrant plusieurs clusters Google Kubernetes Engine et, éventuellement, des VM Compute Engine. Vous pouvez également suivre ces instructions si vous configurez Cloud Service Mesh avec un VPC partagé.

Le processus de configuration implique les étapes suivantes :

Créer un cluster GKE pour vos charges de travail
Installer l'injecteur side-car Envoy et activer l'injection
Déployer un exemple de client et valider l'injection
Déployer un service Kubernetes à des fins de test
Configurer Cloud Service Mesh avec des composants Cloud Load Balancing pour acheminer le trafic vers le service de test
Valider la configuration en envoyant une requête de l'exemple de client au service de test

Présentation des composants déployés dans le cadre de ce guide de configuration (cliquez pour agrandir)

Prérequis

Avant de suivre les instructions de ce guide, effectuez les tâches préalables décrites dans la section Préparer la configuration des API de routage de service avec Envoy et des charges de travail sans proxy.

Pour en savoir plus sur la version d'Envoy compatible, consultez les notes de version de Cloud Service Mesh.

Prérequis supplémentaires avec un VPC partagé

Si vous configurez Cloud Service Mesh dans un environnement VPC partagé, assurez-vous de respecter les points suivants.

Vous disposez des autorisations et des rôles appropriés pour le VPC partagé.
Vous avez configuré les projets et la facturation appropriés.
Vous avez activé la facturation dans les projets.
Vous avez activé les API Cloud Service Mesh et GKE dans chaque projet, y compris le projet hôte.
Vous avez configuré les comptes de service appropriés pour chaque projet.
Vous avez créé un réseau et des sous-réseaux VPC.
Vous avez activé le VPC partagé.

Pour en savoir plus, consultez la section VPC partagé.

Configurer les rôles IAM

Cet exemple de configuration de rôle IAM suppose que le projet hôte du VPC partagé comporte deux sous-réseaux et que le VPC partagé contient deux projets de service.

Dans Cloud Shell, créez un dossier de travail (WORKDIR) dans lequel vous allez créer les fichiers associés à la présente section :
```
mkdir -p ~/td-shared-vpc
cd ~/td-shared-vpc
export WORKDIR=$(pwd)
```

Configurez les autorisations IAM dans le projet hôte afin que les projets de service puissent utiliser les ressources du VPC partagé.

Dans cette étape, vous allez configurer les autorisations IAM de sorte que subnet-1 soit accessible par le projet de service 1 et subnet-2 par le projet de service 2. Vous allez attribuer le rôle IAM "Utilisateur de réseau Compute" (roles/compute.networkUser) au compte de service Compute Engine par défaut et au compte de service de l'API Google Cloud dans chaque projet de service de chaque sous-réseau.

Pour le projet de service 1, configurez les autorisations IAM de subnet-1 :

export SUBNET_1_ETAG=$(gcloud beta compute networks subnets get-iam-policy subnet-1 --project ${HOST_PROJECT} --region ${REGION_1} --format=json | jq -r '.etag')

cat > subnet-1-policy.yaml <<EOF
bindings:
- members:
  - serviceAccount:${SVC_PROJECT_1_API_SA}
  - serviceAccount:${SVC_PROJECT_1_GKE_SA}
  role: roles/compute.networkUser
etag: ${SUBNET_1_ETAG}
EOF

gcloud beta compute networks subnets set-iam-policy subnet-1 \
subnet-1-policy.yaml \
    --project ${HOST_PROJECT} \
    --region ${REGION_1}

Pour le projet de service 2, configurez les autorisations IAM de subnet-2 :

export SUBNET_2_ETAG=$(gcloud beta compute networks subnets get-iam-policy subnet-2 --project ${HOST_PROJECT} --region ${REGION_2} --format=json | jq -r '.etag')

cat > subnet-2-policy.yaml <<EOF
bindings:
- members:
  - serviceAccount:${SVC_PROJECT_2_API_SA}
  - serviceAccount:${SVC_PROJECT_2_GKE_SA}
  role: roles/compute.networkUser
etag: ${SUBNET_2_ETAG}
EOF

gcloud beta compute networks subnets set-iam-policy subnet-2 \
subnet-2-policy.yaml \
    --project ${HOST_PROJECT} \
    --region ${REGION_2}

Pour chaque projet de service, vous devez attribuer le rôle IAM "Utilisateur de l'agent de service hôte Kubernetes Engine" (roles/container.hostServiceAgentUser) au compte de service GKE du projet hôte:
```
gcloud projects add-iam-policy-binding ${HOST_PROJECT} \
    --member serviceAccount:${SVC_PROJECT_1_GKE_SA} \
    --role roles/container.hostServiceAgentUser

gcloud projects add-iam-policy-binding ${HOST_PROJECT} \
    --member serviceAccount:${SVC_PROJECT_2_GKE_SA} \
    --role roles/container.hostServiceAgentUser
```
Ce rôle permet au compte de service GKE du projet de service d'utiliser le compte de service GKE du projet hôte pour configurer des ressources réseau partagées.
Dans le projet hôte, attribuez le rôle IAM de lecteur de réseau Compute (roles/compute.networkViewer) au compte de service par défaut Compute Engine de chaque projet de service.
```
gcloud projects add-iam-policy-binding ${SVC_PROJECT_1} \
    --member serviceAccount:${SVC_PROJECT_1_COMPUTE_SA} \
    --role roles/compute.networkViewer

gcloud projects add-iam-policy-binding ${SVC_PROJECT_2} \
    --member serviceAccount:${SVC_PROJECT_2_COMPUTE_SA} \
    --role roles/compute.networkViewer
```
Lorsque le proxy side-car Envoy se connecte au service xDS (API Traffic Director), il utilise le compte de service de l'hôte de la machine virtuelle (VM) Compute Engine ou de l'instance du nœud GKE. Le compte de service doit disposer de l'autorisation IAM compute.globalForwardingRules.get au niveau du projet. Le rôle "Lecteur de réseau Compute" est suffisant pour cette étape.

Configurer les informations du projet

Si vous n'avez pas encore créé de projet Google Cloud ni installé la Google Cloud CLI, suivez ces instructions. Si vous n'avez pas encore installé kubectl, suivez ces instructions.

# The project that contains your GKE cluster.
export CLUSTER_PROJECT_ID=YOUR_CLUSTER_PROJECT_NUMBER_HERE
# The name of your GKE cluster.
export CLUSTER=YOUR_CLUSTER_NAME
# The channel of your GKE cluster. Eg: rapid, regular, stable. This channel
# should match the channel of your GKE cluster.
export CHANNEL=YOUR_CLUSTER_CHANNEL
# The location of your GKE cluster, Eg: us-central1 for regional GKE cluster,
# us-central1-a for zonal GKE cluster
export LOCATION=ZONE

# The network name of the traffic director load balancing API.
export MESH_NAME=default
# The project that holds the mesh resources.
export MESH_PROJECT_NUMBER=YOUR_PROJECT_NUMBER_HERE

export TARGET=projects/${MESH_PROJECT_NUMBER}/global/networks/${MESH_NAME}

gcloud config set project ${CLUSTER_PROJECT_ID}

Si vous utilisez les nouvelles API de routage de service, suivez les instructions ci-dessous pour définir MESH_NAME, MESH_PROJECT_NUMBER et TARGET:

# The mesh name of the traffic director load balancing API.
export MESH_NAME=YOUR_MESH_NAME
# The project that holds the mesh resources.
export MESH_PROJECT_NUMBER=YOUR_PROJECT_NUMBER_HERE

export TARGET=projects/${MESH_PROJECT_NUMBER}/locations/global/meshes/${MESH_NAME}

Dans la plupart des scénarios, CLUSTER_PROJECT_ID et MESH_PROJECT_NUMBER font référence au même projet. Toutefois, si vous configurez un autre projet, par exemple lorsque vous utilisez un VPC partagé, CLUSTER_PROJECT_ID fait référence à l'ID du projet contenant votre cluster GKE, et MESH_PROJECT_NUMBER fait référence au numéro du projet contenant les ressources. Assurez-vous d'avoir configuré les autorisations appropriées pour autoriser l'envoy injecté à récupérer des configurations à partir de

Activer l'API Mesh Config

Activez l'API suivante pour commencer à utiliser l'injecteur sidecar géré par Google.

gcloud services enable --project=${CLUSTER_PROJECT_ID} meshconfig.googleapis.com

Créer un cluster GKE pour vos charges de travail

Les clusters GKE doivent répondre aux exigences suivantes pour être compatibles avec Cloud Service Mesh:

La compatibilité avec les groupes de points de terminaison du réseau doit être activée. Pour en savoir plus et obtenir des exemples, reportez-vous à la section Groupes de points de terminaison du réseau autonomes.
Le compte de service de vos nœuds/pods GKE doit être autorisé à accéder à l'API Traffic Director. Pour en savoir plus sur les autorisations requises, consultez la section Autoriser le compte de service à accéder à l'API Traffic Director.

Créer le cluster GKE

Créez un cluster GKE dans la zone de votre choix, par exemple us-central1-a.

gcloud container clusters create YOUR_CLUSTER_NAME \
  --zone ZONE \
  --scopes=https://www.googleapis.com/auth/cloud-platform \
  --enable-ip-alias

Faire pointer kubectl vers le cluster que vous venez de créer

Remplacez le contexte actuel de kubectl par le nouveau cluster en exécutant la commande suivante :

gcloud container clusters get-credentials traffic-director-cluster \
    --zone ZONE

Appliquer les configurations pour le webhook de modification

Les sections suivantes fournissent des instructions pour appliquer MutatingWebhookConfiguration au cluster. Lorsqu'un pod est créé, le contrôleur d'admission du cluster est appelé. Le contrôleur d'admission communique avec l'injecteur de sidecar géré pour ajouter le conteneur Envoy au pod.

Appliquez les configurations de webhook de modification suivantes à votre cluster.

cat <<EOF | kubectl apply -f -
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
  labels:
    app: sidecar-injector
  name: td-mutating-webhook
webhooks:
- admissionReviewVersions:
  - v1beta1
  - v1
  clientConfig:
    url: https://meshconfig.googleapis.com/v1internal/projects/${CLUSTER_PROJECT_ID}/locations/${LOCATION}/clusters/${CLUSTER}/channels/${CHANNEL}/targets/${TARGET}:tdInject
  failurePolicy: Fail
  matchPolicy: Exact
  name: namespace.sidecar-injector.csm.io
  namespaceSelector:
    matchExpressions:
    - key: td-injection
      operator: Exists
  reinvocationPolicy: Never
  rules:
  - apiGroups:
    - ""
    apiVersions:
    - v1
    operations:
    - CREATE
    resources:
    - pods
    scope: '*'
  sideEffects: None
  timeoutSeconds: 30
EOF

Activer l'injection de side-car

La commande suivante active l'injection pour l'espace de noms default. L'injecteur de side-car injecte des conteneurs side-car dans les pods créés sous cet espace de noms :

kubectl label namespace default td-injection=enabled

Vous pouvez vérifier que l'espace de noms default est correctement activé en exécutant la commande suivante :

kubectl get namespace -L td-injection

Cette opération devrait renvoyer les valeurs ci-dessous :

NAME              STATUS   AGE     TD-INJECTION
default           Active   7d16h   enabled

Si vous configurez la sécurité du service pour Cloud Service Mesh avec Envoy, revenez à la section Configurer un service de test du guide de configuration.

Déployer un exemple de client et valider l'injection

Cette section explique comment déployer un exemple de pod exécutant Busybox, qui fournit une interface simple permettant d'accéder à un service de test. Dans un déploiement réel, vous déploieriez votre propre application cliente.

cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: client
  name: busybox
spec:
  replicas: 1
  selector:
    matchLabels:
      run: client
  template:
    metadata:
      labels:
        run: client
    spec:
      containers:
      - name: busybox
        image: busybox
        command:
        - sh
        - -c
        - while true; do sleep 1; done
EOF

Le pod Busybox se compose de deux conteneurs. Le premier conteneur est le client basé sur l'image Busybox et le second est le proxy Envoy injecté par l'injecteur de side-car. Exécutez la commande suivante pour obtenir plus d'informations sur le pod :

kubectl describe pods -l run=client

Cette opération devrait renvoyer les valeurs ci-dessous :

…
Init Containers:
# Istio-init sets up traffic interception for the pod.
  Istio-init:
…
Containers:
# busybox is the client container that runs application code.
  busybox:
…
# Envoy is the container that runs the injected Envoy proxy.
  envoy:
…

Proxy Cloud Service Mesh

L'injecteur side-car géré utilisera l'image du proxy Cloud Service Mesh comme proxy. Le proxy Cloud Service Mesh est un conteneur side-car chargé de démarrer un proxy Envoy pour les instances compatibles avec le maillage. L'image du proxy utilise l'image envoy OSS ainsi qu'un agent de proxy chargé de démarrer l'envoy, de fournir la configuration de démarrage et de vérifier l'état de l'envoy. Les versions d'image du proxy Cloud Service Mesh correspondent à la version Envoy Open Source. Vous pouvez suivre les images de proxy disponibles ici : https://gcr.io/gke-release/asm/csm-mesh-proxy.

Le proxy de réseau Cloud Service Mesh qui est injecté varie en fonction du canal que l'utilisateur a choisi pour le cluster GKE. La version d'Envoy est régulièrement mise à jour en fonction des versions actuelles d'Envoy Open Source et est testée avec la version spécifique de GKE pour garantir la compatibilité.

Version du proxy Cloud Service Mesh

Le tableau suivant montre le mappage entre le canal de cluster GKE actuel et la version du proxy Cloud Service Mesh:

Canal	Version du proxy Cloud Service Mesh
Élasticité	1.29.9-gke.3
Standard	1.28.7-gke.3
Stable	1.27.7-gke.3

Mise à niveau du proxy Cloud Service Mesh

Nous vous recommandons vivement de passer à la dernière version. Bien que le maillage de services fonctionne correctement lorsque le plan de contrôle et les proxys utilisent des versions différentes, nous vous recommandons de mettre à jour les proxys afin qu'ils soient configurés avec la nouvelle version de Cloud Service Mesh.

L'injecteur side-car géré s'occupe de la version d'Envoy, qui injecte toujours la dernière version d'Envoy qualifiée par Google. Si la version du proxy Cloud Service Mesh est plus récente que la version du proxy, redémarrez les proxys pour vos services.

kubectl rollout restart deployment -n YOUR_NAMESPACE_HERE

Déployer un service Kubernetes à des fins de test

Les sections suivantes fournissent des instructions permettant de configurer un service de test que vous utiliserez ultérieurement dans ce guide pour valider votre configuration de bout en bout.

Configurer des services GKE avec des NEG

Les services GKE doivent être exposés via des groupes de points de terminaison du réseau (NEG) afin que vous puissiez les configurer en tant que backends d'un service de backend Cloud Service Mesh. Ajoutez l'annotation NEG à votre spécification de service Kubernetes et choisissez un nom (en remplaçant NEG-NAME dans l'exemple ci-dessous) afin de pouvoir la retrouver facilement par la suite. Vous avez besoin du nom lorsque vous associez le NEG à votre service de backend Cloud Service Mesh. Pour en savoir plus sur l'annotation de NEG, consultez la section Nommer les NEG.

...
metadata:
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "service-test-neg"}}}'
spec:
  ports:
  - port: 80
    name: service-test
    protocol: TCP
    targetPort: 8000

Cette annotation crée un NEG autonome contenant des points de terminaison correspondant aux adresses IP et aux ports des pods du service. Pour en savoir plus et obtenir des exemples, reportez-vous à la section Groupes de points de terminaison du réseau autonomes.

L'exemple de service suivant inclut l'annotation NEG. Le service diffuse le nom d'hôte via HTTP sur le port 80. Exécutez la commande suivante pour obtenir le service et le déployer sur votre cluster GKE.

wget -q -O - \
https://storage.googleapis.com/traffic-director/demo/trafficdirector_service_sample.yaml \
| kubectl apply -f -

Vérifiez que le nouveau service est créé et que le pod de l'application est en cours d'exécution :

kubectl get svc

La sortie devrait ressembler à ce qui suit :

NAME             TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service-test     ClusterIP   10.71.9.71   none          80/TCP    41m
[..skip..]

Vérifiez que le pod de l'application associé à ce service est en cours d'exécution :

kubectl get pods

Cette opération renvoie:

NAME                        READY     STATUS    RESTARTS   AGE
app1-6db459dcb9-zvfg2       2/2       Running   0          6m
busybox-5dcf86f4c7-jvvdd    2/2       Running   0          10m
[..skip..]

Enregistrer le nom du NEG

Recherchez le NEG créé à partir de l'exemple ci-dessus et notez son nom pour l'utiliser dans la configuration de Cloud Service Mesh dans la section suivante.

gcloud compute network-endpoint-groups list

Cela renvoie le résultat suivant :

NAME                       LOCATION            ENDPOINT_TYPE       SIZE
service-test-neg           ZONE     GCE_VM_IP_PORT      1

Enregistrez le nom du NEG dans la variable NEG_NAME :

NEG_NAME=$(gcloud compute network-endpoint-groups list \
| grep service-test | awk '{print $1}')

Configurer Cloud Service Mesh avec des composants Cloud Load Balancing

Cette section configure Cloud Service Mesh à l'aide des ressources d'équilibrage de charge de Compute Engine. Cela permet au proxy side-car de l'exemple de client de recevoir la configuration de Cloud Service Mesh. Les requêtes sortantes de l'exemple de client sont gérées par le proxy side-car et acheminées vers le service de test.

Vous devez configurer les composants suivants :

Une vérification de l'état Pour en savoir plus sur les vérifications d'état, consultez les pages Concepts de la vérification d'état et Créer des vérifications d'état.
Un service de backend Pour en savoir plus sur les services de backend, consultez la page Services de backend.
Une carte des règles de routage. Cela inclut la création d'une règle de transfert, d'un proxy HTTP cible et d'un mappage d'URL. Pour en savoir plus, consultez les pages Utiliser des règles de transfert pour Cloud Service Mesh, Utiliser des proxys cibles pour Cloud Service Mesh et Utiliser des mappages d'URL.

Créer la vérification d'état et la règle de pare-feu

Suivez les instructions ci-dessous pour créer une vérification de l'état et la règle de pare-feu requise pour les tests de vérification de l'état d'état. Pour en savoir plus, consultez la section Règles de pare-feu pour les vérifications d'état.

Console

Accédez à la page "Vérifications d'état" dans Google Cloud Console.
Accéder à la page "Vérifications d'état"
Cliquez sur Créer une vérification d'état.
Dans le champ du nom, saisissez td-gke-health-check.
Comme protocole, sélectionnez HTTP.
Cliquez sur Créer.
Accédez à la page Stratégies de pare-feu de la console Google Cloud.
Accéder à la page "Stratégies de pare-feu"
Cliquez sur Créer des règles de pare-feu.
Sur la page Créer une règle de pare-feu, fournissez les informations suivantes :
- Nom : attribuez un nom à la règle. Pour cet exemple, utilisez fw-allow-health-checks.
- Réseau : choisissez un réseau VPC.
- Priorité : saisissez un numéro pour la priorité. Plus la valeur est faible, plus la priorité est élevée. Assurez-vous que la règle de pare-feu a une priorité plus élevée que les autres règles susceptibles de refuser le trafic entrant.
- Sens du trafic: choisissez Entrée.
- Action en cas de correspondance: sélectionnez Autoriser.
- Cibles : sélectionnez Toutes les instances du réseau.
- Filtre source: choisissez le type de plage d'adresses IP approprié.
- Plages d'adresses IP sources : 35.191.0.0/16,130.211.0.0/22
- Filtre de destination: sélectionnez le type d'adresse IP.
- Protocoles et ports: cliquez sur Ports et protocoles spécifiés, puis cochez tcp. TCP est le protocole sous-jacent de tous les protocoles de vérification d'état.
- Cliquez sur Create (Créer).

gcloud

Créez la vérification de l'état.

gcloud compute health-checks create http td-gke-health-check \
  --use-serving-port

Créez la règle de pare-feu pour autoriser les plages d'adresses IP du vérificateur d'état.

gcloud compute firewall-rules create fw-allow-health-checks \
  --action ALLOW \
  --direction INGRESS \
  --source-ranges 35.191.0.0/16,130.211.0.0/22 \
  --rules tcp

Créer un service de backend

Créez un service de backend global avec un schéma d'équilibrage de charge INTERNAL_SELF_MANAGED. Dans la console Google Cloud, le schéma d'équilibrage de charge est défini implicitement. Ajoutez la vérification d'état au service de backend.

Console

Accédez à la page Cloud Service Mesh de la console Google Cloud.
Accéder à la page Cloud Service Mesh
Dans l'onglet Services, cliquez sur Créer un service.
Cliquez sur Continuer.
Pour le nom du service, saisissez td-gke-service.
Sélectionnez Network (Réseau), que vous avez configuré dans le ConfigMap Cloud Service Mesh.
Sous Type de backend, sélectionnez Groupes de points de terminaison du réseau.
Sélectionnez le groupe de points de terminaison du réseau que vous avez créé.
Définissez le Nombre maximal de RPS sur 5.
Définissez le mode d'équilibrage sur Fréquence.
Cliquez sur OK.
Sous Vérification d'état, sélectionnez td-gke-health-check, qui est la vérification d'état que vous avez créée.
Cliquez sur Continuer.

gcloud

Créez le service de backend et associez la vérification d'état au service de backend.

gcloud compute backend-services create td-gke-service \
 --global \
 --health-checks td-gke-health-check \
 --load-balancing-scheme INTERNAL_SELF_MANAGED

Ajoutez le NEG créé précédemment en tant que backend au service de backend. Si vous configurez Cloud Service Mesh avec un proxy TCP cible, vous devez utiliser le mode d'équilibrage UTILIZATION. Si vous utilisez un proxy cible HTTP ou HTTPS, vous pouvez utiliser le mode RATE.
```
gcloud compute backend-services add-backend td-gke-service \
 --global \
 --network-endpoint-group ${NEG_NAME} \
 --network-endpoint-group-zone ZONE \
 --balancing-mode [RATE | UTILIZATION] \
 --max-rate-per-endpoint 5
```

Créer la carte des règles de routage

La carte des règles de routage définit la manière dont Cloud Service Mesh achemine le trafic dans votre maillage. Dans le cadre de la carte des règles de routage, vous configurez une adresse IP virtuelle et un ensemble de règles de gestion du trafic associées, comme par exemple le routage basé sur l'hôte. Lorsqu'une application envoie une requête à l'adresse IP virtuelle, le proxy side-car Envoy associé effectue les opérations suivantes :

intercepte la requête ;
l'évalue en fonction des règles de gestion du trafic dans le mappage d'URL ;
sélectionne un service de backend en fonction du nom d'hôte spécifié dans la requête ;
choisit un backend ou un point de terminaison associé au service de backend sélectionné ;
envoie le trafic vers ce backend ou point de terminaison.

Console

Dans la console, le proxy cible est associé à la règle de transfert. Lorsque vous créez la règle de transfert, Google Cloud crée automatiquement un proxy HTTP cible et l'associe au mappage d'URL.

La règle de routage comprend la règle de transfert ainsi que les règles d'hôte et de chemin d'accès (également appelées mappage d'URL).

Accédez à la page Cloud Service Mesh de la console Google Cloud.
Accéder à la page Cloud Service Mesh
Cliquez sur Cartes des règles de routage.
Cliquez sur Créer une règle de routage.
Saisissez td-gke-url-map dans le champ Nom du mappage d'URL.
Cliquez sur Ajouter une règle de transfert.
Pour le nom de la règle de transfert, saisissez td-gke-forwarding-rule.
Sélectionnez votre réseau.
Sélectionnez votre adresse IP interne.
Cliquez sur Enregistrer.
Vous pouvez également ajouter des règles personnalisées d'hôte et de chemin d'accès ou conserver les règles de chemin d'accès par défaut.
Définissez l'hôte sur service-test.
Cliquez sur Enregistrer.

gcloud

Créez un mappage d'URL qui utilise td-gke-service comme service de backend par défaut.
```
gcloud compute url-maps create td-gke-url-map \
   --default-service td-gke-service
```
Créez un outil de mise en correspondance des chemins d'accès de mappage d'URL ainsi qu'une règle d'hôte pour acheminer le trafic de votre service en fonction du nom d'hôte et du chemin d'accès. Cet exemple utilise service-test comme nom de service avec un outil de mise en correspondance des chemins d'accès par défaut qui correspond à toutes les requêtes de chemin pour cet hôte (/*).
```
gcloud compute url-maps add-path-matcher td-gke-url-map \
   --default-service td-gke-service \
   --path-matcher-name td-gke-path-matcher

gcloud compute url-maps add-host-rule td-gke-url-map \
   --hosts service-test \
   --path-matcher-name td-gke-path-matcher
```

Créez le proxy HTTP cible.

gcloud compute target-http-proxies create td-gke-proxy \
   --url-map td-gke-url-map

Créez la règle de transfert.

gcloud compute forwarding-rules create td-gke-forwarding-rule \
  --global \
  --load-balancing-scheme=INTERNAL_SELF_MANAGED \
  --address=0.0.0.0 \
  --target-http-proxy=td-gke-proxy \
  --ports 80 --network default

À ce stade, Cloud Service Mesh configure vos proxys side-car de manière à acheminer les requêtes qui spécifient le nom d'hôte service-test vers les backends de td-gke-service. Dans ce cas, ces backends sont des points de terminaison dans le groupe de points de terminaison du réseau associé au service de test Kubernetes que vous avez déployé précédemment.

Vérifier la configuration

Cette section explique comment vérifier que le trafic envoyé depuis l'exemple de client Busybox est acheminé vers votre service Kubernetes service-test. Pour envoyer une requête de test, vous pouvez accéder à une interface système sur l'un des conteneurs et exécuter la commande de vérification suivante. Un pod service-test doit renvoyer le nom d'hôte du pod de diffusion.

# Get the name of the pod running Busybox.
BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}')

# Command to execute that tests connectivity to the service service-test at
# the VIP 10.0.0.1. Because 0.0.0.0 is configured in the forwarding rule, this
# can be any VIP.
TEST_CMD="wget -q -O - 10.0.0.1; echo"

# Execute the test command on the pod.
kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"

Voici comment la configuration est vérifiée :

L'exemple de client a envoyé une requête spécifiant le nom d'hôte service-test.
L'exemple de client dispose d'un proxy side-car Envoy injecté par l'injecteur side-car Envoy.
Le proxy side-car a intercepté la requête.
À l'aide du mappage d'URL, Envoy a mis en correspondance le nom d'hôte service-test et le service Cloud Service Mesh td-gke-service.
Envoy a choisi un point de terminaison dans le groupe de points de terminaison du réseau associé à td-gke-service.
Envoy a envoyé la requête à un pod associé au service Kubernetes service-test.

Migrer vers l'injecteur de side-car géré

Ce tutoriel vous explique comment migrer une application de l'ancien injecteur sidecar Cloud Service Mesh sur GKE (avec un injecteur sidecar dans le cluster) vers un injecteur sidecar géré.

Désactiver l'injection side-car au sein du cluster

Les commandes suivantes désactivent l'ancien injecteur side-car au sein du cluster pour l'espace de noms par défaut.

kubectl label namespace default istio-injection-

Nettoyer l'injecteur side-car dans le cluster

Téléchargez et extrayez l'ancien injecteur de side-car Envoy.

wget https://storage.googleapis.com/traffic-director/td-sidecar-injector-xdsv3.tgz
tar -xzvf td-sidecar-injector-xdsv3.tgz
cd td-sidecar-injector-xdsv3

Supprimer les ressources de l'injecteur side-car dans le cluster

kubectl delete -f specs/

Étape suivante

En savoir plus sur la gestion avancée du trafic.
Découvrez la sécurité du service Cloud Service Mesh.
Découvrez comment configurer l'observabilité avec Envoy.
Découvrez comment résoudre les problèmes de déploiement de Cloud Service Mesh.
Découvrez les options de configuration de pod Google Kubernetes Engine avec injection Envoy automatique.