Configurer des pods Google Kubernetes Engine avec injection Envoy manuelle
Ce guide vous explique comment configurer les hôtes de pods Kubernetes ou Google Kubernetes Engine les composants d'équilibrage de charge dont Cloud Service Mesh a besoin.
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.
Vous pouvez configurer Cloud Service Mesh à l'aide de l'équilibrage de charge Compute Engine ou les API REST. Consultez la documentation de référence de l'API Cloud Load Balancing et de gcloud.
Configurer des clusters GKE/Kubernetes pour Cloud Service Mesh
Cette section décrit la procédure à suivre pour activer Clusters GKE/Kubernetes pour qu'ils fonctionnent avec Cloud Service Mesh
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 est disponible en disponibilité générale pour Cloud Service Mesh.
- Les instances des nœuds du cluster compte de service doit être autorisé à accéder
l'API Cloud Service Mesh.
- Pour en savoir plus sur les autorisations requises, consultez la section Autoriser le compte de service à accéder à l'API Traffic Director.
- Pour en savoir plus sur l'activation de l'API Cloud Service Mesh, consultez Activez l'API Cloud Service Mesh.
- Les conteneurs doivent avoir accès à l'API Cloud Service Mesh, 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 :
Accédez au menu "Kubernetes Engine" dans la console Google Cloud.
Cliquez sur Créer un cluster.
Remplissez les champs suivants :
- Nom : saisissez
traffic-director-cluster
. - Type d'emplacement :
Zonal
. - Zone :
us-central1-a
.
- Nom : saisissez
Dans le volet de navigation, cliquez sur default-pool sous Pools de nœuds.
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).
Dans le volet de navigation, sous default-pool, cliquez sur Nœuds.
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.
Dans le volet de navigation, sous default-pool, cliquez sur Sécurité.
Dans la section Niveaux d'accès, cliquez sur Autoriser l'accès complet à l'ensemble des API Cloud.
Personnalisez votre cluster si nécessaire.
Cliquez sur Create (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 explique comment préparer les spécifications du déploiement Kubernetes avec Cloud Service Mesh. Cela implique également de configurer des services avec des NEG. comme l'injection de proxys side-car dans les pods nécessitant un accès aux services gérée par Cloud Service Mesh.
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
- 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: 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 toutes les instances vérifier les protocoles. - Cliquez sur Créer.
- Nom : attribuez un nom à la règle. Pour cet exemple, utilisez
gcloud
Exécutez la commande
gcloud
suivante pour créer une règle de pare-feu nomméefw-allow-health-checks
qui autorise les connexions entrantes aux instances de votre réseau ayant le tagallow-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 de pouvoir les configurer en tant que backends d'un backend Cloud Service Mesh
Google Cloud. 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": "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 Cloud Service Mesh
Les instructions de cette section permettent de s'assurer que les services GKE sont accessibles à l'adresse IP virtuelle de service pour laquelle Cloud Service Mesh 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 :
- 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 règle de routage. Cela inclut la création d'une règle de transfert et d'un mappage d'URL. Pour en savoir plus, consultez les sections Utiliser des règles de transfert et Utiliser des mappages d'URL.
L'exemple de configuration de Cloud Service Mesh ci-dessous rend ces hypothèses:
- Les NEG et toutes les autres ressources sont créés dans le réseau
default
, en mode automatique, dans la zoneus-central1-a
. - 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
- 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 Create (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
Accédez à la page Cloud Service Mesh de la console Google Cloud.
Dans l'onglet Services, cliquez sur Créer un service.
Cliquez sur Continuer.
Comme nom de service, saisissez
td-gke-service
.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
.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 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 Adresse IP de votre configuration Cloud Service Mesh.
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).
Accédez à la page Cloud Service Mesh de la console Google Cloud.
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 le service de backend.
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 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
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 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 Cloud Service Mesh à partir d'un client application.
Pour illustrer son fonctionnement, vous pouvez déployer un exemple de pod exécutant Tensorbox. La
le pod a accès à service-test
, que vous avez créé à la section précédente
et reçoit le trafic dont la charge
est équilibrée par Cloud Service Mesh.
Injecter un proxy side-car dans les pods GKE/Kubernetes
Pour accéder à un service géré par Cloud Service Mesh, un pod doit disposer d'un Un proxy side-car compatible avec l'API xDS a été installé.
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 Cloud Service Mesh. Pour vérifier la configuration, vous pouvez accéder à une interface système 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 Cloud Service Mesh 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"
Étape suivante
- En savoir plus sur la gestion avancée du trafic.
- Découvrez comment résoudre les problèmes de déploiement de Cloud Service Mesh.
- Découvrez comment configurer l'observabilité avec Envoy.