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, Traffic Director est votre plan de contrôle, et les proxys side-car Envoy sont votre plan de données.
L'injecteur de side-car Envoy facilite l'ajout de 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 à Traffic Director pour la configuration.
Ce guide vous explique comment configurer simplement Traffic Director 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.
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 Traffic Director 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érequis
Avant de suivre les instructions de ce guide, consultez la section Préparer la configuration de Traffic Director et assurez-vous d'avoir effectué les tâches préalables décrites dans ce document.
Créer un cluster GKE pour vos charges de travail
Les clusters GKE doivent répondre aux exigences suivantes pour être compatibles avec Traffic Director :
- 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 page Activer le compte de service pour accéder à l'API Traffic Director.
Créer le cluster GKE
Créez un cluster GKE appelé traffic-director-cluster
dans la zone us-central1-a
.
gcloud container clusters create traffic-director-cluster \ --zone us-central1-a \ --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 us-central1-a
Installer l'injecteur de side-car Envoy
Les sections suivantes fournissent des instructions concernant l'installation de l'injecteur side-car Envoy. Lorsque l'injecteur de side-car est activé, il déploie automatiquement les proxys side-car pour les charges de travail nouvelles et existantes de Google Kubernetes Engine. Étant donné que l'injecteur de side-car Envoy s'exécute dans votre cluster GKE, vous devez l'installer une fois sur chaque cluster si vous utilisez Traffic Director pour prendre en charge un maillage de services multiclusters.
Télécharger l'injecteur de side-car
Téléchargez et extrayez l'injecteur de side-car Envoy.
wget https://storage.googleapis.com/traffic-director/td-sidecar-injector.tgz tar -xzvf td-sidecar-injector.tgz cd td-sidecar-injector
Configurer l'injecteur de side-car
Configurez l'injecteur de side-car en modifiant le fichier specs/01-configmap.yaml
de la manière suivante :
- Dans
TRAFFICDIRECTOR_GCP_PROJECT_NUMBER
, remplacezyour-project-here
par le numéro de votre projet. Le numéro de projet est un identifiant numérique de votre projet. Pour en savoir plus sur l'obtention de la liste de tous vos projets, consultez la section Identifier des projets. - Dans
TRAFFICDIRECTOR_NETWORK_NAME
, remplacezyour-network-here
par le nom du réseau cloud privé virtuel Google Cloud que vous souhaitez utiliser avec Traffic Director. Notez ce nom de réseau VPC, car vous en aurez besoin plus tard lorsque vous configurerez Traffic Director.
Vous pouvez également activer la journalisation et le traçage pour chaque proxy injecté automatiquement. Pour en savoir plus sur ces configurations, consultez la section Configurer des attributs supplémentaires pour les proxys side-car.
Notez que TRAFFICDIRECTOR_INTERCEPTION_PORT
ne doit pas être configuré dans ce fichier ConfigMap
, car il est déjà configuré par l'injecteur de side-car.
Configurer TLS pour l'injecteur de side-car
Cette section explique comment configurer TLS pour l'injecteur de side-car.
L'injecteur de side-car utilise un webhook d'admission en mutation Kubernetes pour injecter des proxys lors de la création de nouveaux pods. Ce webhook est un point de terminaison HTTPS. Vous devez donc fournir une clé et un certificat pour TLS.
Vous pouvez créer une clé privée et un certificat autosigné à l'aide de openssl
pour sécuriser l'injecteur de side-car.
Si vous disposez de votre propre clé privée et d'un certificat signé par une autorité de certification approuvée, vous pouvez ignorer cette étape.
CN=istio-sidecar-injector.istio-control.svc openssl req \ -x509 \ -newkey rsa:4096 \ -keyout key.pem \ -out cert.pem \ -days 365 \ -nodes \ -subj "/CN=${CN}" cp cert.pem ca-cert.pem
Cet exemple de commande openssl
génère une clé RSA privée de 4 096 bits dans key.pem
et un certificat autosigné au format X.509 dans cert.pem
. Comme le certificat est autosigné, il est copié dans ca-cert.pem
et considéré également comme le certificat de l'autorité de certification. Le certificat reste valide 365 jours et ne nécessite pas de phrase secrète. Pour en savoir plus sur la création et la signature de certificats, consultez la documentation de Kubernetes sur les requêtes de signature de certificat.
Les étapes de cette section doivent être répétées chaque année pour régénérer et réappliquer de nouvelles clés et certificats avant leur expiration.
Une fois que vous disposez de votre clé et de vos certificats, vous devez créer un secret Kubernetes et mettre à jour le webhook de l'injecteur de side-car.
Créez l'espace de noms sous lequel le secret Kubernetes doit être créé :
kubectl apply -f specs/00-namespaces.yaml
Créez le secret pour l'injecteur de side-car.
kubectl create secret generic istio-sidecar-injector -n istio-control \ --from-file=key.pem \ --from-file=cert.pem \ --from-file=ca-cert.pem
Modifiez le
caBundle
du webhook d'injection de side-car nomméistio-sidecar-injector-istio-control
dansspecs/02-injector.yaml
:CA_BUNDLE=$(cat cert.pem | base64 | tr -d '\n') sed -i "s/caBundle:.*/caBundle:\ ${CA_BUNDLE}/g" specs/02-injector.yaml
Installer l'injecteur de side-car sur votre cluster GKE
Déployez l'injecteur de side-car.
kubectl apply -f specs/
Vérifiez que l'injecteur de side-car est en cours d'exécution.
kubectl get pods -A | grep sidecar-injector
Cette commande renvoie un résultat semblable à celui-ci :
istio-control istio-sidecar-injector-6b475bfdf9-79965 1/1 Running 0 11s istio-control istio-sidecar-injector-6b475bfdf9-vntjd 1/1 Running 0 11s
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 istio-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 istio-injection
Cette opération devrait renvoyer les valeurs ci-dessous :
NAME STATUS AGE ISTIO-INJECTION default Active 7d16h enabled istio-control Active 7d15h istio-system Active 7d15h
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.
kubectl create -f demo/client_sample.yaml
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: … # Istio-proxy is the container that runs the injected Envoy proxy. Istio-proxy: …
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 Traffic Director.
... metadata: annotations: cloud.google.com/neg: '{"exposed_ports":{"80":{}}}'
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 podsCette opération renvoie les valeurs :
NAME READY STATUS RESTARTS AGE app1-6db459dcb9-zvfg2 2/2 Running 0 6m [..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 Traffic Director dans la section suivante.
gcloud compute network-endpoint-groups list
Cette opération renvoie les valeurs :
NAME LOCATION ENDPOINT_TYPE SIZE k8s1-7e91271e-default-service-test-80-a652810c us-central1-a 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 Traffic Director avec des composants Cloud Load Balancing
Cette section configure Traffic Director à 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 Traffic Director. 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 Traffic Director, Utiliser des proxys cibles pour Traffic Director et Utiliser des mappages d'URL.
Créer la vérification d'état et la règle de pare-feu
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).
Accédez à la page Pare-feu de Google Cloud Console.
Accéder à la page Pare-feuCliquez sur Créer une règle 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 Plages d'adresses IP.
- Plages d'adresses IP sources :
35.191.0.0/16,130.211.0.0/22
. - Protocoles et ports autorisés : utilisez
tcp
. TCP est le protocole sous-jacent de tous les protocoles de vérification d'état. - Cliquez sur Créer.
- Nom : attribuez un nom à la règle. Pour cet exemple, utilisez
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 \ --target-tags td-http-server \ --rules tcp:80
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 Cloud Console, 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 "Traffic Director" dans Cloud Console.
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 le NEG créé précédemment en tant que backend 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
La carte des règles de routage définit la manière dont Traffic Director 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 "Traffic Director" dans Cloud Console.
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, Traffic Director 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. 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"
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.
- Étant donné que vous avez configuré
0.0.0.0
comme adresse IP virtuelle dans la carte des règles de routage, Envoy a inspecté le nom d'hôte de la requête. - À l'aide du mappage d'URL, Envoy a mis en correspondance le nom d'hôte
service-test
et le service Traffic Directortd-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
.
Étapes suivantes
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 supplémentaires d'hôte et de chemin d'accès au mappage d'URL. Pour plus d'informations sur les règles de transfert et les mappages d'URL, consultez les documents suivants :
- Utiliser des règles de transfert
- Ressource REST des règles de transfert
- Ressource REST des règles de transfert mondiales
- Utiliser des mappages d'URL
- Ressource REST de mappage d'URL
- Pour plus d'options de configuration d'injecteur de side-car, consultez la section Options de configuration de pods Google Kubernetes Engine avec injection Envoy automatique.