Internetnetzwerk-Endpunktgruppen

Cloud Load Balancing unterstützt die Proxy-Weiterleitung von Traffic zu externen Back-Ends außerhalb von Trusted Cloud by S3NS. Zum Definieren eines externen Back-Ends für einen Load Balancer verwenden Sie eine Ressource, die als Internet-NEG (Netzwerk-Endpunktgruppe) bezeichnet wird.

Sie können diese Art der Bereitstellung verwenden, wenn Sie Inhalte von einem externen Backend bereitstellen, aber der Trusted Cloud Load-Balancer das Frontend sein soll. Damit haben Sie folgende Möglichkeiten:

  • Verwenden Sie die Google Edge-Infrastruktur, um Ihre Nutzerverbindungen zu beenden.
  • Leiten Sie die Verbindungen zu Ihrem externen Back-End weiter.
  • Stellen Sie Traffic zu Ihrem öffentlichen Endpunkt über den privaten Backbone von Google bereit. So steigern Sie die Zuverlässigkeit und verringern die Latenz zwischen Client und Server.

In den folgenden Abschnitten wird erläutert, wie externe Backends mit Cloud Load Balancing verwendet werden. Wenn Sie ein externes Backend mit Cloud Service Mesh verwenden möchten, lesen Sie den Abschnitt Cloud Service Mesh mit Internetnetzwerk-Endpunktgruppen.

Terminologie

Die folgenden Begriffe werden manchmal synonym verwendet, da sie dieselbe oder eine ähnliche Bedeutung haben:

  • Externes Backend:Ein Backend, das sich außerhalb von Trusted Cloud by S3NS befindet und über das Internet erreichbar ist. Der Endpunkt in einer Internet-NEG.
  • Internetnetzwerk-Endpunktgruppe (NEG): Die Trusted Cloud by S3NS API-Ressource, mit der Sie ein externes Back-End angeben.
  • Externer Endpunkt: Entspricht einem externen Back-End.

In diesem Dokument wird der Begriff externes Backend verwendet, außer bei Bezug auf die Internet-NEG-API-Ressource.

Komponenten des Lastenausgleichsmoduls

In diesem Abschnitt werden die Load-Balancing-Architektur und die Ressourcen beschrieben, die zum Konfigurieren eines Load-Balancers mit einem externen Backend erforderlich sind. Der Load-Balancer erfordert spezifische Konfiguration nur für den Backend-Dienst. Die Frontend-Konfiguration ist die gleiche wie für jeden anderen Load Balancer.

Die folgenden Abbildungen zeigen die Trusted Cloud Ressourcen, die zum Einrichten eines Load Balancers mit einem externen Backend erforderlich sind.

Regional, extern

Diese Abbildung zeigt die Trusted Cloud Ressourcen, die zum Einrichten eines regionalen externen Application Load Balancers mit einem externen Backend erforderlich sind.

Globaler externer Application Load Balancer mit externem Backend.
Regional external Application Load Balancer with an external backend (click to enlarge).

Diese Abbildung zeigt die Trusted Cloud Ressourcen, die zum Einrichten eines regionalen externen Proxy-Network Load Balancers mit einem externen Backend erforderlich sind.

Regionaler externer Proxy-Network Load Balancer mit einem externen Backend.
Regional external proxy Network Load Balancer with an external backend (click to enlarge).

Regional intern

Diese Abbildung zeigt die Trusted Cloud Ressourcen, die zum Einrichten eines regionalen internen Application Load Balancers mit einem externen Backend erforderlich sind.

Regionaler interner Application Load Balancer mit einem externen Backend.
Regional internal Application Load Balancer with an external backend (click to enlarge).

Diese Abbildung zeigt die Trusted Cloud Ressourcen, die zum Einrichten eines regionalen internen Proxy-Network Load Balancers mit einem externen Backend erforderlich sind.

Regionaler interner Proxy-Network Load Balancer mit einem externen Backend.
Regional internal proxy Network Load Balancer with an external backend (click to enlarge).

