Configurer des pods Google Kubernetes Engine avec injection Envoy manuelle

Ce guide explique comment configurer les hôtes de pods Kubernetes ou Google Kubernetes Engine et les composants d'équilibrage de charge requis par Traffic Director.

Avant de suivre les instructions de ce guide, consultez la section Préparer la configuration de Traffic Director et assurez-vous d'avoir rempli les conditions préalables.

Vous pouvez configurer Traffic Director à l'aide du SDK d'équilibrage de charge de Compute Engine ou des API REST. Consultez la documentation de référence de l'API Cloud Load Balancing et de gcloud.

Configurer des clusters GKE/Kubernetes pour Traffic Director

Cette section décrit les étapes nécessaires pour permettre aux clusters GKE/Kubernetes de fonctionner avec Traffic Director.

Créer le cluster GKE

Les clusters GKE doivent répondre aux exigences suivantes :

  • 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. La fonctionnalité de NEG autonome de Traffic Director est accessible à tous les utilisateurs (disponibilité générale).
  • Les instances des nœuds du cluster doivent disposer d'une autorisation pour accéder à l'API Traffic Director.
  • Les conteneurs doivent avoir accès à l'API Traffic Director, protégée par l'authentification OAuth. Pour en savoir plus, consultez la section Configuration de l'hôte.

L'exemple suivant montre comment créer un cluster GKE appelé traffic-director-cluster dans la zone us-central1-a.

Console

Pour créer un cluster à l'aide de la console Google Cloud, procédez comme suit :

  1. Accédez au menu "Kubernetes Engine" dans la console Google Cloud.

    Accéder au menu Google Kubernetes Engine

  2. Cliquez sur Créer un cluster.

  3. Remplissez les champs suivants :

    • Nom : saisissez traffic-director-cluster.
    • Type d'emplacement : Zonal.
    • Zone : us-central1-a.

  4. Dans le volet de navigation, cliquez sur default-pool sous Pools de nœuds.

  5. Le champ Taille indique le nombre de nœuds à créer dans le cluster. Vous devez disposer d'un quota de ressources disponible pour les nœuds et les ressources associées (telles que les routes de pare-feu).

  6. Dans le volet de navigation, sous default-pool, cliquez sur Nœuds.

  7. Le champ Type de machine indique le type de machine Compute Engine à utiliser pour les instances. Chaque type de machine est facturé différemment. Pour en savoir plus sur les tarifs par type de machine, consultez la page Tarifs de Compute Engine.

  8. Dans le volet de navigation, sous default-pool, cliquez sur Sécurité.

  9. Dans la section Niveaux d'accès, cliquez sur Autoriser l'accès complet à l'ensemble des API Cloud.

  10. Personnalisez votre cluster si nécessaire.

  11. Cliquez sur Créer.

Après avoir créé un cluster dans la console Google Cloud, vous devez configurer kubectl pour interagir avec le cluster. Pour en savoir plus, consultez la section Générer une entrée kubeconfig.

gcloud

gcloud container clusters create traffic-director-cluster \
  --zone us-central1-a \
  --scopes=https://www.googleapis.com/auth/cloud-platform \
  --enable-ip-alias

Obtenir les droits requis pour le cluster GKE

Pour GKE, exécutez la commande suivante pour basculer vers le cluster(2) que vous venez de créer. Cette commande redirige kubectl vers le cluster approprié.

gcloud container clusters get-credentials traffic-director-cluster \
    --zone us-central1-a

Configurer les services GKE/Kubernetes

Cette section montre comment préparer les spécifications du déploiement de Kubernetes pour qu'elles fonctionnent avec Traffic Director. Il s'agit de configurer des services avec des NEG et d'injecter des proxy side-car dans les pods nécessitant un accès aux services gérés par Traffic Director.

Configurer la règle de pare-feu

Pour vérifier que les pods de backend sont en cours d'exécution, vous devez configurer une règle de pare-feu autorisant les plages d'adresses IP du vérificateur d'état.

