Traffic Director-Einrichtung für Google Kubernetes Engine-Pods mit automatischer Envoy-Einspeisung

Übersicht

In einem Service Mesh muss Ihr Anwendungscode Ihre Netzwerkkonfiguration nicht kennen. Stattdessen kommunizieren Ihre Anwendungen über eine Datenebene. Diese wird von einer Steuerungsebene konfiguriert, die das Dienstnetzwerk verwaltet. In dieser Anleitung ist Traffic Director Ihre Steuerungsebene und die Envoy-Sidecar-Proxys sind Ihre Datenebene.

Mit dem Envoy-Sidecar-Injektor können Sie Ihren Google Kubernetes Engine-Pods ganz einfach Envoy-Sidecar-Proxys hinzufügen. Wenn der Envoy-Sidecar-Injektor einen Proxy hinzufügt, wird dieser Proxy auch für die Verarbeitung des Anwendungstraffics und die Verbindung mit Traffic Director eingerichtet, damit Sie Ihre gewünschten Konfigurationen vornehmen können.

Der Leitfaden führt Sie durch eine einfache Einrichtung von Traffic Director mit Google Kubernetes Engine. Diese Schritte sind die Grundlage, die Sie auf komplexere Anwendungsfälle erweitern können, z. B. ein Service Mesh, das sich über mehrere Google Kubernetes Engine-Cluster und potenziell auch Compute Engine-VMs erstreckt.

Die Einrichtung umfasst Folgendes:

  1. GKE-Cluster für Arbeitslasten erstellen
  2. Envoy-Sidecar-Injektor installieren und Injektion aktivieren
  3. Beispielclient bereitstellen und Injektion prüfen
  4. Kubernetes-Dienst zum Testen bereitstellen
  5. Traffic Director mit Cloud Load Balancing-Komponenten konfigurieren, um Traffic an den Testdienst weiterzuleiten
  6. Konfiguration durch Senden einer Anfrage vom Beispielclient an den Testdienst prüfen
Übersicht der Komponenten, die im Rahmen dieses Einrichtungsleitfadens bereitgestellt werden (zum Vergrößern klicken)
Übersicht über die Komponenten, die im Rahmen dieses Einrichtungsleitfadens bereitgestellt werden (zum Vergrößern klicken)

Vorbereitung

Bevor Sie der Anleitung in diesem Leitfaden folgen, lesen Sie die Informationen unter Traffic Director-Einrichtung vorbereiten und achten Sie darauf, dass Sie die in diesem Dokument beschriebenen erforderlichen Aufgaben ausgeführt haben.

GKE-Cluster für Arbeitslasten erstellen

GKE-Cluster müssen die folgenden Voraussetzungen für die Unterstützung von Traffic Director erfüllen:

GKE-Cluster erstellen

Erstellen Sie einen GKE-Cluster mit dem Namen traffic-director-cluster in der 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

kubectl auf den neu erstellten Cluster verweisen

Ändern Sie den aktuellen Kontext für kubectl in den neu erstellten Cluster. Führen Sie dazu den folgenden Befehl aus:

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

Envoy-Sidecar-Injektor installieren

In den folgenden Abschnitten finden Sie eine Anleitung zum Installieren des Envoy-Sidecar-Injektors. Wenn der Sidecar-Injektor aktiviert ist, werden automatisch Sidecar-Proxys für neue und vorhandene Google Kubernetes Engine-Arbeitslasten bereitgestellt. Da der Envoy-Sidecar-Injektor in Ihrem GKE-Cluster ausgeführt wird, müssen Sie ihn einmal in jedem Cluster installieren, wenn Sie Traffic Director zur Unterstützung eines Service Mesh mit mehreren Clustern verwenden.

Sidecar-Injektor herunterladen

Laden Sie den Envoy-Sidecar-Injektor herunter und extrahieren Sie ihn.

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

Sidecar-Injektor konfigurieren

