Cloud Service Mesh mit Internetnetzwerk-Endpunktgruppen

Sie können Cloud Service Mesh für die Verwendung konfigurieren Internet-Netzwerk-Endpunktgruppen (NEGs) des Typs INTERNET_FQDN_PORT. 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.

Cloud Service Mesh-Service-Mesh mit FQDN-Back-Ends erweitern

Das Service Mesh von Cloud Service Mesh kann Traffic an private Dienste weiterleiten, die sind über Hybridkonnektivität erreichbar, Multi-Cloud- und Internetdiensten. Auf den Remotedienst wird von seinem FQDN verwiesen.

Grafik: Cloud Service Mesh-Service Mesh auf lokale oder Multi-Cloud-Standorte mit FQDN-Back-Ends über Hybridkonnektivität erweitern.
Erweiterung des Cloud Service Mesh-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.

Cloud Service Mesh-Service-Mesh mithilfe von FQDN-Back-Ends auf einen Internetdienst erweitern
Cloud Service Mesh-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 Cloud Service Mesh 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. Cloud Service Mesh programmiert den FQDN mithilfe der xDS-Konfiguration in Envoy-Proxys.

Cloud Service Mesh 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

Verhalten der Systemdiagnose für Netzwerkendpunkte vom Typ INTERNET_FQDN_PORT unterscheidet sich vom Verhalten der Systemdiagnose für andere Arten von Netzwerkendpunkten, mit Cloud Load Balancing und Cloud Service Mesh. 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. Cloud Service Mesh 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-Backends sind kompatibel mit Sicherheitsfunktionen von Cloud Service Mesh und APIs. 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 nicht unterstützt mit Cloud Service Mesh.
  • Envoy-Version 1.15.0 oder höher ist für FQDN-Back-Ends erforderlich.
  • Verwenden Sie die Google Cloud CLI oder REST APIs, um Cloud Service Mesh 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 Cloud Service Mesh verwenden, Die Remote-Endpunkte werden mit dem verteilten Systemzustand von Envoy überprüft Prüfmechanismus. 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