Traffic Director mit Internetnetzwerk-Endpunktgruppen

Sie können Traffic Director so konfigurieren, dass Internetnetzwerk-Endpunktgruppen (NEGs) vom Typ INTERNET_FQDN_PORT verwendet werden. Der externe Dienst wird durch seinen voll qualifizierten Domainnamen (Fully Qualified Domain Name, FQDN) und die Portnummer in der NEG dargestellt. Die NEG kann nur ein FQDN:Port-Paar enthalten und der Back-End-Dienst kann nur eine NEG dieses Typs enthalten. Der FQDN wird mithilfe der Reihenfolge der Namensauflösung des zugrunde liegenden Virtual Private Cloud-Netzwerks (VPC) aufgelöst.

Traffic Director-Service Mesh mit FQDN-Back-Ends erweitern

Das Traffic Director-Service Mesh kann Traffic an private Dienste weiterleiten, die über Hybridkonnektivität erreichbar sind, einschließlich benannter lokaler, Multi-Cloud- und Internetdienste. Auf den Remotedienst wird von seinem FQDN verwiesen.

Grafik: Traffic Director-Service Mesh auf lokale oder Multi-Cloud-Standorte mit FQDN-Back-Ends über Hybridkonnektivität erweitern.
Erweiterung des Traffic Director-Service Mesh auf lokale oder Multi-Cloud-Standorte mithilfe von FQDN-Back-Ends über Hybridkonnektivität (zum Vergrößern klicken)

Außerdem können Sie Traffic an Dienste weiterleiten, die über das öffentliche Internet erreichbar sind.

Grafik: Traffic Director-Service Mesh mithilfe von FQDN-Back-Ends auf einen Internetdienst erweitern.
Traffic Director-Service Mesh mithilfe von FQDN-Back-Ends auf einen Internetdienst erweitern (zum Vergrößern klicken)

Ressourcen und Architektur von Google Cloud

In diesem Abschnitt werden die Ressourcen und die Architektur zum Konfigurieren von Traffic Director mit einer Internet-NEG beschrieben.

INTERNET_FQDN_PORT-Netzwerk-Endpunktgruppe

Verwenden Sie die globale Internet-NEG vom Typ INTERNET_FQDN_PORT, um Traffic an den externen Dienst weiterzuleiten, auf den sein FQDN verweist. Die NEG enthält den FQDN Ihres Dienstes und seine Portnummer. Traffic Director programmiert den FQDN mithilfe der xDS-Konfiguration in Envoy-Proxys.

Traffic Director selbst garantiert nicht die Namensauflösung und Erreichbarkeit der Remote-Endpunkte. Der FQDN muss über die Reihenfolge der Namensauflösung des VPC-Netzwerks aufgelöst werden können, mit dem die Envoy-Proxys verbunden sind, und die aufgelösten Endpunkte müssen über die Envoy-Proxys erreichbar sein.

Systemdiagnosen

Das Verhalten der Systemdiagnose für Netzwerkendpunkte vom Typ INTERNET_FQDN_PORT unterscheidet sich vom Verhalten der Systemdiagnose für andere Arten von Netzwerkendpunkten, die mit Cloud Load Balancing und Traffic Director verwendet werden. Während die meisten anderen Typen von Netzwerkendpunkten das zentrale Systemdiagnosesystem von Google Cloud verwenden, verwenden die NEGs, die für Endpunkte in Multi-Cloud-Umgebungen (INTERNET_FQDN_PORT und NON_GCP_PRIVATE_IP_PORT) verwendet werden, den verteilten Systemdiagnosemechanismus von Envoy.

Envoy unterstützt die folgenden Protokolle für Systemdiagnosen:

  • HTTP
  • HTTPS
  • HTTP/2
  • TCP

Sie konfigurieren Systemdiagnosen mithilfe der Compute Engine APIs.

DNS-Überlegungen

Es gibt zwei wichtige Überlegungen zu DNS:

  • Der DNS-Server, der die Ressourceneinträge Ihres externen Dienstes hostet.
  • Der Modus, in dem der Envoy-Proxy für die Verwendung von DNS für die Verbindungsverwaltung konfiguriert ist.

Cloud DNS-Server

Sie können eine verwaltete private DNS-Zone erstellen, um die DNS-Einträge in Ihrem Google Cloud-Projekt zu hosten. Sie können auch andere Features von Cloud DNS wie Weiterleitungszonen verwenden, um Einträge von einem lokalen DNS-Server abzurufen.

Envoy-DNS-Modus

