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
  • TLS für Gateways mit Zertifikaten konfigurieren, 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 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-Backend 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 gezeigt, 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 werden. 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

Bei der Verwendung serverloser NEGs zur Integration von Cloud Load Balancing für API Gateway sind einige Einschränkungen zu 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 erstellt wurden, der das serverlose NEG-Backend verwendet.
  • API Gateway unterstützt keine Ingress-Kontrolleinstellungen. 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 für serverlose NEGs und Back-End-Dienste finden Sie unter Einschränkungen.

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

Ein Backend-Dienst definiert, wie Cloud Load Balancing Traffic verteilt. Die Konfiguration des Back-End-Dienstes enthält eine Reihe von Werten, z. B. das Protokoll, das für die Verbindung zu Backends verwendet wird, verschiedene Verteilungs- und Sitzungseinstellungen, Systemdiagnosen und Zeitüberschreitungen. Bei serverlosen NEGs, die als Backenddienst für API Gateway verwendet werden, können Sie mit diesen Einstellungen das Verhalten Ihres Load Balancers genau steuern.

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 kombiniert werden können. Serverlose App Engine-NEGs können nur mit serverlosen App Engine-NEGs kombiniert werden.
  • Ein Backend-Dienst darf pro Region nur eine serverlose NEG enthalten.

Wenn Sie eine Backend-Dienstkonfiguration definieren, die zu einer serverlosen NEG weiterleitet, gelten die folgenden Feldeinschränkungen:

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

Die Felder IAP, cdnPolicy und securityPolicy in der Konfiguration des Back-End-Dienstes sind für serverlose NEGs gültig. Mit diesen Feldern können Sie Identity-Aware Proxy, Cloud CDN und Cloud Armor jeweils mit Ihrem API Gateway-Dienst einrichten.

Nächste Schritte