Sie können Internet-NEGs nur auf der Premium-Netzwerkdienststufe verwenden.

Frontend-Konfiguration

Zum Erstellen eines Load-Balancers mit einem Internet-NEG-Backend ist keine spezielle Frontend-Konfiguration erforderlich. Weiterleitungsregeln werden verwendet, um Traffic nach IP-Adresse, Port und Protokoll an einen Zielproxy weiterzuleiten. Der Zielproxy beendet dann Verbindungen von Clients. Darüber hinaus benötigen Envoy-basierte Load Balancer ein Nur-Proxy-Subnetz.

Application Load Balancer verwenden auch URL-Zuordnungen, um ein URL-basiertes Routing von Anfragen an die entsprechenden Backend-Dienste einzurichten.

Weitere Informationen zu den einzelnen Komponenten finden Sie in den Architekturabschnitten des jeweiligen Load Balancers:

Internet-NEG

Eine Internet-NEG ist eine globale Ressource, mit der ein externes Backend für den Load Balancer definiert wird. Es gibt zwei Arten von Internet-NEGs: globale Internet-NEGs und regionale Internet-NEGs. Sie unterscheiden sich in Bezug auf den Bereich (global oder regional) und das Verhalten. Das externe Backend, auf das von einer globalen Internet-NEG verwiesen wird, muss ausschließlich über das Internet erreichbar sein. Es darf nicht über Cloud VPN oder Cloud Interconnect erreichbar sein. Wenn das externe Backend auf eine Google-API oder einen Google-Dienst verweist, muss der Dienst über den TCP-Port 80 oder 443 über das HTTP-, HTTPS- oder HTTP/2-Protokoll erreichbar sein.

Es gibt zwei Möglichkeiten, den externen Endpunkt zu konfigurieren, auf den die NEG verweist: INTERNET_FQDN_PORT oder INTERNET_IP_PORT. Wenn das Format INTERNET_IP_PORT ausgewählt wird, kann nur eine öffentliche, über das Internet routingfähige IP-Adresse verwendet werden. Wenn das Format INTERNET_FQDN_PORT ausgewählt wird, kann der FQDN je nach Umfang des Endpunkts (regional oder global) entweder in eine öffentliche, über das Internet routingfähige IP-Adresse oder in eine private IP-Adresse aufgelöst werden.

Regionale Internet-NEGs werden von verwalteten Envoy-Proxys unterstützt. Jede NEG kann mehrere Endpunkte haben und ein Back-End-Dienst kann mehrere Internet-NEGs enthalten.

Für ausgehenden Traffic können Sie Cloud NAT-Gateways so konfigurieren, dass die Quell-IP-Adressen festgelegt werden. Alternativ können Sie den Traffic auch über erkannte Routen in Ihrem VPC-Netzwerk weiterleiten. Cloud NAT ist für diese Routingmethode nicht erforderlich, wird aber unterstützt.

In der folgenden Tabelle wird beschrieben, wie verschiedene Load Balancer regionale Internet-NEGs unterstützen.

Load-Balancer Endpunkttyp Endpunktdefinition Umfang Systemdiagnosen
  • Regionaler externer Application Load Balancer
  • Regionaler interner Application Load Balancer
  • Regionaler externer Proxy-Network Load Balancer
  • Regionaler interner Proxy-Network Load Balancer

INTERNET_FQDN_PORT

Entweder ein öffentlich oder privat auflösbarer, voll qualifizierter Domainname und ein optionaler Port. Zum Beispiel backend.example.com:443*.

Der Domainname muss von Cloud DNS aufgelöst werden können.

Pro NEG sind maximal 256 Endpunkte zulässig.

 Regional Verteilte Envoy-Systemdiagnosen

INTERNET_IP_PORT

Nur eine öffentlich weiterleitbare IP-Adresse und ein optionaler Port. Beispiel: 8.8.8.8:4432.