Konfigurieren Sie den Sidecar-Injektor durch Bearbeiten von specs/01-configmap.yaml. Gehen Sie dabei so vor:

  • Füllen Sie TRAFFICDIRECTOR_GCP_PROJECT_NUMBER aus. Ersetzen Sie dafür YOUR_PROJECT_NUMBER_HERE durch die Projektnummer Ihres Projekts. Die Projektnummer ist eine numerische Kennung für Ihr Projekt. Weitere Informationen zum Abrufen einer Liste aller Projekte finden Sie unter Projekte identifizieren.
  • Füllen Sie TRAFFICDIRECTOR_NETWORK_NAME aus. Ersetzen Sie dafür YOUR_NETWORK_NAME_HERE durch den Google Cloud-VPC-Netzwerknamen, den Sie mit Traffic Director verwenden möchten. Notieren Sie sich den Namen dieses VPC-Netzwerks, da Sie ihn später beim Konfigurieren von Traffic Director benötigen.

Diese Datei könnte so aussehen:

$ cat ./td-sidecar-injector-xdsv3/specs/01-configmap.yaml
   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: injector-mesh
     namespace: istio-control
   data:
     mesh: |-
       defaultConfig:
         discoveryAddress: trafficdirector.googleapis.com:443

         # Envoy proxy port to listen on for the admin interface.
         proxyAdminPort: 15000

         proxyMetadata:
           # GCP Project number where Traffic Director resources are configured.
           # This is a numeric identifier of your project (e.g. "111222333444").
           # You can get a list of all your projects with their corresponding numbers by
           # using "gcloud projects list" command or looking it up under "Project info"
           # section of your GCP console.
           # If left empty, configuration will be attempted to be fetched for the GCP
           # project associated with service credentials.
           # Leaving empty is not recommended as it is not guaranteed to work in future
           # releases.
           TRAFFICDIRECTOR_GCP_PROJECT_NUMBER: "YOUR_PROJECT_NUMBER_HERE"

           # GCP VPC network name for which the configuration is requested (This is the VPC
           # network name referenced in the forwarding rule in GCP API). If left empty,
           # configuration will be attempted to be fetched for the VPC network over which
           # the request to Traffic Director (trafficdirector.googleapis.com) is sent out.
           # Leaving empty is not recommended as it is not guaranteed to work in future
           # releases.
           TRAFFICDIRECTOR_NETWORK_NAME: "YOUR_NETWORK_NAME_HERE"

Sie können auch Logging und Tracing für jeden automatisch eingefügten Proxy aktivieren. Weitere Informationen zu diesen Konfigurationen finden Sie unter Zusätzliche Attribute für Sidecar-Proxys konfigurieren. Wenn Sie den Sidecar-Injektor verwenden, kann der Wert von TRAFFICDIRECTOR_ACCESS_LOG_PATH nur auf eine Datei im Verzeichnis /etc/istio/proxy/ gesetzt werden. Das Verzeichnis /etc/istio/proxy/access.log ist beispielsweise ein gültiger Speicherort.

Beachten Sie, dass TRAFFICDIRECTOR_INTERCEPTION_PORT nicht in dieser ConfigMap konfiguriert werden muss, da dies bereits vom Sidecar-Injektor konfiguriert wird.

TLS für den Sidecar-Injektor konfigurieren

In diesem Abschnitt erfahren Sie, wie Sie TLS für den Sidecar-Injektor konfigurieren.

Der Sidecar-Injektor verwendet einen mutierenden Zulassungs-Webhook von Kubernetes, um beim Erstellen neuer Pods Proxys einzufügen. Dieser Webhook ist ein HTTPS-Endpunkt. Daher müssen Sie einen Schlüssel und ein Zertifikat für TLS angeben.

Sie können einen privaten Schlüssel und ein selbst signiertes Zertifikat mit openssl erstellen, um den Sidecar-Injektor zu sichern.

Wenn Sie einen eigenen privaten Schlüssel und ein eigenes Zertifikat haben, das von einer vertrauenswürdigen Zertifizierungsstelle signiert wurde, können Sie diesen Schritt überspringen.

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}" \
  -addext "subjectAltName=DNS:${CN}"

cp cert.pem ca-cert.pem

