Externe Back-Ends einrichten

Dieses Dokument enthält eine Anleitung zum Konfigurieren externer Back-Ends für Traffic Director mithilfe von Internetnetzwerk-Endgruppen (NEGs) mit vollständig qualifizierten Domainnamen (FQDN). Es wird davon ausgegangen, dass Sie sich mit fortgeschrittenen Kenntnissen zu den folgenden Themen auskennen:

• Externer Application Load Balancer
• Cloud DNS
• Traffic Director
• Hybridkonnektivität

Dieser Einrichtungsleitfaden enthält grundlegende Anleitungen zu folgenden Themen:

• Traffic Director für die Verwendung einer Internet-NEG und eines nicht authentifizierten TLS für ausgehenden Traffic konfigurieren
• Traffic von Ihrem Service Mesh an einen Cloud Run-Dienst weiterleiten

Hinweise

Lesen Sie die Übersicht zu Traffic Director mit Internetnetzwerk-Endpunktgruppen.

Für die Zwecke dieser Anleitung wird bei den Beispielkonfigurationen Folgendes vorausgesetzt:

• Alle relevanten Compute Engine-Ressourcen wie Mittelproxys, Traffic Director-Ressourcen, Cloud DNS-Zonen und Hybridkonnektivität sind dem Virtual Private Cloud-Standardnetzwerk zugeordnet.
• Der Dienst example.com:443 wird in Ihrer lokalen Infrastruktur ausgeführt. Die Domain example.com wird von drei Endpunkten bereitgestellt: 10.0.0.100, 10.0.0.101 und 10.0.0.102. Es gibt Routen, die die Konnektivität von den Envoy-Proxys zu diesen Remote-Endpunkten gewährleisten.

Die resultierende Bereitstellung sieht in etwa so aus:

Beispieleinrichtung mit einer Internet-NEG (zum Vergrößern klicken)

Traffic-Routing mit einer Internet-NEG und einem TLS mit SNI

Nachdem Sie Traffic Director mit einer Internet-NEG unter Verwendung des FQDN und der TLS für ausgehenden Traffic konfiguriert haben, verhält sich die Beispielbereitstellung wie im folgenden Diagramm und der Beschreibung des Traffics dargestellt.

Weiterleitung des Traffics im Beispiel (zum Vergrößern klicken)

Die Schritte in der folgenden Legende entsprechen der Nummerierung im vorherigen Diagramm.

Schritt	Beschreibung
0	Envoy empfängt die FQDN-Back-End-Konfiguration von Traffic Director über xDS.
0	In der VM ausgeführter Envoy fragt das DNS kontinuierlich nach dem konfigurierten FQDN ab.
1	Die Nutzeranwendung initiiert eine Anfrage.
2	Parameter der Anfrage.
3	Der Envoy-Proxy fängt die Anfrage ab. In diesem Beispiel wird davon ausgegangen, dass Sie 0.0.0.0 als virtuelle IP-Adresse (VIP) für die Weiterleitungsregel verwenden. Wenn 0.0.0.0 die VIP ist, fängt Envoy alle Anfragen ab. Das Anfragenrouting basiert nur auf Parametern der Ebene 7, unabhängig von der Ziel-IP-Adresse in der ursprünglichen Anfrage, die von der Anwendung generiert wird.
4	Envoy wählt einen fehlerfreien Remote-Endpunkt aus und führt einen TLS-Handshake mit der SNI aus der Client-TLS-Richtlinie durch.
5	Envoy leitet die Anfrage an den Remote-Endpunkt weiter.

Wenn Systemdiagnosen konfiguriert sind, prüft Envoy kontinuierlich die Remote-Endpunkte und leitet Anfragen nur an fehlerfreie Endpunkte weiter. Im Diagramm ist dies allerdings nicht dargestellt.

Hybridkonnektivität einrichten

In diesem Dokument wird auch davon ausgegangen, dass Hybridkonnektivität bereits hergestellt wurde.

• Über Cloud VPN oder Cloud Interconnect wird Hybridkonnektivität zwischen dem VPC-Netzwerk und lokalen Diensten oder einer öffentlichen Cloud eines Drittanbieters hergestellt.
• VPC-Firewallregeln und -Routen sind richtig konfiguriert, um die bidirektionale Erreichbarkeit von Envoy für private Dienstendpunkte und optional für einen lokalen DNS-Server einzurichten.
• Für ein erfolgreiches regionales HA-Failover-Szenario ist das globale dynamische Routing aktiviert. Weitere Informationen finden Sie unter Modus für dynamisches Routing.

Cloud DNS-Konfiguration einrichten

Verwenden Sie die folgenden Befehle, um eine private Cloud DNS-Zone für die Domain (FQDN) example.com einzurichten, die A-Einträge mit Verweis auf 10.0.0.100, 10.0.0.101, 10.0.0.102 und 10.0.0.103 hat.