Die IP-Adresse darf keine RFC 1918-Adresse sein.

Pro NEG sind maximal 256 Endpunkte zulässig.

* Bei regionalen Internet-NEGs müssen Sie einen Port angeben. Sie können beim Erstellen der NEG einen Standardport angeben oder jedes Mal einen Port angeben, wenn Sie einen Endpunkt zu der NEG hinzufügen, oder Sie können beides tun. Wenn Sie beim Hinzufügen eines Endpunkts keinen Port angeben, wird der Standardport der NEG verwendet.

DNS-Auflösung für regionale INTERNET_FQDN_PORT-Endpunkte

Wenn Ihre Domain über das Internet aufgelöst werden kann, ist keine weitere Konfiguration erforderlich, um DNS einzurichten. Wenn Sie jedoch private FQDNs auflösen, müssen Sie Cloud DNS für die DNS-Auflösung konfigurieren. Der Name muss in Cloud DNS gehostet werden oder mithilfe der DNS-Weiterleitung von Cloud DNS zu einem lokalen DNS aufgelöst werden können. Wenn Sie auf eine private DNS-Zone in einem anderen VPC-Netzwerk verweisen, ist DNS-Peering erforderlich.

Erstellen Sie zuerst eine Cloud DNS-Zone, um die DNS-Einträge in Ihrem Projekt zu hosten. Fügen Sie dann die DNS-Einträge hinzu. Spezifische Konfigurationsschritte finden Sie in der Cloud DNS-Dokumentation. Die Reihenfolge der Cloud DNS-Auflösung wird unter Reihenfolge der Namensauflösung beschrieben.

Wenn Sie eine freigegebene VPC verwenden, beachten Sie die spezifischen Netzwerkanforderungen. Sie können auch andere Features von Cloud DNS wie Weiterleitungszonen verwenden, um Einträge von einem lokalen DNS-Server abzurufen.

Auflösung der IP-Adresse für regionale INTERNET_FQDN_PORT-Endpunkte

Regionale Internet-NEGs unterstützen die Domainnamensauflösung mit Cloud DNS.

Wenn der DNS-Server mehrere IP-Adressen zurückgibt, verteilt Envoy den Traffic zwischen den zurückgegebenen IP-Adressen anhand des konfigurierten Load Balancing-Algorithmus (Round Robin, letzte Anfrage usw.). Die Liste der Endpunkte wird regelmäßig basierend auf der DNS-TTL aktualisiert. Sie können Wiederholungsrichtlinien konfigurieren, um Envoy zu zwingen, eine Verbindung zu einer anderen IP-Adresse herzustellen, wenn eine Verbindung fehlschlägt.

Backend-Dienst

Backend-Dienste stellen Konfigurationsinformationen für den Load-Balancer bereit. Load-Balancer leiten den eingehenden Traffic anhand der Informationen in einem Backend-Dienst an einen oder mehrere verknüpfte Backends weiter.

