Load Balancing für API Gateway

Durch die Einbindung von globalen externen Application Load Balancern und klassischen Application Load Balancern in API Gateway können Ihre serverlosen Back-Ends alle Funktionen von Cloud Load Balancing nutzen. Wenn Sie API Gateway mit einem globalen externen Application Load Balancer oder einem klassischen Application Load Balancer mit einer serverlosen Netzwerk-Endpunktgruppe (serverless NEG) 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-Routing zu mehreren Backends erstellen
  • 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
  • Antwortzeit des Gateways mit Cloud CDN verbessern

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 Backend, das auf ein von Google gehostetes serverloses Backend 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 Backend-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 so 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. Insbesondere:

  • Serverlose NEGs können 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 gibt es keine Möglichkeit, den Zugriff auf Ihr API Gateway über eine vom Dienst generierte Gateway-URL zu deaktivieren und dafür zu sorgen, 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 Backend-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.

Beim Definieren einer Backend-Dienstkonfiguration, 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 Backend-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