Google Kubernetes Engine-Pods mit automatischer Envoy-Injektion einrichten

Überblick

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. Sie können diese Anleitung auch verwenden, wenn Sie Traffic Director mit freigegebene VPC konfigurieren.

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 über die Komponenten, die im Rahmen dieser Einrichtungsanleitung 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.

Informationen zur unterstützten Envoy-Version finden Sie in den Versionshinweisen zu Traffic Director.

Hinweis: Der Sidecar-Injektor und der eingefügte Proxy basieren auf dem Sidecar-Injektor von Istio. Installieren Sie den Envoy-Sidecar-Injektor nicht, wenn Sie Istio bereits für Ihren GKE-Cluster bereitgestellt haben, da dies zu Konflikten beim Injektionsverhalten führen kann.

Zusätzliche Voraussetzungen für freigegebene VPC

Wenn Sie Traffic Director in einer freigegebene VPC-Umgebung einrichten, müssen Sie Folgendes beachten.

• Sie haben die erforderlichen Berechtigungen und Rollen für freigegebene VPC.
• Sie haben die richtigen Projekte und die richtigen Abrechnungen eingerichtet.
• Sie haben die Abrechnung in den Projekten aktiviert.
• Sie haben die Traffic Director und die GKE APIs in jedem Projekt aktiviert, einschließlich des Hostprojekts.
• Sie haben für jedes Projekt die richtigen Dienstkonten eingerichtet.
• Sie haben ein VPC-Netzwerk und Subnetze erstellt.
• Sie haben die freigegebene VPC aktiviert.

Weitere Informationen finden Sie unter Freigegebene VPC.

IAM-Rollen konfigurieren

In diesem Beispiel für die IAM-Rollenkonfiguration wird davon ausgegangen, dass das Hostprojekt für die freigegebene VPC zwei Subnetze hat und sich in der freigegebenen VPC zwei Dienstprojekte befinden.

1. Erstellen Sie in Cloud Shell einen Arbeitsordner (WORKDIR), in dem Sie die mit diesem Abschnitt verknüpften Dateien erstellen:

   mkdir -p ~/td-shared-vpc
   cd ~/td-shared-vpc
   export WORKDIR=$(pwd)
   

2. Konfigurieren Sie IAM-Berechtigungen im Hostprojekt, damit Dienstprojekte die Ressourcen in der freigegebenen VPC verwenden können.

   In diesem Schritt konfigurieren Sie die IAM-Berechtigungen, sodass Dienstprojekt 1 auf subnet-1 und Dienstprojekt 2 auf subnet-2 zugreifen kann. Sie weisen die Rolle "Compute-Netzwerknutzer" (roles/compute.networkUser) in jedem Dienstprojekt für jedes Subnetz sowohl dem Compute Engine-Standarddienstkonto als auch dem Google Cloud API-Dienstkonto zu.

   1. Konfigurieren Sie für Dienstprojekt 1 IAM-Berechtigungen für 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}
      

   2. Konfigurieren Sie für Dienstprojekt 2 IAM-Berechtigungen für 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}
      

3. Für jedes Dienstprojekt müssen Sie dem GKE-Dienstkonto im Hostprojekt die IAM-Rolle "Nutzer des Dienst-Agents für Kubernetes Engine-Host" (roles/container.hostServiceAgentUser) zuweisen:

   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
   

   Damit kann das GKE-Dienstkonto des Dienstprojekts das GKE-Dienstkonto des Hostprojekts verwenden, um gemeinsam genutzte Netzwerkressourcen zu konfigurieren.

4. Weisen Sie dem Compute Engine-Standarddienstkonto für jedes Dienstprojekt die IAM-Rolle "Compute-Netzwerkbetrachter" (roles/compute.networkViewer) im Hostprojekt zu.

   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
   

   Wenn der Envoy-Sidecar-Proxy mit dem xDS-Dienst (Traffic Director API) verbunden ist, verwendet der Proxy das Dienstkonto des Compute Engine-VM-Hosts (virtuelle Maschine) oder der GKE-Knoteninstanz Das Dienstkonto muss die IAM-Berechtigung compute.globalForwardingRules.get auf Projektebene haben. Die Rolle "Compute-Netzwerkbetrachter" ist für diesen Schritt ausreichend.

GKE-Cluster für Arbeitslasten erstellen

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