Um einen Load-Balancer mit einem externen Backend einzurichten, konfigurieren Sie den Backend-Dienst mit einem Internet-NEG-Backend. Wenn Sie einem Backend-Dienst eine Internet-NEG hinzufügen, gelten je nach Umfang der NEG die folgenden Überlegungen:

  • Der Backend-Dienst kann nicht auch andere Backend-Typen wie zonale NEGs oder Instanzgruppen als Backends verwenden.

  • Anzahl der NEGs pro Backend-Dienst

    • Regionale NEGs. Sie können bis zu 50 Internet-NEGs zu demselben Backend-Dienst hinzufügen.

  • Anzahl der Endpunkte pro NEG

    Regionale NEGs unterstützen keine Load-Balancing-Modi wie Rate, Verbindung oder Auslastung. Alle Endpunkte aller NEGs, die an einen Back-End-Dienst angehängt sind, werden in einer einzigen Gruppe zusammengefasst. Der Load Balancing-Traffic zwischen diesem Pool der Endpunkte wird mithilfe von Envoy-Load Balancing-Algorithmen verarbeitet. Informationen zu den unterstützten Load Balancing-Richtlinienalgorithmen finden Sie unter localityLbPolicy in der API-Dokumentation für regionale Backend-Dienste.

  • Systemdiagnosen

  • Das Load Balancing-Schema des Backend-Dienstes muss mit dem Schema übereinstimmen, das vom Load Balancer benötigt wird, den Sie bereitstellen. Eine vollständige Liste finden Sie unter Backend-Dienste.

  • Das Protokoll des Backend-Dienstes muss entweder HTTP, HTTPS oder HTTP2 sein.

    Wir empfehlen dringend, entweder HTTPS oder HTTP/2 als Protokoll zu verwenden, wenn Sie einen Backend-Dienst mit einer Internet-NEG konfigurieren. Damit wird die Kommunikation zwischen dem Load-Balancer und dem Backend verschlüsselt und authentifiziert, wenn das öffentliche Internet durchlaufen wird.

    Wenn Sie HTTPS oder HTTP/2 als Backend-Protokoll verwenden, müssen Sie außerdem einen INTERNET_FQDN_PORT-Endpunkt zum Erstellen Ihres externen Backends verwenden. Dies hat zwei Vorteile:

    • Dadurch wird sichergestellt, dass der Load-Balancer das SSL-Serverzertifikat validiert, das vom externen Backend bereitgestellt wird, und dass die folgenden Informationen wahr sind:

      • Ob das Zertifikat von bekannten Zertifizierungsstellen signiert wurde.
      • Ob das Zertifikat noch nicht abgelaufen ist
      • Ob die Zertifikatsignatur gültig ist
      • Ob der konfigurierte FQDN mit einem der alternativen Antragstellernamen (Subject Alternative Names, SANs) im Zertifikat übereinstimmt

      Wenn Sie das externe Backend mithilfe eines INTERNET_IP_PORT-Endpunkts erstellen, wird keine SSL-Serverzertifikat-Validierung durchgeführt.

    • Die SNI-Erweiterung (Server Name Indication) für SSL wird nur mit INTERNET_FQDN_PORT-Endpunkten unterstützt. Der konfigurierte FQDN sendet während des SSL-Handshakes zwischen dem Load-Balancer und dem externen Endpunkt ein SNI im Client-Hello. Das SNI wird nicht gesendet, wenn Sie einen INTERNET_IP_PORT-Endpunkt verwenden, da IP-Adressliterale im Feld HostName einer SNI-Nutzlast nicht zulässig sind.

Systemdiagnosen

Die Konfiguration der Systemdiagnose variiert je nach Art des Load Balancers:

  • Regionaler externer Application Load Balancer, regionaler interner Application Load Balancer, regionaler externer Proxy-Network Load Balancer und regionaler interner Proxy-Network Load Balancer. Health Checks sind optional. Systemdiagnoseprüfungen für diese Load Balancer stammen aus dem Nur-Proxy-Subnetz und werden dann (mithilfe von Cloud NAT) entweder in vorreservierte IP-Adressen oder automatisch zugewiesene NAT-IP-Adressen übersetzt. Weitere Informationen finden Sie unter Regionale NEGs: Cloud NAT-Gateway verwenden.

    Verteilte Envoy-Systemdiagnosen werden mit der gleichenTrusted Cloud Console, gcloud CLI und API-Prozessen erstellt wie zentralisierte Systemdiagnosen. Es ist keine weitere Konfiguration erforderlich.

    Wichtige Hinweise:

    • gRPC-Systemdiagnosen werden nicht unterstützt.
    • Systemdiagnosen mit aktiviertem PROXY-Protokoll v1 werden nicht unterstützt.

    • Da die Envoy-Datenebene Systemdiagnosen verarbeitet, können Sie den Systemstatus der externen Endpunkte nicht mit derTrusted Cloud -Konsole, der API oder der gcloud CLI prüfen. Bei Hybrid-NEGs mit Envoy-basierten Load Balancern zeigt die Trusted Cloud Console den Status der Systemdiagnose als N/A an. Dies ist zu erwarten.

    • Jeder Envoy-Proxy, der dem Nur-Proxy-Subnetz in der Region im VPC-Netzwerk zugewiesen ist, initiiert Systemdiagnosen unabhängig voneinander. Daher kann es vorkommen, dass der Netzwerktraffic aufgrund von Systemdiagnosen zunimmt. Die Zunahme hängt von der Anzahl der Envoy-Proxys, die Ihrem VPC-Netzwerk in einer Region zugewiesen sind, der Menge des von diesen Proxys empfangenen Traffics und der Anzahl der Endpunkte ab, die jeder Envoy-Proxy für die Systemdiagnose benötigt. Im schlimmsten Fall steigt der Netzwerktraffic aufgrund von Systemdiagnosen quadratisch ((O(n^2))) an.

    • Systemdiagnose-Logs für verteilte Envoy-Systemdiagnosen enthalten keine detaillierten Systemzustände. Informationen dazu, was in Logs erfasst wird, finden Sie unter Systemdiagnose-Logging. Weitere Informationen zur Fehlerbehebung bei der Konnektivität von Envoy-Proxys zu Ihren NEG-Endpunkten finden Sie in den entsprechenden Load Balancer-Logs.

