Traffic Director-Einrichtung mit Google Kubernetes Engine-Pods

In dieser Anleitung erfahren Sie, wie Sie Google Kubernetes Engine- oder Kubernetes-Pod-Hosts und die Load-Balancing-Komponenten konfigurieren, die Traffic Director benötigt.

Bevor Sie die Anleitung in dieser Anleitung befolgen, lesen Sie die Informationen unter Traffic Director-Einrichtung vorbereiten und stellen Sie sicher, dass Sie die Voraussetzungen erfüllt haben.

Sie können Traffic Director mit dem Compute Engine-Load-Balancing-SDK oder mit REST APIs konfigurieren. Weitere Informationen finden Sie in den Load-Balancing API- und gcloud-Referenzen.

GKE/Kubernetes-Cluster für Traffic Director konfigurieren

In diesem Abschnitt werden die erforderlichen Schritte zum Aktivieren von GKE/Kubernetes-Clustern für Traffic Director beschrieben.

GKE-Cluster erstellen

GKE-Cluster müssen die folgenden Voraussetzungen erfüllen:

  • Die Unterstützung von Netzwerk-Endpunktgruppen muss aktiviert sein. Weitere Informationen und Beispiele finden Sie unter Eigenständige Netzwerk-Endpunktgruppen. Die eigenständige NEG-Funktion ist in der allgemeinen Verfügbarkeit für Traffic Director verfügbar.
  • Das Dienstkonto der Clusterknoteninstanzen muss über die Berechtigung zum Zugriff auf die Traffic Director API verfügen. Weitere Informationen zu den erforderlichen Berechtigungen finden Sie unter Dienstkonto für den Zugriff auf die Traffic Director API aktivieren.
  • Die Container müssen Zugriff auf die Traffic Director API haben und durch OAuth-Authentifizierung geschützt sein. Weitere Informationen finden Sie unter Hostkonfiguration.

Das folgende Beispiel zeigt, wie Sie einen GKE-Cluster namens traffic-director-cluster in der Zone us-central1-a erstellen.

Console

Zum Erstellen eines Clusters mit der Cloud Console führen Sie die folgenden Schritte aus:

  1. Rufen Sie in der Cloud Console das Menü "Kubernetes Engine" auf.

    Rufen Sie das Kubernetes Engine-Menü auf

  2. Klicken Sie auf Cluster erstellen.

  3. Füllen Sie die folgenden Felder aus:

    • Name: Geben Sie traffic-director-cluster ein.
    • Standorttyp: Zonal.
    • Zone:us-central1-a.
  4. Klicken Sie im Navigationsbereich unter Knotenpools auf default-pool.

  5. Das Feld Größe gibt die Anzahl der Knoten an, die im Cluster erstellt werden sollen. Sie müssen verfügbare Ressourcenkontingente für die Knoten und ihre Ressourcen (z. B. Firewallrouten) haben.

  6. Klicken Sie im Navigationsbereich unter Standardpool auf Knoten.

  7. Das Feld Maschinentyp gibt den Compute Engine-Maschinentyp an, der für die Instanzen verwendet werden soll. Jeder Maschinentyp wird unterschiedlich abgerechnet. Informationen zu Preisen für Maschinentypen finden Sie auf der Preisseite zu Compute Engine.

  8. Klicken Sie im Navigationsbereich unter Standardpool auf Sicherheit.

  9. Klicken Sie unter Zugriffsbereiche auf Uneingeschränkten Zugriff auf alle Cloud APIs zulassen.

  10. Passen Sie den Cluster nach Bedarf an.

  11. Klicken Sie auf Erstellen.

Nachdem Sie einen Cluster in der Cloud Console erstellt haben, müssen Sie kubectl für die Interaktion mit dem Cluster konfigurieren. Weitere Informationen finden Sie unter kubeconfig-Eintrag generieren.

gcloud

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

Erforderliche GKE-Clusterberechtigungen abrufen

Wechseln Sie für GKE zum gerade erstellten Cluster(2), indem Sie den folgenden Befehl ausführen. Dadurch wird kubectl auf den richtigen Cluster verweisen.

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

GKE/Kubernetes-Dienste konfigurieren