Console

  1. Accédez à la page Stratégies de pare-feu de la console Google Cloud.
    Accéder à la page "Stratégies de pare-feu"
  2. Cliquez sur Créer des règles de pare-feu.
  3. 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: sélectionnez 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 Créer.

gcloud

  1. Exécutez la commande gcloud suivante pour créer une règle de pare-feu nommée fw-allow-health-checks qui autorise les connexions entrantes aux instances de votre réseau ayant le tag allow-health-checks. Remplacez NETWORK_NAME par le nom du réseau.

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

Pour en savoir plus, consultez la section Configurer la règle de pare-feu pour les vérifications d'état.

Configurer des services GKE/Kubernetes avec des groupes de points de terminaison du réseau

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 Traffic Director. 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 Traffic Director. 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": "NEG-NAME"}}}'
spec:
  ports:
  - port: 80
    name: service-test
    protocol: TCP
    targetPort: 8000

Un groupe de points de terminaison du réseau autonome est créé pour chaque service. Il contient les points de terminaison correspondant aux adresses IP et aux ports du pod. Pour en savoir plus et obtenir des exemples, reportez-vous à la section Groupes de points de terminaison du réseau autonomes.

À des fins de démonstration, vous pouvez déployer un exemple de service qui diffuse son nom d'hôte via HTTP sur le port 80 :

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

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

kubectl get svc

Cette opération renvoie les valeurs : 

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


kubectl get pods

Cette opération renvoie les valeurs : 

NAME                        READY     STATUS    RESTARTS   AGE
app1-6db459dcb9-zvfg2       1/1       Running   0          6m
[..skip..]

Enregistrer le nom du NEG

Recherchez le groupe de points de terminaison du réseau créé à partir de l'exemple ci-dessus, puis enregistrez son nom.

Console

Pour afficher la liste des groupes de points de terminaison du réseau, accédez à la page Groupes de points de terminaison du réseau dans Google Cloud Console.
Accéder à la page Groupes de points de terminaison du réseau

gcloud

gcloud compute network-endpoint-groups list

Cela renvoie le résultat suivant :

NAME                 LOCATION          ENDPOINT_TYPE      SIZE
NEG-NAME           us-central1-a     GCE_VM_IP_PORT      1

Enregistrez le nom du groupe de points de terminaison du réseau dans la variable NEG_NAME. Par exemple:

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

Configurer les composants d'équilibrage de charge Google Cloud pour Traffic Director

Les instructions de cette section permettent de s'assurer que les services GKE sont accessibles à l'adresse IP virtuelle de service pour laquelle Traffic Director effectue l'équilibrage de charge, à l'aide d'une configuration d'équilibrage de charge semblable aux autres produits Google Cloud Load Balancing.

Vous devez configurer les composants suivants :

L'exemple de configuration Traffic Director qui suit repose sur les hypothèses suivantes :

  1. Les NEG et toutes les autres ressources sont créés dans le réseau default, en mode automatique, dans la zone us-central1-a.
  2. Le nom du NEG correspondant au cluster est stocké dans la variable ${NEG_NAME}.

Créer une vérification d'état

Créez la vérification d'état.

Console

  1. Accédez à la page "Vérifications d'état" dans Google Cloud Console.
    Accéder à la page "Vérifications d'état"
  2. Cliquez sur Créer une vérification d'état.
  3. Dans le champ du nom, saisissez td-gke-health-check.
  4. Comme protocole, sélectionnez HTTP.
  5. Cliquez sur Créer.

gcloud 

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

Créer un service de backend

Créez un service de backend mondial avec un schéma d'équilibrage de charge de type 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

  1. Accédez à la page "Traffic Director" dans la console Google Cloud.

    Accéder à la page "Traffic Director"

  2. Dans l'onglet Services, cliquez sur Créer un service.

  3. Cliquez sur Continuer.

  4. Comme nom de service, saisissez td-gke-service.

  5. Sous Type de backend, sélectionnez Groupes de points de terminaison du réseau.

  6. Sélectionnez le groupe de points de terminaison du réseau que vous avez créé.

  7. Définissez le Nombre maximal de RPS sur 5.

  8. Cliquez sur OK.

  9. Sous Vérification d'état, sélectionnez td-gke-health-check, qui est la vérification d'état que vous avez créée.

  10. Cliquez sur Continuer.