Der Envoy-DNS-Modus, auch Diensterkennung genannt, gibt an, wie der Envoy-Proxy DNS-Einträge zur Verwaltung ausgehender Verbindungen verwendet. Traffic Director konfiguriert Envoy für die Verwendung des strikten DNS-Modus. Mit dem strikten DNS-Modus kann das Load-Balancing für alle aufgelösten Endpunkte durchgeführt werden. Sie berücksichtigt den Status der Systemdiagnose und beendet Verbindungen zu Endpunkten, die fehlerhaft sind oder nicht mehr mit DNS aufgelöst werden. Sie können diesen Modus nicht ändern.

Weitere Informationen zur Diensterkennung finden Sie in der Envoy-Dokumentation.

Konnektivität und Routing

Wenn Sie Traffic an einen privaten Dienst weiterleiten, gelten für die zugrunde liegende Netzwerkverbindung die folgenden Anforderungen:

  • Die Hybridkonnektivität zwischen dem VPC-Netzwerk und dem lokalen Rechenzentrum oder der öffentlichen Cloud eines Drittanbieters erfolgt über Cloud VPN oder Cloud Interconnect.
  • VPC-Firewallregeln und -Routen werden richtig konfiguriert, um die bidirektionale Erreichbarkeit von Envoy zu Ihren privaten Dienstendpunkten und gegebenenfalls zum lokalen DNS-Server zu konfigurieren.
  • Für ein erfolgreiches regionales Hochverfügbarkeits-Failover muss globales dynamisches Routing aktiviert sein. Weitere Informationen finden Sie unter Modus für dynamisches Routing.

Wenn Sie Traffic an einen externen Dienst weiterleiten, der im Internet erreichbar ist, gelten die folgenden Anforderungen:

  • Die Client-VM-Instanzen im VPC-Netzwerk müssen eine externe IP-Adresse oder Cloud NAT haben.
  • Die Standardroute muss vorhanden sein, um ausgehenden Traffic an das Internet zu senden.

In beiden vorherigen Fällen verwendet der Traffic das Routing des VPC-Netzwerks.

Sicherheit

FQDN-Back-Ends sind mit den Sicherheitsfeatures und APIs von Traffic Director kompatibel. Bei den ausgehenden Verbindungen zu Ihrem externen Dienst können Sie FQDN im SNI-Header mithilfe von Client-TLS-Richtlinien konfigurieren.

Einschränkungen und Überlegungen

  • Internet-NEGs vom Typ INTERNET_IP_PORT werden von Traffic Director nicht unterstützt.
  • Envoy-Version 1.15.0 oder höher ist für FQDN-Back-Ends erforderlich.
  • Verwenden Sie Google Cloud CLI oder REST APIs, um Traffic Director zu konfigurieren. End-to-End-Konfigurationen mit der Google Cloud Console werden nicht unterstützt.
  • FQDN-Back-Ends werden nur mit Envoy unterstützt. Proxylose gRPC-Dienste werden nicht unterstützt.

  • Wenn Sie den NEG-Typ INTERNET_FQDN_PORT mit Traffic Director verwenden, werden Systemdiagnosen der Remote-Endpunkte mithilfe des verteilten Systemdiagnosemechanismus von Envoy durchgeführt. Immer wenn ein neuer Remote-Endpunkt hinzugefügt wird, starten alle Envoy-Proxys die Systemdiagnose unabhängig voneinander.

    Ähnlich verhält es sich, wenn ein neuer Envoy-Proxy dem Mesh hinzugefügt wird. Er beginnt damit, alle Remote-Endpunkte zu prüfen. Abhängig von der Anzahl der Envoy-Proxys und Remote-Endpunkte in Ihrer Bereitstellung kann das resultierende Systemdiagnose-Mesh jedoch zu einem erheblichen Anstieg des Traffics führen und die Remote-Endpunkte unnötig belasten. Sie haben die Möglichkeit, keine Systemdiagnosen zu konfigurieren.

  • Der Status der Systemdiagnose ist in der Google Cloud Console für FQDN-Back-Ends nicht sichtbar.

  • Systemdiagnosen, die die Protokolle UDP, SSL und gRPC verwenden, werden nicht unterstützt.

  • Die folgenden Systemdiagnoseoptionen werden nicht unterstützt:

    • HTTP-/HTTP2-/HTTPS-Systemdiagnose
      • --proxy-header
      • --response
    • TCP-Systemdiagnose
      • --proxy-header
      • --request
      • --response

Nächste Schritte