• Die Unterstützung von Netzwerk-Endpunktgruppen muss aktiviert sein. Weitere Informationen und Beispiele finden Sie unter Standalone-Netzwerk-Endpunktgruppen.
• Das Dienstkonto für Ihre GKE-Knoten/Pods muss die Berechtigung für den Zugriff auf die Traffic Director API haben. Weitere Informationen zu den erforderlichen Berechtigungen finden Sie unter Dienstkonto für den Zugriff auf die Traffic Director API aktivieren.

GKE-Cluster erstellen

Erstellen Sie einen GKE-Cluster mit dem Namen traffic-director-cluster in Ihrer bevorzugten Zone, z. B. us-central1-a.

gcloud container clusters create traffic-director-cluster \
  --zone ZONE \
  --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 ZONE

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

Wenn Sie die älteren APIs verwenden, konfigurieren Sie den Sidecar-Injektor durch Bearbeiten der Datei specs/01-configmap.yaml:

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

Wenn Sie die neuen Service Routing APIs verwenden, die sich derzeit in der Vorschau befinden:

• Füllen Sie TRAFFICDIRECTOR_MESH_NAME aus. Ersetzen Sie dafür "" durch den Namen des Service Mesh, um die Konfiguration für ein Service Mesh abzurufen.
  • Beachten Sie, dass Sie den Sidecar-Injektor nicht verwenden, wenn Sie einen Gateway konfigurieren. Sie stellen einen Envoy-Proxy als Pod bereit.

Diese Datei könnte so aussehen:

$ cat 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:
           # Google Cloud 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 Google Cloud console.
           # If left empty, configuration will be attempted to be fetched for the Google Cloud
           # 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"

           # Google Cloud VPC network name for which the configuration is requested (This is the VPC
           # network name referenced in the forwarding rule in Google Cloud 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: "default"

Hinweis: Wenn Sie eine freigegebene VPC eingerichtet haben, ersetzen Sie TRAFFICDIRECTOR_NETWORK_NAME durch den Namen des Netzwerks, das im Hostprojekt konfiguriert ist.

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/envoy/ gesetzt werden. Das Verzeichnis /etc/envoy/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
   

Hinweis: Sowohl der Injektor als auch der eingefügte Proxy beruhen auf den Implementierungen von Istio. Daher sind in Ihren Clustern die Istio-basierten Komponenten enthalten. Sie müssen keine zusätzlichen Istio-Komponenten installieren. Alle für Traffic Director erforderlichen Konfigurationen werden in diesem Leitfaden erläutert.

Notwendigen Port in einem privaten Cluster öffnen

Wenn Sie der Anleitung unter Traffic Director-Dienstsicherheit mit Envoy einrichten folgen, können Sie diesen Abschnitt überspringen und mit dem nächsten Abschnitt Sidecar-Injektion aktivieren fortfahren.

Wenn Sie den Envoy-Sidecar-Injektor in einem privaten Cluster installieren, müssen Sie den TCP-Port 9443 in der Firewallregel für die Masterknoten öffnen, damit der Webhook ordnungsgemäß funktioniert.

In den folgenden Schritten wird beschrieben, wie Sie die nötige Firewallregel aktualisieren. Beachten Sie, update-Befehl ersetzt die vorhandene Firewallregel. Sie müssen daher die Standardports 443 (HTTPS) und 10250 (kubelet) sowie den neuen Port, den Sie öffnen möchten inkludieren.

1. Suchen Sie den Quellbereich (master-ipv4-cidr) des Clusters. Ersetzen Sie im folgenden Befehl CLUSTER_NAME durch den Namen des Clusters, z. B. traffic-director-cluster:

   FIREWALL_RULE_NAME=$(gcloud compute firewall-rules list \
    --filter="name~gke-CLUSTER_NAME-[0-9a-z]*-master" \
    --format="value(name)")
   

2. Aktualisieren Sie die Firewallregel zum Öffnen von TCP-Port 9443, um die automatische Injektion zu aktivieren:

   gcloud compute firewall-rules update ${FIREWALL_RULE_NAME} \
    --allow tcp:10250,tcp:443,tcp:9443
   

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

Mit dem folgenden Befehl können Sie prüfen, ob der Namespace default 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