gcloud

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

  2. Ajoutez des groupes de points de terminaison du réseau au service de backend.

    gcloud compute backend-services add-backend td-gke-service \
 --global \
 --network-endpoint-group ${NEG_NAME} \
 --network-endpoint-group-zone us-central1-a \
 --balancing-mode RATE \
 --max-rate-per-endpoint 5

Créer la carte des règles de routage

Suivez ces instructions pour créer la règle de routage, la règle de transfert et l'adresse IP interne de votre configuration Traffic Director.

Le trafic envoyé à l'adresse IP interne est intercepté par le proxy Envoy et envoyé au service approprié conformément aux règles d'hôte et de chemin d'accès.

La règle de transfert est créée en tant que règle de transfert mondiale dont le paramètre load-balancing-scheme est défini sur INTERNAL_SELF_MANAGED.

Vous pouvez définir l'adresse de votre règle de transfert sur 0.0.0.0. Dans ce cas, le trafic est acheminé en fonction du nom d'hôte HTTP et des informations de chemin d'accès configurées dans le mappage d'URL, quelle que soit l'adresse IP réelle du nom d'hôte. Dans ce cas, les URL (nom d'hôte + chemin d'URL) de vos services, telles que configurées dans les règles d'hôte, doivent être uniques dans votre configuration de maillage de services. Autrement dit, vous ne pouvez pas disposer de deux services différents, avec un ensemble de backends différent, qui utilisent tous les deux la même combinaison nom d'hôte/chemin d'accès.

Vous pouvez également activer le routage en fonction de l'adresse IP virtuelle de destination réelle du service. Si vous configurez l'adresse IP virtuelle de votre service en tant que paramètre address de la règle de transfert, seules les requêtes destinées à cette adresse IP sont acheminées en fonction des paramètres HTTP spécifiés dans le mappage d'URL.

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

  1. Accédez à la page "Traffic Director" dans la console Google Cloud.

    Accéder à la page "Traffic Director"

  2. Cliquez sur Cartes des règles de routage.

  3. Cliquez sur Créer une règle de routage.

  4. Saisissez td-gke-url-map dans le champ Nom du mappage d'URL.

  5. Cliquez sur Ajouter une règle de transfert.

  6. Pour le nom de la règle de transfert, saisissez td-gke-forwarding-rule.

  7. Sélectionnez votre réseau.

  8. Sélectionnez votre adresse IP interne.

  9. Cliquez sur Enregistrer.

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

  11. Définissez l'hôte sur service-test.

  12. Cliquez sur Enregistrer.