gcloud

1. Erstellen Sie eine von DNS verwaltete private Zone und hängen Sie sie an das Standardnetzwerk an.

   gcloud dns managed-zones create example-zone \
       --description=test \
       --dns-name=example.com \
       --networks=default \
       --visibility=private
   

2. Fügen Sie der privaten Zone DNS-Einträge hinzu.

   gcloud dns record-sets transaction start \
       --zone=example-zone
   
   gcloud dns record-sets transaction add 10.0.0.100 10.0.0.101 10.0.0.102 10.0.0.103 \
       --name=example.com \
       --ttl=300 \
       --type=A \
       --zone=example-zone
   
   gcloud dns record-sets transaction execute \
       --zone=example-zone
   

Traffic Director mit einer Internet-FQDN-NEG konfigurieren

In diesem Abschnitt konfigurieren Sie Traffic Director mit einer Internet-FQDN-NEG.

NEG, Systemdiagnose und Back-End-Dienst erstellen

gcloud

1. Erstellen Sie die Internet-NEG:

   gcloud compute network-endpoint-groups create on-prem-service-a-neg \
       --global \
       --network-endpoint-type INTERNET_FQDN_PORT
   

2. Fügen Sie der Internet-NEG den Endpunkt FQDN:Port hinzu:

   gcloud compute network-endpoint-groups update on-prem-service-a-neg \
       --global \
       --add-endpoint=fqdn=example.com,port=443
   

3. Erstellen Sie eine globale Systemdiagnose:

   gcloud compute health-checks create http service-a-http-health-check \
       --global
   

4. Erstellen Sie einen globalen Back-End-Dienst mit dem Namen on-prem-service-a und verknüpfen Sie die Systemdiagnose damit:

   gcloud compute backend-services create on-prem-service-a \
       --global \
       --load-balancing-scheme=INTERNAL_SELF_MANAGED \
       --health-checks service-a-http-health-check
   

5. Fügen Sie die NEG on-prem-service-a-neg als Back-End des Back-End-Dienstes hinzu:

   gcloud compute backend-services add-backend on-prem-service-a \
       --global \
       --global-network-endpoint-group \
       --network-endpoint-group on-prem-service-a-neg
   

Zuordnung einer Routingregel erstellen

Die URL-Zuordnung, der Ziel-HTTP-Proxy und die Weiterleitungsregel stellen eine Routingregelzuordnung dar, die Routinginformationen zu Traffic in Ihrem Mesh-Netzwerk bereitstellt.

Diese URL-Zuordnung enthält eine Regel, die den gesamten HTTP-Traffic an on-prem-service-a weiterleitet.

gcloud

1. Erstellen Sie die URL-Zuordnung:

   gcloud compute url-maps create td-url-map \
       --default-service on-prem-service-a
   

2. Erstellen Sie den Ziel-HTTP-Proxy und verknüpfen Sie die URL-Zuordnung mit dem Zielproxy:

   gcloud compute target-http-proxies create td-proxy \
       --url-map td-url-map
   

3. Erstellen Sie die globale Weiterleitungsregel mithilfe der IP-Adresse 0.0.0.0. Dies ist eine spezielle IP-Adresse, die dazu führt, dass die Datenebene die Ziel-IP-Adresse ignoriert und Anfragen nur auf Grundlage der HTTP-Parameter der Anfrage weiterleitet.

   gcloud compute forwarding-rules create td-forwarding-rule \
       --global \
       --load-balancing-scheme=INTERNAL_SELF_MANAGED \
       --address=0.0.0.0 \
       --target-http-proxy=td-proxy \
       --ports=443 \
       --network=default
   

Nicht authentifiziertes TLS und HTTPS konfigurieren

Wenn Sie nicht authentifiziertes HTTPS zwischen Ihren Envoy-Proxys und Ihren lokalen Diensten konfigurieren möchten, folgen Sie optional dieser Anleitung. Diese Anleitung zeigt auch, wie SNI im TLS-Handshake konfiguriert wird.

Eine Client-TLS-Richtlinie gibt die Clientidentität und den Authentifizierungsmechanismus an, wenn ein Client ausgehende Anfragen an einen bestimmten Dienst sendet. Eine Client-TLS-Richtlinie wird mithilfe des Felds securitySettings an eine Back-End-Dienstressource angehängt.

gcloud

1. Erstellen und importieren Sie die Client-TLS-Richtlinie. Legen Sie die SNI auf den FQDN fest, den Sie in der NEG konfiguriert haben:

   cat << EOF > client_unauthenticated_tls_policy.yaml
   name: "client_unauthenticated_tls_policy"
   sni: "example.com"
   EOF
   
   gcloud beta network-security client-tls-policies import client_unauthenticated_tls_policy \
       --source=client_unauthenticated_tls_policy.yaml \
       --location=global
   

