Load-Balancing für API Gateway

Durch die Einbindung des globalen externen Application Load Balancers und der klassischen Application Load Balancer für API Gateway können Ihre serverlosen Back-Ends alle Features von Cloud Load Balancing nutzen. Wenn Sie das API Gateway über eine serverlose Netzwerk-Endpunktgruppe (serverlose NEG) mit einem globalen externen oder klassischen Application Load Balancer kombinieren, haben Sie folgende Möglichkeiten:

  • 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 weiterleitet
  • Gateways für Hochverfügbarkeit in mehreren Regionen bereitstellen, ohne URLs für jede Region verwalten zu müssen
  • Gateways mit Cloud Armor schützen
  • Verbessern Sie die Antwortzeit des Gateways mithilfe 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 vorherigen 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 als Back-End-Dienst fungierenden NEGs für das Load-Balancing verwendet werden, sollten sie funktional gleichwertige 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, sollten Sie einige Einschränkungen berücksichtigen. Vor allem:

  • An serverlosen NEGs können keine Netzwerkendpunkte wie IP-Adressen oder Ports angehängt sein.
  • Serverlose NEGs können nur auf API-Gateway-Instanzen verweisen, die sich in derselben Region befinden, in der die NEG erstellt wurde.
  • 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 Einstellungen der Steuerung für eingehenden Traffic. Daher gibt es keine Möglichkeit, den Zugriff auf Ihr API-Gateway mithilfe einer vom Dienst generierten Gateway-URL zu deaktivieren und sicherzustellen, dass der gesamte Traffic vom Load-Balancer verarbeitet wird.

Weitere Informationen zu Einschränkungen in Bezug auf serverlose NEGs und Back-End-Dienste im Allgemeinen 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, das für die Verbindung zu Back-Ends verwendet wird, verschiedene Verteilungs- und Sitzungseinstellungen, Systemdiagnosen und Zeitüberschreitungen. Bei serverlosen NEGs, die als Back-End-Dienst für API Gateway verwendet werden, können Sie mit diesen Einstellungen genau steuern, wie sich Ihr Load-Balancer verhält.

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

  • Serverlose NEGs können nicht mit anderen Arten von NEGs im selben Back-End-Dienst verwendet werden. Beispielsweise ist das Routing an einen GKE-Cluster und eine API Gateway-Instanz vom selben Back-End-Dienst nicht möglich.
  • 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.

Wenn Sie eine Back-End-Dienstkonfiguration definieren, die an eine serverlose NEG weitergeleitet wird, gelten die folgenden Feldeinschrä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 Feldern für utilization oder connection angegeben sind, werden nicht unterstützt.

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

Nächste Schritte