gcloud

  1. Créez un mappage d'URL qui utilise le service de backend.

    gcloud compute url-maps create td-gke-url-map \
   --default-service td-gke-service

  2. Créez un outil de mise en correspondance des chemins d'accès de mappage d'URL et 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 ainsi qu'un outil de mise en correspondance des chemins d'accès par défaut qui fait correspondre toutes les requêtes de chemin à cet hôte (/*). service-test est également le nom configuré du service Kubernetes utilisé dans l'exemple de configuration ci-dessus.

    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

  3. Créez le proxy HTTP cible.

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

  4. 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, Traffic Director est configuré pour équilibrer la charge des services spécifiés dans le mappage d'URL sur les backends du groupe de points de terminaison du réseau.

Selon la manière dont vos microservices sont distribués sur votre réseau, vous devrez peut-être ajouter des règles de transfert ou des règles d'hôte et de chemin d'accès au mappage d'URL.

Vérifier la configuration en déployant un exemple de client pour les tests

Cette section explique comment accéder aux backends Traffic Director à partir d'une application cliente.

Pour comprendre sa fonctionnalité, vous pouvez déployer un exemple de pod exécutant Busybox. Le pod a accès au service-test créé dans la section précédente et reçoit un trafic dont la charge est équilibrée par Traffic Director.

Injecter un proxy side-car dans les pods GKE/Kubernetes

Pour accéder à un service géré par Traffic Director, un pod doit être doté d'un proxy side-car compatible avec l'API xDS.

Dans cet exemple, vous déployez un client Busybox avec un conteneur side-car Istio et des conteneurs init ajoutés au déploiement à l'aide de la spécification de référence.

Si vous utilisez les anciennes API, remplacez les variables PROJECT_NUMBER et NETWORK_NAME par le numéro de projet et le nom du réseau :

wget -q -O - https://storage.googleapis.com/traffic-director/demo/trafficdirector_client_sample_xdsv3.yaml
sed -i "s/PROJECT_NUMBER/PROJECT_NUMBER/g" trafficdirector_client_sample_xdsv3.yaml
sed -i "s/NETWORK_NAME/NETWORK_NAME/g" trafficdirector_client_sample_xdsv3.yaml
kubectl apply -f trafficdirector_client_sample_xdsv3.yaml

Si vous utilisez les nouvelles API de routage de service, qui sont actuellement en version bêta, remplacez les variables PROJECT_NUMBER et MESH_NAME par le numéro du projet et le nom du Mesh :

wget -q -O - https://storage.googleapis.com/traffic-director/demo/trafficdirector_client_new_api_sample_xdsv3.yaml
sed -i "s/PROJECT_NUMBER/PROJECT_NUMBER/g" trafficdirector_client_new_api_sample_xdsv3.yaml
sed -i "s/MESH_NAME/MESH_NAME/g" trafficdirector_client_new_api_sample_xdsv3.yaml
kubectl apply -f trafficdirector_client_new_api_sample_xdsv3.yaml

Le pod Busybox utilise deux conteneurs en cours d'exécution. Le premier conteneur est le client basé sur l'image Busybox et le second est le proxy Envoy injecté en tant que side-car. Exécutez la commande suivante pour obtenir plus d'informations sur le pod :

kubectl describe pods -l run=client

Atteindre le service de backend

Une fois configurées, les applications des pods ayant un proxy side-car injecté peuvent accéder aux services gérés par les services Traffic Director. Pour vérifier la configuration, vous pouvez accéder à un shell sur l'un des conteneurs.

Si vous avez utilisé la configuration de démonstration fournie dans ce guide, vous pouvez exécuter la commande de vérification suivante pour vous assurer que le nom d'hôte du pod de diffusion est renvoyé.

# Get name of the Pod  with 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.
TEST_CMD="wget -q -O - service-test; echo"

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

Comprendre l'interception du trafic par le proxy side-car

Notez que, dans cet exemple, lorsque le client Busybox envoie des requêtes au service de backend, chaque requête est relayée par le proxy side-car.

Cette application de démonstration utilise le proxy Envoy. C'est pourquoi "server: envoy" figure dans l'en-tête des réponses du serveur lues par le client.

Pour le vérifier, exécutez les commandes suivantes :

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

# Command to send a request to service-test and output server response headers.
TEST_CMD="wget -S --spider service-test; echo"

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

Dans cet exemple, vous avez créé une règle de transfert en utilisant l'adresse IP virtuelle 0.0.0.0. Cela signifie que Traffic Director transfère les requêtes au backend en fonction de l'en-tête Host uniquement. Dans ce cas, l'adresse IP de destination peut être n'importe quelle adresse, à condition que l'en-tête de l'hôte de requête corresponde à l'hôte défini dans le mappage d'URL service-test.

Pour le vérifier, exécutez les commandes de test suivantes :

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

# Command to send a request to service-test setting the Host header and using a random IP address.
TEST_CMD="wget -q --header 'Host: service-test' -O - 1.2.3.4; echo"

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

Étapes suivantes