In diesem Abschnitt wird gezeigt, wie Sie die Kubernetes-Bereitstellungsspezifikationen auf die Zusammenarbeit mit Traffic Director vorbereiten. Dazu werden Dienste mit NEGs konfiguriert und Sidecar-Proxys in Pods eingefügt, die Zugriff auf die von Traffic Director verwalteten Dienste benötigen.

Firewallregeln konfigurieren

Zum Prüfen, ob die Back-End-Pods ausgeführt werden, müssen Sie eine Firewallregel konfigurieren, die die IP-Adressbereiche der Systemdiagnose zulässt.

Console

  1. Rufen Sie in der Google Cloud Console die Seite "Firewallregeln" auf.
    Zur Seite "Firewall"
  2. Klicken Sie auf Firewallregel erstellen.
  3. 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. Mit dem folgenden gcloud-Befehl erstellen Sie eine Firewallregel mit dem Namen fw-allow-health-checks, die eingehende Verbindungen zu Instanzen in Ihrem Netzwerk mit dem Tag allow-health-checks zulässt. Ersetzen Sie NETWORK_NAME durch den Namen Ihres Netzwerks.

    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

Weitere Informationen finden Sie unter Firewallregel für Systemdiagnosen konfigurieren.

GKE/Kubernetes-Dienste mit NEGs konfigurieren

Der erste Schritt bei der Konfiguration von GKE / Kubernetes-Diensten mit NEGs besteht darin, die Dienste verfügbar zu machen, die von Traffic Director verwaltet werden müssen. Um über NEGs verfügbar gemacht zu werden, muss jede Spezifikation die folgende Annotation haben, die dem Port entspricht, den Sie bereitstellen möchten.

...
metadata:
  annotations:
    cloud.google.com/neg: '{"exposed_ports":{"80":{}}}'

Für jeden Dienst wird eine eigenständige NEG erstellt, deren Endpunkte die IP-Adressen und Ports des Pods sind. Weitere Informationen und Beispiele finden Sie unter Eigenständige Netzwerk-Endpunktgruppen.

Zu Demonstrationszwecken können Sie einen Beispieldienst bereitstellen, der seinen Hostnamen über HTTP an Port 80 sendet:

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

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

kubectl get svc

Diese meldet

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

kubectl get pods

Diese meldet

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

NEG-Name aufzeichnen

Suchen Sie die NEG, die im obigen Beispiel erstellt wurde, und notieren Sie den Namen der NEG.

Console

Sie können sich eine Liste der Netzwerk-Endpunktgruppen anzeigen lassen. Rufen Sie dazu die Seite "Netzwerk-Endpunktgruppen" in der Google Cloud Console auf.
Zur Seite "Netzwerk-Endpunktgruppen"

gcloud

gcloud beta compute network-endpoint-groups list

Diese meldet

NAME                                           LOCATION       ENDPOINT_TYPE   SIZE
k8s1-7e91271e-default-service-test-80-a652810c  us-central1-a  GCE_VM_IP_PORT  1

Speichern Sie den NEG-Namen in der Variablen NEG_NAME. Beispiel:

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

Google Cloud-Load-Balancing-Komponenten für Traffic Director konfigurieren

Mit den Anleitungen in diesem Abschnitt wird sichergestellt, dass GKE-Dienste über das Dienst-VIP-Load-Balancing von Traffic Director zugänglich sind. Dabei wird eine Load-Balancing-Konfiguration verwendet, die anderen Google Cloud Load Balancing-Produkten ähnelt.

Sie müssen die folgenden Komponenten konfigurieren:

Im folgenden Konfigurationsbeispiel für Traffic Director werden diese Annahmen getroffen:

  1. Die NEGs und alle anderen Ressourcen werden im default-Netzwerk mit automatischem Modus in der Zone us-central1-a erstellt.
  2. Der NEG-Name für den Cluster wird in der Variablen ${NEG_NAME} gespeichert.

Systemdiagnose erstellen

Erstellen Sie die Systemdiagnose:

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 im Feld td-gke-health-check ein.
  4. Wählen Sie als Protokoll HTTP aus.
  5. Klicken Sie auf Erstellen.