Dieser openssl-Beispielbefehl gibt einen privaten 4.096-Bit-RSA-Schlüssel für key.pem und ein selbst signiertes Zertifikat im X.509-Format für cert.pem aus. Da das Zertifikat selbst signiert ist, wird es in ca-cert.pem kopiert und auch als Zertifikat der signierenden Zertifizierungsstelle erachtet. Das Zertifikat ist 365 Tage lang gültig und erfordert keine Passphrase. Weitere Informationen zum Erstellen und Signieren von Zertifikaten finden Sie in der Kubernetes-Dokumentation zu Anfragen zur Signierung von Zertifikaten.

Die Schritte in diesem Abschnitt müssen jährlich wiederholt werden, um neue Schlüssel und Zertifikate neu zu generieren und anzuwenden, bevor sie ablaufen.

Nachdem Sie Ihren Schlüssel und die Zertifikate generiert haben, müssen Sie ein Kubernetes-Secret erstellen und den Webhook des Sidecar-Injektors aktualisieren.

  1. Erstellen Sie den Namespace, unter dem das Kubernetes-Secret erstellt werden soll:

    kubectl apply -f specs/00-namespaces.yaml
    
  2. Erstellen Sie das Secret für den Sidecar-Injektor.

    kubectl create secret generic istio-sidecar-injector -n istio-control \
      --from-file=key.pem \
      --from-file=cert.pem \
      --from-file=ca-cert.pem
    
  3. Ändern Sie das caBundle des Sidecar-Injektions-Webhooks istio-sidecar-injector-istio-control in specs/02-injector.yaml:

    CA_BUNDLE=$(cat cert.pem | base64 | tr -d '\n')
    sed -i "s/caBundle:.*/caBundle:\ ${CA_BUNDLE}/g" specs/02-injector.yaml
    

Sidecar-Injektor im GKE-Cluster installieren

  1. Stellen Sie den Sidecar-Injektor bereit.

    kubectl apply -f specs/
    
  2. Prüfen Sie, ob der Sidecar-Injektor ausgeführt wird.

    kubectl get pods -A | grep sidecar-injector
    

    Die Ausgabe sollte in etwa so aussehen:

    istio-control   istio-sidecar-injector-6b475bfdf9-79965  1/1 Running   0   11s
    istio-control   istio-sidecar-injector-6b475bfdf9-vntjd  1/1 Running   0   11s
    

Sidecar-Injektion aktivieren

Mit dem folgenden Befehl wird die Injektion für den Namespace default aktiviert. Der Sidecar-Injektor fügt Sidecar-Container in Pods ein, die unter diesem Namespace erstellt werden:

kubectl label namespace default istio-injection=enabled

Führen Sie Folgendes aus, um zu prüfen, ob der default-Namespace richtig aktiviert ist:

kubectl get namespace -L istio-injection

In diesem Fall sollte Folgendes zurückgegeben werden:

NAME              STATUS   AGE     ISTIO-INJECTION
default           Active   7d16h   enabled
istio-control     Active   7d15h
istio-system      Active   7d15h

Beispielclient bereitstellen und Injektion prüfen

In diesem Abschnitt wird gezeigt, wie Sie einen Beispiel-Pod mit Busybox bereitstellen. Busybox bietet Ihnen eine einfache Schnittstelle zum Erreichen eines Testdienstes. In einer echten Bereitstellung würden Sie stattdessen Ihre eigene Clientanwendung bereitstellen.

kubectl create -f demo/client_sample.yaml

Der Busybox-Pod besteht aus zwei Containern. Der erste Container ist der Client, der auf dem Busybox-Image basiert, und der zweite Container ist der Envoy-Proxy, der vom Sidecar-Injektor eingefügt wird. Mit dem folgenden Befehl können Sie weitere Informationen zum Pod abrufen:

kubectl describe pods -l run=client

In diesem Fall sollte Folgendes zurückgegeben werden:

…
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:
…

Kubernetes-Dienst zum Testen bereitstellen