2. Wenn Sie im vorherigen Abschnitt eine HTTP-Systemdiagnose mit dem Back-End-Dienst konfiguriert haben, trennen Sie die Systemdiagnose vom Back-End-Dienst:

   gcloud compute backend-services update on-prem-service-a \
       --global \
       --no-health-checks
   

3. Erstellen Sie eine HTTPS-Systemdiagnose:

   gcloud compute health-checks create https service-a-https-health-check \
       --global
   

4. Hängen Sie die Client-TLS-Richtlinie an den zuvor erstellten Back-End-Dienst an. Dadurch wird nicht authentifiziertes HTTPS für alle ausgehenden Anfragen vom Client an diesen Back-End-Dienst erzwungen:

   gcloud compute backend-services export on-prem-service-a \
       --global \
       --destination=on-prem-service-a.yaml
   
   cat << EOF >> on-prem-service-a.yaml
   securitySettings:
     clientTlsPolicy: projects/${PROJECT_ID}/locations/global/clientTlsPolicies/client_unauthenticated_tls_policy
   healthChecks:
     - projects/${PROJECT_ID}/global/healthChecks/service-a-https-health-check
   EOF
   
   gcloud compute backend-services import on-prem-service-a \
       --global \
       --source=on-prem-service-a.yaml
   

Sie können Internet-FQDN-NEGs verwenden, um Traffic an jeden Dienst weiterzuleiten, der über FQDN erreichbar ist, z. B. externe DNS-auflösbare externe und interne Dienste oder Cloud Run-Dienste.

Von einer IP:Port-NEG zu einer FQDN:Port-NEG migrieren

Bei einer NON_GCP_PRIVATE_IP_PORT-NEG müssen Dienstendpunkte als statische IP:PORT-Paare in die NEG programmiert werden, während INTERNET_FQDN_NEG die Endpunkte mithilfe von DNS dynamisch auflösen kann. Sie können zur Internet-NEG migrieren, indem Sie DNS-Einträge für Ihre lokalen Dienstendpunkte einrichten und Traffic Director konfigurieren, wie in den folgenden Schritten beschrieben:

1. Richten Sie DNS-Einträge für Ihren FQDN ein.
2. Erstellen Sie eine neue Internet-NEG mit dem FQDN.
3. Erstellen Sie einen neuen Back-End-Dienst mit der Internet-NEG, die Sie in Schritt 2 als Back-End erstellt haben. Verknüpfen Sie dieselbe Systemdiagnose, die Sie mit dem NEG-Back-End-Dienst für Hybridkonnektivität verwendet haben, mit dem neuen Back-End-Dienst. Prüfen Sie, ob die neuen Remote-Endpunkte fehlerfrei sind.
4. Aktualisieren Sie Ihre Routingregelzuordnung, um auf den neuen Back-End-Dienst zu verweisen. Ersetzen Sie dazu das alte Back-End, das die Hybrid-Konnektivitäts-NEG enthält.
5. Wenn Sie während der Live-Migration in einer Produktionsbereitstellung keine Ausfallzeiten haben möchten, können Sie gewichteten Traffic verwenden. Konfigurieren Sie Ihren neuen Back-End-Dienst zu Beginn so, dass nur ein kleiner Prozentsatz des Traffics empfangen wird, z. B. 5 %. Folgen Sie der Anleitung zum Einrichten der Trafficaufteilung.
6. Prüfen Sie, ob die neuen Remote-Endpunkte den Diensttraffic korrekt verarbeiten.
7. Wenn Sie die gewichtete Traffic-Aufteilung verwenden, konfigurieren Sie den neuen Back-End-Dienst so, dass er 100 % des Traffics empfängt. Mit diesem Schritt wird der alte Back-End-Dienst per Drain beendet.
8. Nachdem Sie geprüft haben, ob die neuen Back-Ends problemlos Traffic bereitstellen, löschen Sie den alten Back-End-Dienst.

Fehlerbehebung

Folgen Sie der Anleitung in diesem Abschnitt, um Probleme bei der Bereitstellung zu beheben. Wenn Ihre Probleme mit diesen Informationen nicht behoben werden, lesen Sie Fehlerbehebung bei Bereitstellungen, die Envoy verwenden.

Ein lokaler Endpunkt empfängt keinen Traffic

Wenn ein Endpunkt keinen Traffic empfängt, prüfen Sie, ob Systemdiagnosen und DNS-Abfragen des Envoy-Clients konsistent die IP-Adresse zurückgeben.