gcloud

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

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 Dienstnamen td-gke-service ein.

  5. Wählen Sie unter Backend-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 die Systemdiagnose td-gke-health-check aus, 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 Back-End-NEGs 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
    

Routingregel, Weiterleitungsregel und interne IP-Adresse erstellen

Folgen Sie dieser Anleitung, um die Routingregel, die Weiterleitungsregel und die interne IP-Adresse für Ihre Traffic Director-Konfiguration zu erstellen.

Der an die interne IP-Adresse gesendete Traffic wird vom Envoy-Proxy abgefangen und gemäß den Host- und Pfadregeln an den entsprechenden Dienst gesendet.

Die Weiterleitungsregel wird als globale Weiterleitungsregel erstellt, wobei load-balancing-scheme auf INTERNAL_SELF_MANAGED gesetzt ist.

Sie können die Adresse Ihrer Weiterleitungsregel auf 0.0.0.0 festlegen. In diesem Fall wird der Traffic basierend auf dem in der URL-Zuordnung konfigurierten HTTP-Hostnamen und den Pfadinformationen weitergeleitet, unabhängig von der tatsächlichen IP-Adresse, in die der Hostname aufgelöst wird. In diesem Fall müssen die in den Hostregeln konfigurierten URLs (Hostname und URL-Pfad) Ihrer Dienste innerhalb Ihrer Service Mesh-Konfiguration eindeutig sein. Sie können z. B. nicht zwei verschiedene Dienste mit unterschiedlichen Back-Ends haben, die beide dieselbe Kombination aus Hostname und Pfad verwenden.

Alternativ können Sie das Routing basierend auf der tatsächlichen Ziel-VIP des Dienstes aktivieren. Wenn Sie die VIP Ihres Dienstes als address-Parameter der Weiterleitungsregel konfigurieren, werden nur Anfragen an diese IP-Adresse weitergeleitet, die auf den in der URL-Zuordnung angegebenen HTTP-Parametern basieren.

Console

In der Console wird der Ziel-Proxy mit der Weiterleitungsregel kombiniert. Wenn Sie die Weiterleitungsregel erstellen, erstellt Google Cloud automatisch einen Ziel-HTTP-Proxy und hängt ihn an die URL-Zuordnung an.

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 dem Tab Richtlinien auf Routingregel erstellen.

  3. Geben Sie einen Richtliniennamen ein.

  4. Klicken Sie auf Weiterleitungsregel hinzufügen.

  5. Geben Sie als Namen für die Weiterleitungsregel td-gke-forwarding-rule ein.

  6. Wählen Sie Ihr Netzwerk aus.

  7. Wählen Sie Ihre interne IP-Adresse aus.

  8. Klicken Sie auf Speichern.

  9. Optional können Sie benutzerdefinierte Host- und Pfadregeln hinzufügen oder die Pfadregeln als Standard beibehalten und den Host auf service-test setzen.

  10. Klicken Sie auf Speichern.