In den folgenden Abschnitten finden Sie eine Anleitung zum Einrichten eines Testdienstes, den Sie später in diesem Leitfaden verwenden, um eine End-to-End-Prüfung Ihrer Einrichtung zu ermöglichen.

GKE-Dienste mit NEGs konfigurieren

GKE-Dienste müssen über Netzwerk-Endpunktgruppen (NEGs) verfügbar gemacht werden, damit Sie sie als Back-Ends eines Traffic Director-Back-End-Dienstes konfigurieren können. Fügen Sie der Kubernetes-Dienstspezifikation die NEG-Annotation hinzu und wählen Sie einen Namen aus, indem Sie NEG-NAME im Beispiel unten ersetzen, damit Sie sie später leicht wiederfinden. Sie benötigen den Namen, wenn Sie die NEG an Ihren Traffic Director-Back-End-Dienst anhängen. Weitere Informationen zum Annotieren von NEGs finden Sie unter NEGs benennen.

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

Diese Annotation erstellt eine Standalone-NEG mit Endpunkten, die den IP-Adressen und Ports der Dienst-Pods entsprechen. Weitere Informationen und Beispiele finden Sie unter Standalone-Netzwerk-Endpunktgruppen.

Der folgende Beispieldienst enthält die NEG-Annotation. Der Dienst stellt den Hostnamen über HTTP auf Port 80 bereit. Verwenden Sie den folgenden Befehl, um den Dienst abzurufen und im GKE-Cluster bereitzustellen.

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

Prüfen Sie, ob der neue Dienst erstellt wurde und der Anwendungs-Pod ausgeführt wird:

kubectl get svc

Die Ausgabe sollte in etwa so aussehen:

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

Prüfen Sie, ob der mit diesem Dienst verknüpfte Anwendungs-Pod ausgeführt wird:

kubectl get pods
Dadurch wird Folgendes zurückgegeben:
NAME                        READY     STATUS    RESTARTS   AGE
app1-6db459dcb9-zvfg2       2/2       Running   0          6m
[..skip..]

Name der NEG speichern

Suchen Sie die im obigen Beispiel erstellte NEG und notieren Sie sich ihren Namen für die Traffic Director-Konfiguration im nächsten Abschnitt.

gcloud compute network-endpoint-groups list

Es wird Folgendes zurückgegeben:

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

Speichern Sie den Namen der NEG in der Variable NEG_NAME:

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

Traffic Director mit Cloud Load Balancing-Komponenten konfigurieren

In diesem Abschnitt wird Traffic Director mithilfe von Compute Engine-Load-Balancing-Ressourcen konfiguriert. Dadurch kann der Sidecar-Proxy des Beispielclients die Konfiguration von Traffic Director empfangen. Ausgehende Anfragen vom Beispielclient werden vom Sidecar-Proxy verarbeitet und an den Testdienst weitergeleitet.

Sie müssen die folgenden Komponenten konfigurieren:

Systemdiagnose und Firewallregel erstellen

Console

  1. Rufen Sie in der Google Cloud Console die Seite "Systemdiagnosen" auf.
    Zur Seite "Systemdiagnosen"
  2. Klicken Sie auf Systemdiagnose erstellen.
  3. Geben Sie als Name td-gke-health-check ein.
  4. Wählen Sie als Protokoll HTTP aus.
  5. Klicken Sie auf Erstellen.

  6. Rufen Sie in der Google Cloud Console die Seite „Firewallregeln“ auf.
    Zur Seite "Firewall"

  7. Klicken Sie auf Firewallregel erstellen.

  8. Geben Sie auf der Seite Firewallregel erstellen die folgenden Informationen an:

    • Name: Geben Sie einen Namen für die Regel an. Verwenden Sie für dieses Beispiel fw-allow-health-checks.
    • Netzwerk: Wählen Sie ein VPC-Netzwerk aus.
    • Priorität: Geben Sie eine Zahl für die Priorität ein. Niedrigere Zahlen haben höhere Prioritäten. Achten Sie darauf, dass die Firewallregel eine höhere Priorität hat als andere Regeln, die möglicherweise eingehenden Traffic ablehnen.
    • Traffic-Richtung: Wählen Sie eingehend aus.
    • Aktion bei Übereinstimmung: Wählen Sie Zulassen aus.
    • Ziele: Wählen Sie Alle Instanzen im Netzwerk aus.
    • Quellfilter: Wählen Sie IP-Bereiche aus.
    • Quell-IP-Bereiche: 35.191.0.0/16,130.211.0.0/22.
    • Zulässige Protokolle und Ports: Verwenden Sie tcp. TCP ist das zugrunde liegende Protokoll für alle Systemdiagnose-Protokolle.
    • Klicken Sie auf Erstellen.

