text: 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.
  Hinweis: Die Konfigurationsbeispiele dienen zu Demonstrationszwecken. Möglicherweise müssen Sie je nach Umgebung und Anforderungen zusätzliche Komponenten bereitstellen.
  Bevor Sie der Anleitung in diesem Leitfaden folgen, lesen Sie die Informationen unter Einrichtung von Traffic Director vorbereiten und achten Sie darauf, 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 beschrieben, damit GKE/Kubernetes-Cluster mit Traffic Director zusammenarbeiten können.
  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 Standalone-Netzwerk-Endpunktgruppen. Das Standalone-NEG-Feature ist für Traffic Director allgemein 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, die durch OAuth-Authentifizierung geschützt ist. Weitere Informationen finden Sie in der Übersicht über den Konfigurationsprozess.
  Das folgende Beispiel zeigt, wie Sie einen GKE-Cluster mit dem Namen traffic-director-cluster in der Zone us-central1-a erstellen.
  Rufen Sie in der Cloud Console das Menü "Kubernetes Engine" auf.
  Zum Kubernetes Engine-Menü
  Name: Geben Sie traffic-director-cluster ein.
  Standorttyp: Zonal.
  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.
  Klicken Sie im Navigationsbereich unter Standardpool auf Knoten.
  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 Preisübersicht für Compute Engine.
  Klicken Sie unter Zugriffsbereiche auf Uneingeschränkten Zugriff auf alle Cloud APIs zulassen.
  Passen Sie den Cluster nach Bedarf an.
  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 Eintrag in kubeconfig generieren.
  Erforderliche GKE-Clusterberechtigungen abrufen
  Wechseln Sie in GKE zum gerade erstellten Cluster (2). Führen Sie dafür den folgenden Befehl aus. Dadurch wird kubectl auf den richtigen Cluster verwiesen.
  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.
  Wenn Sie prüfen möchten, ob die Back-End-Pods ausgeführt werden, müssen Sie eine Firewallregel konfigurieren, die die IP-Adressbereiche der Systemdiagnose zulässt.
  Ziele: Wählen Sie Alle Instanzen im Netzwerk 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.
  Erstellen Sie mit dem folgenden gcloud-Befehl 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.
  Weitere Informationen finden Sie unter Erforderliche Firewallregeln.
  GKE/Kubernetes-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.
  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 Standalone-Netzwerk-Endpunktgruppen.
  Zu Demonstrationszwecken können Sie einen Beispieldienst bereitstellen, der seinen Hostnamen über HTTP an Port 80 sendet:
  Prüfen Sie, ob der neue Diensthostname erstellt wurde und der Anwendungs-Pod ausgeführt wird:
  Name der NEG speichern
  Suchen Sie die NEG, die im obigen Beispiel erstellt wurde, und notieren Sie den Namen der NEG.
  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
  Speichern Sie den NEG-Namen in der Variablen NEG_NAME. Beispiel:
  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.
  Google Cloud-Load-Balancing-Komponenten für Traffic Director konfigurieren
  Mit den Anleitungen in diesem Abschnitt wird dafür gesorgt, dass GKE-Dienste über die Dienst-VIP zugänglich sind, bei der das Load-Balancing durch Traffic Director erfolgt. Dabei wird eine Load-Balancing-Konfiguration verwendet, die anderen Google Cloud Load Balancing-Produkten ähnelt.
  Sie müssen die folgenden Komponenten konfigurieren:
  Eine Routingregel. Dies umfasst das Erstellen einer Weiterleitungsregel und einer URL-Zuordnung. Weitere Informationen finden Sie unter Weiterleitungsregeln verwenden und URL-Zuordnungen verwenden.
  Im folgenden Konfigurationsbeispiel für Traffic Director werden diese Annahmen getroffen:
  Die NEGs und alle anderen Ressourcen werden im default-Netzwerk mit automatischem Modus in der Zone us-central1-a erstellt.
  Der NEG-Name für den Cluster wird in der Variable ${NEG_NAME} gespeichert.
  Geben Sie als Name td-gke-health-check ein.
  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.
  Geben Sie als Dienstname td-gke-service ein.
  Wählen Sie unter Back-End-Typ Netzwerk-Endpunktgruppen aus.
  Wählen Sie die erstellte Netzwerk-Endpunktgruppe aus.
  Legen Sie die Maximale Anzahl der Anfragen pro Sekunde auf 5 fest.
  Wählen Sie unter Systemdiagnose td-gke-health-check aus. Dies ist die Systemdiagnose, die Sie erstellt haben.
  Erstellen Sie den Back-End-Dienst und verknüpfen Sie die Systemdiagnose damit.
  Fügen Sie dem Back-End-Dienst die Back-End-NEGs hinzu.
  Sie können die Adresse Ihrer Weiterleitungsregel auf 0.0.0.0 festlegen. Dabei 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 URLs (Hostname und URL-Pfad) Ihrer Dienste gemäß den Hostregeln in der 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 anhand der in der URL-Zuordnung angegebenen HTTP-Parameter nur Anfragen an diese IP-Adresse weitergeleitet.
  Hinweis: Unabhängig von der ausgewählten Methode muss Traffic an die VIP-Adresse, in die Ihr Diensthostname aufgelöst wird, vom Sidecar-Proxy auf dem Clienthost abgefangen werden, der auf Ihren Dienst zugreifen muss. Ausführliche Informationen zur Hostkonfiguration finden Sie unter Einzelne Compute Engine-VM für Traffic Director konfigurieren.
  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).
  Klicken Sie auf Routingregelzuordnungen.
  Klicken Sie auf Routingregel erstellen.
  Geben Sie als Name der URL-Zuordnung td-gke-url-map ein.
  Geben Sie als Name für die Weiterleitungsregel td-gke-forwarding-rule ein.
  Wählen Sie Ihre Interne IP-Adresse aus.
  Fügen Sie optional benutzerdefinierte Host- und Pfadregeln hinzu oder behalten Sie die Pfadregeln als Standard bei.
  Legen Sie den Host auf service-test fest.
  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. service-test ist auch der konfigurierte Name des Kubernetes-Dienstes, der in der obigen Beispielkonfiguration verwendet wird.
  Zu diesem Zeitpunkt ist Traffic Director so konfiguriert, dass das Load-Balancing des Traffics für die in der URL-Zuordnung angegebenen Dienste über Back-Ends in der Netzwerk-Endpunktgruppe erfolgt.
  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 durch Bereitstellung eines Beispielclients für Tests prüfen
  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, der im vorherigen Abschnitt erstellt wurde und Traffic empfängt, bei dem das Load-Balancing durch Traffic Director erfolgt.
  Sidecar-Proxy in GKE/Kubernetes-Pods einfügen
  Für den Zugriff auf einen von Traffic Director verwalteten Dienst muss ein xDS API-kompatibler Sidecar-Proxy auf einem Pod installiert sein.
  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: Ersetzen Sie die Variablen PROJECT_NUMBER und NETWORK_NAME durch Ihre Projektnummer und den Netzwerknamen:
  Im Busybox-Pod sind zwei Container aktiv. Der erste Container ist der Client, der auf dem Busybox-Image beruht, und der zweite Container ist der als Sidecar eingefügte Envoy-Proxy. Mit dem folgenden Befehl können Sie weitere Informationen zum Pod abrufen:
  Auf Back-End-Dienst zugreifen
  Nach der Konfiguration haben Anwendungen auf Pods mit eingefügtem Sidecar-Proxy Zugriff auf von Traffic Director-Diensten verwaltete Dienste. 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 Befehl prüfen, ob der Hostname des Bereitstellungs-Pods zurückgegeben wird.
  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 Demoanwendung verwendet den Envoy-Proxy. Aus diesem Grund sieht der Client "server: envoy" im Header der Serverantworten.
  Verwenden Sie zur Bestätigung die folgenden Befehle:
  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-Hostheader mit dem in der URL-Zuordnung service-test definierten Host übereinstimmt.