Externes Backend für den Empfang von Anfragen aktivieren

Konfigurieren Sie Ihr externes Backend so, dass Traffic von Trusted Cloudzugelassen wird.

Regionale NEGs: Cloud NAT-Gateway verwenden

Wenn Sie eine regionale Internet-NEG verwenden, müssen Sie zuerst ein Cloud NAT-Gateway einrichten, um eine Reihe von IP-Adressbereichen zuzuweisen, von denen der Trusted Cloud -Traffic stammen sollte.

Der Gateway-Endpunkt sollte vom Typ ENDPOINT_TYPE_MANAGED_PROXY_LB sein.

Das Cloud NAT-Gateway kann so konfiguriert werden, dass entweder externe IP-Adressen nach Bedarf automatisch zugewiesen werden oder ein manuell vorab reservierter Satz externer IP-Adressen verwendet wird.

  • Automatisch zugeordnete IP-Adressen

    Verwenden Sie automatisch zugeordnete IP-Adressen, wenn Sie in Ihrer externen Backend-Umgebung keine bestimmten Trusted CloudIP-Adressen, die Traffic an das externe Backend senden können, auf eine Zulassungsliste setzen müssen.

  • Manuell zugeordnete IP-Adressen

    Verwenden Sie manuell zugeordnete IP-Adressen nur, wenn Ihre externe Backend-Umgebung erfordert, dass Sie bestimmte Trusted Cloud IP-Adressen auf eine Zulassungsliste setzen. Da jeder Envoy, der Ihrem Proxy-Subnetz zugewiesen ist, eine vollständige IP-Adresse nutzt, muss der Pool reservierter IP-Adressen groß genug sein, um alle Envoys verarbeiten zu können.

    Wenn bei Ihnen in großem Umfang Verbindungsprobleme auftreten, prüfen Sie, ob Sie die Cloud NAT-Limits erreicht haben. Standardmäßig sind pro Gateway auf 50 manuell zugewiesene NAT-IP-Adressen beschränkt.

Die dynamische Portzuweisung wird für regionale Internet-NEGs unterstützt. IP-Adressen können von Proxys gemeinsam genutzt werden und werden so optimal genutzt.

Diese Cloud NAT-Konfiguration gilt für das gesamte Nur-Proxy-Subnetz. Der Internet-Traffic, der allen regionalen Envoy-basierten Load Balancern in der Region zugeordnet ist, hat dasselbe NAT-Gateway.

Für die Cloud NAT-Nutzung fallen Gebühren für Nutzer-Traffic und Systemdiagnose-Traffic an. Weitere Informationen zur Preisgestaltung für regionale Internet-NEGs finden Sie unter Preisgestaltung für regionale Internet-NEGs.

Für NAT-Gateways in Nur-Proxy-Subnetzen gelten bestimmte Einschränkungen:

  • Es wird nur eine 1:1-NAT-Übersetzung durchgeführt. Die Freigabe von IP-Adressen wird nicht unterstützt.
  • Logging und Monitoring werden nicht unterstützt. Die Flags --enable-logging und --log-filter werden nicht unterstützt.

Anfragen an das externe Backend authentifizieren

Dieser Abschnitt gilt nur für Application Load Balancer.

So authentifizieren Sie Anfragen, die an Ihr externes Backend gesendet werden:

  • Bestimmen Sie einen benutzerdefinierten Header, der angibt, dass die Anfrage von einem Trusted Cloud Load-Balancer mit einem benutzerdefinierten Anfrageheader stammt. Beispielsweise können Sie 16 oder mehr kryptografisch zufällige Byte als gemeinsam genutzten Schlüssel verwenden.

    Implementieren von benutzerdefinierten Header-Transformationen je nach Art des verwendeten Load Balancers:

    • Regionaler externer Application Load Balancer und regionaler interner Application Load Balancer. Benutzerdefinierte Header-Transformationen können nur für die URL-Zuordnung konfiguriert werden.

      Für diese Envoy-basierten Load Balancer sind Host und authority spezielle Keywords, die von Trusted Cloudreserviert werden. Sie können diese Header nicht für diese Load Balancer ändern. Stattdessen empfehlen wir, andere benutzerdefinierte Header (z. B. MyHost) zu erstellen, damit Sie die reservierten Headernamen nicht beeinträchtigen.

  • Aktivieren Sie IAP und prüfen Sie, ob das signierte JWT im Anfrageheader von Google signiert ist und die aud (Zielgruppen-) Anforderung die Nummer des Projekts enthält, in dem der Load Balancer definiert ist.

Logs

An ein externes Backend weitergeleitete Anfragen werden in Cloud Logging auf dieselbe Weise in Logs erfasst wie Anfragen an andere Backends.

Hier finden Sie weitere Informationen:

Beschränkungen

  • Im Abschnitt Backend-Dienst finden Sie Einschränkungen für die Konfiguration von Internet-NEGs als Backends.
  • Wenn Sie einen Load Balancer ändern, um das Backend von einer Internet-NEG in einen anderen Backend-Typ oder das Backend von einem anderen Backend-Typ in eine Internet-NEG zu ändern, kommt es zu einer vorübergehenden Ausfallzeit Ihrer Anwendung von etwa 30 bis 90 Sekunden.
  • Im Abschnitt Cloud NAT-Gateway finden Sie Einschränkungen für NAT-Gateways, die in Nur-Proxy-Subnetzen konfiguriert sind.

Kontingente und Limits

Informationen zu Kontingenten und Limits finden Sie in der Kontingenttabelle für NEG-Back-Ends und der Kontingenttabelle für Endpunkte pro NEG.

Preise

Ausgehender Traffic an externe Internet-NEG-Endpunkte wird zu den Preisen für ausgehenden Internettraffic der Premium-Stufe berechnet. Die Quelle basiert auf dem Standort des Clients und das Ziel richtet sich nach dem Standort Ihres öffentlichen Endpunkts.

Wenn Sie ein Cloud NAT-Gateway konfiguriert haben, um das Nur-Proxy-Subnetz Ihres regionalen Envoy-basierten Load Balancers zuzuordnen, fallen Cloud NAT-Gebühren an. Für Cloud NAT-Gateways, die Load Balancern zugewiesen sind, fallen stündliche Gebühren an, die einem Netzwerk mit mehr als 32 VM-Instanzen entsprechen. Weitere Informationen finden Sie unter Cloud NAT-Preise.

Weitere Informationen finden Sie unter Cloud Load Balancing – Preise.

Nächste Schritte