gcloud

  1. Erstellen Sie die Systemdiagnose.

    gcloud compute health-checks create http td-gke-health-check \
      --use-serving-port
    
  2. Erstellen Sie die Firewallregel, um IP-Adressbereiche für die Systemdiagnose zuzulassen.

    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
    

Back-End-Dienst erstellen

Erstellen Sie einen globalen Back-End-Dienst mit dem Load-Balancing-Schema INTERNAL_SELF_MANAGED. In der Cloud Console wird das Load-Balancing-Schema implizit festgelegt. Binden Sie die Systemdiagnose in den Back-End-Dienst ein.

Console

  1. Rufen Sie in der Cloud Console die Seite "Traffic Director" auf.

    Zur Seite "Traffic Director"

  2. Klicken Sie auf dem Tab Dienste auf Dienst erstellen.

  3. Klicken Sie auf Weiter.

  4. Geben Sie als Dienstname td-gke-service ein.

  5. Wählen Sie unter Back-End-Typ Netzwerk-Endpunktgruppen aus.

  6. Wählen Sie die erstellte Netzwerk-Endpunktgruppe aus.

  7. Legen Sie die Maximale Anzahl der Anfragen pro Sekunde auf 5 fest.

  8. Klicken Sie auf Fertig.

  9. Wählen Sie unter Systemdiagnose td-gke-health-check aus. Dies ist die Systemdiagnose, die Sie erstellt haben.

  10. Klicken Sie auf Weiter.

gcloud

  1. Erstellen Sie den Back-End-Dienst und verknüpfen Sie die Systemdiagnose mit dem Back-End-Dienst.

    gcloud compute backend-services create td-gke-service \
     --global \
     --health-checks td-gke-health-check \
     --load-balancing-scheme INTERNAL_SELF_MANAGED
    
  2. Fügen Sie dem Back-End-Dienst die zuvor erstellte NEG als Back-End hinzu.

    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
    

Routingregelzuordnung erstellen

Die Routingregelzuordnung definiert, wie Traffic Director den Traffic in Ihrem Mesh-Netzwerk weiterleitet. Im Rahmen der Routingregelzuordnung konfigurieren Sie eine virtuelle IP-Adresse (VIP) und eine Reihe zugehöriger Trafficverwaltungsregeln, z. B. hostbasiertes Routing. Wenn eine Anwendung eine Anfrage an die VIP sendet, führt der angehängte Envoy-Sidecar-Proxy die folgenden Schritte aus:

  1. Fängt die Anfrage ab
  2. Bewertet die Anfrage in Übereinstimmung mit den Trafficverwaltungsregeln in der URL-Zuordnung
  3. Wählt einen Back-End-Dienst anhand des Hostnamens in der Anfrage aus
  4. Wählt ein Back-End oder einen Endpunkt aus, der dem ausgewählten Back-End-Dienst zugeordnet ist
  5. Sendet Traffic an dieses Back-End oder den Endpunkt

Console

In der Console wird der Zielproxy mit der Weiterleitungsregel kombiniert. Wenn Sie die Weiterleitungsregel erstellen, erstellt Google Cloud automatisch einen Ziel-HTTP-Proxy und verknüpft ihn mit der URL-Zuordnung.