Envoy verwendet den strict_dns-Modus zum Verwalten von Verbindungen. Dabei wird der Traffic auf alle aufgelösten Endpunkte verteilt, die fehlerfrei sind. Die Reihenfolge, in der Endpunkte aufgelöst werden, spielt im strict_dns-Modus keine Rolle. Envoy beendet den Traffic jedoch per Drain an jedem Endpunkt, der nicht mehr in der Liste der zurückgegebenen IP-Adressen vorhanden ist.

HTTP-Host-Header stimmt nicht mit FQDN überein, wenn die Anfrage meinen lokalen Server erreicht

Stellen Sie sich ein Beispiel vor, in dem die Domain example.com in 10.0.0.1 aufgelöst wird. Die IP-Adresse der Weiterleitungsregel und die Domain altostrat.com werden in 10.0.0.100 aufgelöst. Dies ist Ihr lokaler Dienstendpunkt. Sie möchten Traffic an die Domain altostrat.com senden, die in Ihrer NEG konfiguriert ist.

Es ist möglich, dass die Anwendung in Compute Engine oder GKE den HTTP-Header Host auf example.com (Host: example.com) setzt, der an den lokalen Endpunkt übertragen wird. Wenn Sie HTTPS verwenden, setzt Envoy die SNI während des TLS-Handshakes auf altostrat.com. Envoy erhält die SNI von der TLS-Richtlinienressource des Clients.

Wenn dieser Konflikt Probleme bei der Verarbeitung oder Weiterleitung der Anfrage verursacht, wenn sie den lokalen Endpunkt erreicht, können Sie als Behelfslösung den Header Host in altostrat.com (Host: altostrat.com) umschreiben. Dies kann entweder in Traffic Director mit URL-Umschreibung oder auf dem Remote-Endpunkt erfolgen, wenn dieser eine Funktion zur Header-Umschreibung hat.

Eine weitere, weniger komplexe Problemumgehung besteht darin, den Header Host auf altostrat.com (Host: altostrat.com) zu setzen und die spezielle Adresse 0.0.0.0 als IP-Adresse der Weiterleitungsregel zu verwenden.

Envoy gibt viele 5xx-Fehler zurück

Wenn Envy zu viele 5xx-Fehler zurückgibt, gehen Sie so vor:

• Prüfen Sie die Envoy-Logs, um zu unterscheiden, ob die Antwort vom Back-End kommt (lokales Back-End), und worin der Grund für den 5xx-Fehler liegt.
• Achten Sie darauf, dass DNS-Abfragen erfolgreich sind und keine SERVFAIL- oder NXDOMAIN-Fehler vorliegen.
• Achten Sie darauf, dass alle Remote-Endpunkte die Systemdiagnosen bestehen.
• Wenn keine Systemdiagnosen konfiguriert sind, prüfen Sie, ob alle Endpunkte über Envoy erreichbar sind. Prüfen Sie die Firewallregeln und -routen sowohl auf der Google Cloud-Seite als auch auf der lokalen Seite.

Mit dem Service Mesh können Sie keine externen Dienste über das öffentliche Internet erreichen.

Sie können Traffic mithilfe von FQDN-Back-Ends in Traffic Director an Dienste im öffentlichen Internet senden. Sie müssen zuerst eine Internetverbindung zwischen Envoy-Clients und dem externen Dienst herstellen. Wenn während Verbindungen zum externen Dienst der Fehler 502 auftritt, gehen Sie so vor:

• Achten Sie darauf, dass Sie die richtigen Routen haben, insbesondere die Standardroute 0.0.0.0/0 und die in den Firewallregeln konfigurierten.
• Achten Sie darauf, dass DNS-Abfragen erfolgreich sind und keine SERVFAIL- oder NXDOMAIN-Fehler vorliegen.
• Wenn der Envoy-Proxy in einer Compute Engine-VM ohne externe IP-Adresse oder in einem privaten GKE-Cluster ausgeführt wird, müssen Sie Cloud NAT konfigurieren oder eine andere Methode verwenden, um eine ausgehende Internetverbindung herzustellen.

Wenn die Fehler bestehen bleiben oder andere 5xx-Fehler auftreten, prüfen Sie die Envoy-Logs, um die Fehlerquelle einzugrenzen.

Serverlose Dienste können nicht über das Service Mesh erreicht werden.

Sie können Traffic an serverlose Dienste (Cloud Run, Cloud Functions und App Engine) senden, indem Sie FQDN-Back-Ends in Traffic Director verwenden. Wenn der Envoy-Proxy in einer Compute Engine-VM ausgeführt wird, die keine externe IP-Adresse hat, oder in einem privaten GKE-Cluster, müssen Sie den privaten Google-Zugriff in dem Subnetz so konfigurieren, dass er auf Google APIs und Google-Dienste zugreifen kann.

Nächste Schritte

• Weitere Informationen zu Client-TLS-Richtlinien finden Sie unter Traffic Director-Dienstsicherheit und unter Network Security API.