Wenn Sie die Dienstsicherheit für Traffic Director mit Envoy konfigurieren, kehren Sie zum Abschnitt Testdienst einrichten in diesem Einrichtungsleitfaden zurück.

Beispielclient bereitstellen und Einfügung 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.

Hinweis: Das in diesem Einrichtungshandbuch bereitgestellte Paket trafficdirector_service_sample.yaml verwendet den NEG-Namen service-test-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

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
busybox-5dcf86f4c7-jvvdd    2/2       Running   0          10m
[..skip..]

Hinweis: Da der Sidecar-Injektor im Standard-Namespace aktiviert ist, werden Sidecar-Proxys auch in den Testdienst-Pod eingefügt, wenn dieser erstellt wird. Der Sidecar-Injektor konfiguriert nur das Abfangen von ausgehendem Traffic. Daher ist der Sidecar-Proxy des Testdienstes nicht an der Verarbeitung des eingehenden Traffics aus dem Beispielclient beteiligt.

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
service-test-neg           ZONE     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}')

Hinweis: Wenn Sie Ihre NEG benannt haben, wie unter GKE-Dienste mit NEGs konfigurieren beschrieben, sollte der NEG-Name mit dem übereinstimmen, den Sie in der Kubernetes-Dienstspezifikation angegeben haben. Wenn Sie die NEG nicht benannt haben, wird automatisch ein Name generiert.

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 Weitere Informationen zu Systemdiagnosen finden Sie unter Konzepte der Systemdiagnose und Systemdiagnosen erstellen.
• Back-End-Dienst Weitere Informationen zu Back-End-Diensten finden Sie unter Back-End-Dienste.
• Eine Routingregelzuordnung: Dazu gehört das Erstellen einer Weiterleitungsregel, eines Ziel-HTTP-Proxys und einer URL-Zuordnung. Weitere Informationen finden Sie unter Weiterleitungsregeln für Traffic Director verwenden, Zielproxys für Traffic Director verwenden und URL-Zuordnungen verwenden.

Systemdiagnose und Firewallregel erstellen

Erstellen Sie anhand der folgenden Anleitung eine Systemdiagnose und die Firewallregel, die für die Systemdiagnoseprüfungen erforderlich ist. Weitere Informationen finden sich unter Firewallregeln für Systemdiagnosen.

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 Firewallrichtlinien auf.
   Zur Seite „Firewallrichtlinien“

7. Klicken Sie auf Firewallregeln 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 den richtigen IP-Bereichstyp aus.
   • Quell-IP-Bereiche: 35.191.0.0/16,130.211.0.0/22
   • Zielfilter: Wählen Sie den IP-Typ aus.
   • Protokolle und Ports: Klicken Sie auf Angegebene Ports und Protokolle und dann auf 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 Backend-Dienst mit dem Load-Balancing-Schema INTERNAL_SELF_MANAGED. In der Google Cloud Console wird das Load-Balancing-Schema implizit festgelegt. Binden Sie die Systemdiagnose in den Backend-Dienst ein.

Console

1. Rufen Sie in der Google 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 das Netzwerk aus, das Sie in der Traffic Director-ConfigMap konfiguriert haben.

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

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

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

9. Setzen Sie den Balancing-Modus auf Rate.

10. Klicken Sie auf Fertig.

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

12. 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 Backend-Dienst die zuvor erstellte NEG als Backend hinzu. Wenn Sie Traffic Director mit einem Ziel-TCP-Proxy konfigurieren, müssen Sie den Balancing-Modus UTILIZATION verwenden. Wenn Sie einen HTTP- oder HTTPS-Zielproxy verwenden, können Sie den RATE-Modus verwenden.

   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
   

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

Hinweis: Da Sie für die URL-Zuordnung einen Standarddienst (td-gke-service) konfiguriert haben, wird jede ausgehende Anfrage, die von einem Sidecar-Proxy verarbeitet wird, an die Back-Ends weitergeleitet, die diesem Standarddienst zugeordnet sind.

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

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

Nächste Schritte

• Weitere Informationen zur Erweiterten Trafficverwaltung.
• Sicherheit von Traffic Director-Diensten.
• Beobachtbarkeit mit Envoy einrichten.
• Probleme bei Traffic Director-Bereitstellungen beheben
• Optionen für die Einrichtung des Google Kubernetes Engine-Pods mit automatischer Envoy-Einfügung.