Die Routingregel besteht aus der Weiterleitungsregel und den Host- und Pfadregeln (auch als URL-Zuordnung bezeichnet).

  1. Rufen Sie in der Cloud Console die Seite "Traffic Director" auf.

    Zur Seite "Traffic Director"

  2. Klicken Sie auf Routingregelzuordnungen.

  3. Klicken Sie auf Routingregel erstellen.

  4. Geben Sie als Name der URL-Zuordnung td-gke-url-map ein.

  5. Klicken Sie auf Weiterleitungsregel hinzufügen.

  6. Geben Sie als Name für die Weiterleitungsregel td-gke-forwarding-rule ein.

  7. Wählen Sie das Netzwerk aus.

  8. Wählen Sie Ihre Interne IP-Adresse aus.

  9. Klicken Sie auf Speichern.

  10. Fügen Sie optional benutzerdefinierte Host- und Pfadregeln hinzu oder behalten Sie die Pfadregeln als Standard bei.

  11. Legen Sie den Host auf service-test fest.

  12. Klicken Sie auf Speichern.

gcloud

  1. Erstellen Sie eine URL-Zuordnung, die td-gke-service als Standard-Back-End-Dienst verwendet.

    gcloud compute url-maps create td-gke-url-map \
       --default-service td-gke-service
    
  2. Erstellen Sie ein Tool zum Abgleich von Pfaden für URL-Zuordnungen und eine Hostregel, um den Traffic für Ihren Dienst auf Grundlage des Hostnamens und Pfads weiterzuleiten. In diesem Beispiel werden service-test als Dienstname und ein Standardtool zum Abgleich von Pfaden verwendet, das mit allen Pfadanfragen für diesen Host (/*) übereinstimmt.

    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. Erstellen Sie den Ziel-HTTP-Proxy.

    gcloud compute target-http-proxies create td-gke-proxy \
       --url-map td-gke-url-map
    
  4. Erstellen Sie die Weiterleitungsregel.

    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
    

An dieser Stelle konfiguriert Traffic Director Ihre Sidecar-Proxys so, dass sie Anfragen weiterleiten, die den Hostnamen service-test für Back-Ends von td-gke-service angeben. Dabei sind diese Back-Ends Endpunkte in der Netzwerk-Endpunktgruppe, die dem zuvor bereitgestellten Kubernetes-Testdienst zugeordnet ist.

Konfiguration prüfen

In diesem Abschnitt wird gezeigt, wie Sie prüfen, ob der vom Busybox-Beispielclient gesendete Traffic an Ihren Kubernetes-Dienst service-test weitergeleitet wird. Zum Senden einer Testanfrage können Sie auf eine Shell in einem der Container zugreifen und den folgenden Prüfungsbefehl ausführen. Ein service-test-Pod sollte den Hostnamen des Bereitstellungs-Pods zurückgeben.

# 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"

So wird die Konfiguration geprüft:

  • Der Beispielclient hat eine Anfrage gesendet, in der der Hostname service-test angegeben ist.
  • Der Beispielclient verfügt über einen Envoy-Sidecar-Proxy, der vom Envoy-Sidecar-Injektor eingefügt wurde.
  • Der Sidecar-Proxy hat die Anfrage abgefangen.
  • Da Sie 0.0.0.0 als VIP in Ihrer Routingregelzuordnung konfiguriert haben, hat Envoy den Hostnamen der Anfrage geprüft.
  • Envoy hat mithilfe der URL-Zuordnung den Hostnamen service-test mit dem Traffic Director-Dienst td-gke-service abgeglichen.
  • Envoy hat einen Endpunkt aus der mit td-gke-service verknüpften Netzwerk-Endpunktgruppe ausgewählt.
  • Envoy hat die Anfrage an einen Pod gesendet, der mit dem Kubernetes-Dienst service-test verknüpft ist.

Weitere Informationen

Je nachdem, wie Ihre Mikrodienste in Ihrem Netzwerk verteilt sind, müssen Sie möglicherweise weitere Weiterleitungsregeln oder weitere Host- und Pfadregeln zur URL-Zuordnung hinzufügen. Weitere Informationen zu Weiterleitungsregeln und URL-Zuordnungen finden Sie in den folgenden Dokumenten: