Load-Balancing für API Gateway

Durch die Integration der Unterstützung für den globalen externen Application Load Balancer und den Classic Application Load Balancer für API Gateway können Ihre serverlosen Backends alle Features von Cloud Load Balancing nutzen. Wenn Sie API Gateway mit einem globalen externen Application Load Balancer oder einem klassischen Application Load Balancer mithilfe einer serverlosen Netzwerk-Endpunktgruppe (serverlose NEG) kombinieren, können Sie:

  • Gateways mit benutzerdefinierten Markendomains hosten
  • Konfigurieren Sie TLS für Gateways mit Zertifikaten, die von einer bevorzugten Zertifizierungsstelle ausgestellt wurden
  • Gemeinsamen Einstiegspunkt für ein Gateway erstellen, das an mehrere Back-Ends weitergeleitet wird
  • Gateways in mehreren geografischen Regionen für Hochverfügbarkeit bereitstellen, ohne URLs für jede Region verwalten zu müssen
  • Gateways mit Cloud Armor schützen
  • Verbessern Sie die Antwortzeit von Gateways durch die Nutzung von Cloud CDN.

Serverlose NEG für API Gateway verwenden

Eine Netzwerk-Endpunktgruppe (NEG) ist eine Gruppe von Backend-Endpunkten für einen Load-Balancer. Eine serverlose NEG ist ein Back-End, das auf ein von Google gehostetes serverloses Back-End wie Cloud Run, App Engine oder API Gateway verweist. Ein serverloses NEG-Back-End für API Gateway kann Folgendes darstellen:

  • Eine API Gateway-Instanz
  • Eine Gruppe von Gateways, die mit derselben API-Konfiguration konfiguriert sind

Die folgende Abbildung zeigt, wie serverlose NEGs im Cloud Load Balancing-Modell verwendet werden können:

Diagramm der serverlosen NEG als Backend für multiregionale Gateways

Wie in einem früheren Beispiel dargestellt, kann ein Back-End-Dienst von mehreren serverlosen NEGs verwaltet werden. Jede serverlose NEG kann eine einzelne API-Gateway-Instanz enthalten oder eine URL-Maske verwenden, um auf mehrere Gateways zu verweisen. Da alle NEGs, die als Back-End-Dienst fungieren, für das Load-Balancing verwendet werden, sollten sie funktional äquivalente Gateway-Bereitstellungen darstellen. Beispielsweise sollte für alle NEGs dieselbe API-Konfiguration für jedes Gateway in verschiedenen Regionen bereitgestellt sein. Wenn ein Back-End-Dienst mehrere NEGs enthält, verteilt der Load-Balancer den Traffic zwischen diesen NEGs und minimiert gleichzeitig die Anfragelatenz.

Einschränkungen für serverlose NEGs und API Gateway

Wenn Sie serverlose NEGs zur Einbindung von Cloud Load Balancing für API Gateway verwenden, müssen Sie einige Einschränkungen beachten. Vor allem:

  • Serverlose NEGs dürfen keine Netzwerkendpunkte wie IP-Adressen oder Ports haben.
  • Serverlose NEGs können nur auf API-Gateway-Instanzen verweisen, die sich in derselben Region befinden, in der die NEG erstellt wird.
  • Serverlose NEGs können nur auf API-Gateway-Instanzen verweisen, die im selben Projekt wie der Load-Balancer mit dem serverlosen NEG-Back-End erstellt wurden.
  • API Gateway unterstützt keine Einstellungen für die Ingress-Steuerung. Daher ist es nicht möglich, den Zugriff auf Ihr API-Gateway mithilfe einer von einem Dienst generierten Gateway-URL zu deaktivieren und sicherzustellen, dass der gesamte Traffic vom Load-Balancer verarbeitet wird.

Weitere Informationen zu Einschränkungen im Zusammenhang mit serverlosen NEGs und Back-End-Diensten finden Sie unter Einschränkungen.

Einschränkungen für serverlose NEGs in Back-End-Dienstkonfigurationen

Ein Back-End-Dienst definiert, wie Cloud Load Balancing den Traffic verteilt. Die Back-End-Dienstkonfiguration enthält eine Reihe von Werten, z. B. das Protokoll für die Verbindung mit Back-Ends, verschiedene Verteilungs- und Sitzungseinstellungen, Systemdiagnosen und Zeitüberschreitungen. Bei serverlosen NEGs, die als Back-End-Dienst für API Gateway verwendet werden, ermöglichen diese Einstellungen eine differenzierte Kontrolle über das Verhalten Ihres Load-Balancers.

Die Ressourcendefinition eines Back-End-Dienstes hat folgende Auswirkungen auf Ihr Load-Balancing-Design:

  • Serverlose NEGs können nicht mit anderen Arten von NEGs im selben Back-End-Dienst verwendet werden. Beispielsweise können Sie nicht vom selben Back-End-Dienst an einen GKE-Cluster und eine API Gateway-Instanz weiterleiten.
  • Alle serverlosen NEGs, die in einem Back-End-Dienst kombiniert sind, müssen denselben Back-End-Typ verwenden. Das bedeutet, dass serverlose API Gateway-NEGs nur mit anderen serverlosen API Gateway-NEGs und serverlose App Engine-NEGs nur mit serverlosen App Engine-NEGs kombiniert werden können.
  • Ein Backend-Dienst darf pro Region nur eine serverlose NEG enthalten.

Beim Definieren einer Back-End-Dienstkonfiguration, die an eine serverlose NEG weiterleitet, gelten die folgenden Feldbeschränkungen:

  • balancingMode kann nicht angegeben werden
  • Das Feld „healthCheck“ muss leer sein und kann nicht angegeben werden
  • Ports können nicht angegeben werden
  • Es werden nur HTTP- und HTTPS-Protokolle unterstützt.
  • Werte, die in utilization- oder connection-bezogenen Feldern angegeben werden, werden nicht unterstützt.

Die Felder IAP, cdnPolicy und securityPolicy in der Konfiguration des Back-End-Dienstes sind für serverlose NEGs gültig. Diese Felder können verwendet werden, um Identity-Aware Proxy, Cloud CDN und Cloud Armor jeweils mit Ihrem API Gateway-Dienst einzurichten.

Nächste Schritte