gcloud

  1. Erstellen Sie eine URL-Zuordnung, die den Back-End-Dienst verwendet.

    gcloud compute url-maps create td-gke-url-map \
       --default-service td-gke-service
    
  2. Erstellen Sie einen URL-Map-Matcher und eine Hostregel, um den Traffic für Ihren Dienst basierend auf Hostname und Pfad weiterzuleiten. In diesem Beispiel werden service-test als Dienstname und ein Standardpfad-Matcher verwendet, der mit allen Pfadanfragen für diesen Host (/*) übereinstimmt. service-test ist auch der konfigurierte Name des Kubernetes-Dienstes, der in der obigen Beispielkonfiguration verwendet wird.

    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
    

Zu diesem Zeitpunkt ist Traffic Director so konfiguriert, dass der Traffic für die in der URL-Zuordnung angegebenen Dienste über Back-Ends in der Netzwerk-Endpunktgruppe verteilt wird.

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.

Konfiguration prüfen, indem Sie einen Beispielclient für Tests bereitstellen

In diesem Abschnitt wird gezeigt, wie Sie Traffic Director-Back-Ends über eine Clientanwendung erreichen.

Zur Veranschaulichung der Funktionalität können Sie einen Beispiel-Pod mit Busybox bereitstellen. Der Pod hat Zugriff auf service-test, das im vorherigen Abschnitt erstellt wurde, und empfängt Traffic, der von Traffic Director verteilt wird.

Sidecar-Proxy in GKE/Kubernetes-Pods einfügen

Für den Zugriff auf einen von Traffic Director verwalteten Dienst muss auf einem Pod ein xDS API-kompatibler Sidecar-Proxy installiert sein.

Die folgenden Schritte stellen eine Referenzkonfiguration für eine bestimmte Anwendungsbereitstellung mit Sidecar-Einfügung bereit.

  1. Laden Sie die Referenzspezifikation von https://storage.googleapis.com/traffic-director/trafficdirector_istio_sidecar.yaml herunter.
  2. Ändern Sie die Anwendungsbereitstellungsspezifikation, indem Sie zwei weitere Containerspezifikationen aus der Datei trafficdirector_istio_sidecar.yaml hinzufügen:
    1. Sidecar-Proxy-Container, der die Envoy-Bootstrap-Konfiguration einrichtet und Envoy startet (siehe das Beispiel des in trafficdirector_istio_sidecar.yaml definierten Istio-Proxy-Containers).
    2. Init-Container, der die erforderlichen netfilter-Regeln für das Abfangen einrichtet und mit den erforderlichen Berechtigungen zum Ändern von netfilter ausgeführt wird (siehe das Beispiel für initContainer, das in trafficdirector_istio_sidecar.yaml definiert ist).
  3. (Optional) Geben Sie den IP-Adressbereich für den Traffic an, der von einem Sidecar-Proxy abgefangen werden soll. Ersetzen Sie dazu den Parameter "-i"*"" im Abschnitt "args" der initContainers -Definition durch eine IP-Adresse des Dienstes, für den Traffic umgeleitet wird. Standardmäßig wird der gesamte Traffic abgefangen.
    1. Sie können beispielsweise "-i" 10.0.0.0/24" angeben, um nur den Traffic für den Bereich 10.0.0.0/24 umzuleiten.
  4. Stellen Sie die Pods mit der neuen Bereitstellungsspezifikation wieder bereit.

In diesem Beispiel stellen Sie einen Busybox-Client mit einem Istio-Proxy-Sidecar und Init-Containern bereit, die mithilfe der Referenzspezifikation zur Bereitstellung hinzugefügt wurden:

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

Im Busybox-Pod sind zwei Container aktiv. Der erste Container ist der Client, der auf dem Busybox-Image basiert, und der zweite Container ist der als Sidecar eingefügte Envoy-Proxy. Mit dem folgenden Befehl können Sie weitere Informationen zum Pod abrufen:

kubectl describe pods -l run=client

Auf Back-End-Dienst zugreifen

Nach der Konfiguration können Anwendungen auf Pods, in die ein Sidecar-Proxy eingefügt ist, auf von Traffic Director-Diensten verwaltete Dienste zugreifen. Zum Prüfen der Konfiguration können Sie in einem der Container auf eine Shell zugreifen.

Wenn Sie die in dieser Anleitung enthaltene Demokonfiguration verwendet haben, können Sie mit dem folgenden Überprüfungsbefehl prüfen, ob der Hostname des Bereitstellungs-Pods zurückgegeben wird.

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

Informationen zum Abfangen von Traffic durch den Sidecar-Proxy

Wenn der Busybox-Client in diesem Beispiel Anfragen an den Back-End-Dienst stellt, wird jede Anfrage vom Sidecar-Proxy weitergeleitet.

Diese Demonstrationsanwendung verwendet den Envoy-Proxy. Aus diesem Grund sieht der Client "server: envoy" im Header der Serverantworten.

Verwenden Sie zur Bestätigung die folgenden Befehle:

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

In diesem Beispiel haben Sie eine Weiterleitungsregel mit der VIP-Adresse 0.0.0.0 erstellt. Dies bedeutet, dass Traffic Director Anfragen nur basierend auf dem Header Host an das Back-End weiterleitet. In diesem Fall kann die Ziel-IP-Adresse eine beliebige Adresse sein, solange der Anfrage-Host-Header mit dem in der URL-Zuordnung service-test definierten Host übereinstimmt.

Führen Sie die folgenden Testbefehle aus, um dies zu bestätigen:

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