Gateway-Traffic-Verwaltung

Autopilot Standard

Auf dieser Seite wird die Funktionsweise der Gateway-Traffic-Verwaltung erläutert.

Diese Seite richtet sich an Entwickler, Bediener und Netzwerkexperten, die Traffic mit der Gateway API bereitstellen und verwalten möchten.

Übersicht

Das Google Kubernetes Engine-Netzwerk (GKE) basiert auf Cloud Load Balancing. Mit Cloud Load Balancing kann eine einzelne Anycast-IP-Adresse die globale Traffic-Verwaltung ermöglichen. Die Traffic-Verwaltung von Google bietet globales und regionales Load-Balancing, Autoscaling und Kapazitätsverwaltung, um Traffic-Verteilung gleichmäßig, stabil und mit niedriger Latenz bereitzustellen. Mit dem GKE-Gateway-Controller können GKE-Nutzer die globale Traffic-Verwaltung von Google deklarativ und Kubernetes-nativ verwenden.

Informationen zum Testen des Traffic-Überlaufs zwischen Clustern finden Sie unter Kapazitätsbasiertes Load-Balancing bereitstellen. Informationen zum traffic-basierten Autoscaling finden Sie unter Autoscaling auf Basis des Load-Balancer-Traffics.

Trafficverwaltung

Load-Balancing, Autoscaling und Kapazitätsverwaltung sind die Grundlagen eines Traffic-Verwaltungssystems. Sie arbeiten zusammen, um die Systemlast auszugleichen und zu stabilisieren.

• Beim Load-Balancing wird der Traffic gemäß Standort, Systemstatus und verschiedenen Load-Balancing-Algorithmen auf Backend-Pods verteilt.
• Beim Autoscaling werden Arbeitslastreplikate skaliert, um mehr Kapazität zu schaffen und dadurch mehr Traffic zu verarbeiten.
• Die Kapazitätsverwaltung überwacht die Auslastung von Services, damit der Traffic zu Back-Ends mit freier Kapazität überlaufen kann, statt die Verfügbarkeit oder Leistung der Anwendung zu beeinträchtigen.

Diese Funktionen können je nach Ihren Zielen auf verschiedene Weise kombiniert werden. Beispiel:

• Wenn Sie die Vorteile von kostengünstigen Spot-VMs nutzen möchten, sollten Sie den Traffic so gleichmäßig wie möglich auf die Spot-VMs verteilen, auch wenn das die Latenz erhöht. Mithilfe von Load-Balancing und Kapazitätsverwaltung würde GKE den Traffic je nach Kapazität zwischen Regionen überlaufen lassen, sodass Spot-VMs überall, wo sie verfügbar sind, voll genutzt werden.

• Wenn Sie die Nutzerlatenz auf Kosten einer Überdimensionierung optimieren möchten, können Sie GKE-Cluster in vielen Regionen bereitstellen und die Kapazität dynamisch erhöhen, wenn die Last zunimmt. Mithilfe von Load-Balancing und Autoscaling würde GKE die Anzahl der Pods automatisch skalieren, wenn der Traffic stark zunimmt, damit der Traffic nicht in andere Regionen überlaufen muss. Die Kapazität von Regionen würde wachsen, sodass sie in der Lage sind, die Last so nahe wie möglich bei den Nutzern zu bewältigen.

Das folgende Diagramm zeigt das Load-Balancing, das Autoscaling und die Kapazitätsverwaltung:

Im Diagramm ist die Arbeitslast im Cluster gke-us fehlgeschlagen. Load-Balancing und Systemdiagnose beenden aktive Verbindungen und leiten Traffic an den nächstgelegenen Cluster weiter. Die Arbeitslast in gke-asia empfängt mehr Traffic, als ihre Kapazität zulässt. Daher wird ein Teil der Last zu gke-eu geleitet. gke-eu erhält aufgrund von Ereignissen in gke-us und gke-asia mehr Last als üblich. Daher wird gke-eu automatisch skaliert, um die Traffic-Kapazität zu erhöhen.

Weitere Informationen dazu, wie Cloud Load Balancing die Traffic-Verwaltung handhabt, finden Sie unter Globale Kapazitätsverwaltung.

Funktionen zur Traffic-Verwaltung und Diensterweiterungen

Gateway-, HTTPRoute-, Dienst- und Richtlinienressourcen bieten die Steuerelemente zur Verwaltung von Traffic in GKE. Der GKE-Gateway-Controller ist die Steuerungsebene, die diese Ressourcen überwacht.

Mit GKE Gateway-Diensterweiterungen lässt sich die Trafficverwaltung in GKE anpassen und erweitern. Mit Erweiterungen wird benutzerdefinierte Logik für die erweiterte Traffic-Steuerung eingefügt.

Die folgenden Traffic-Verwaltungsfunktionen sind verfügbar, wenn Sie Services in GKE bereitstellen:

• Service-Kapazität: Die Möglichkeit, die Menge an Traffic-Kapazität anzugeben, die ein Service empfangen kann, bevor Pods automatisch skaliert werden oder der Traffic zu anderen verfügbaren Clustern überläuft.
• Traffic-basiertes Autoscaling: Autoscaling von Pods in einem Service anhand der pro Sekunde empfangenen HTTP-Anfragen.
• Multi-Cluster-Load-Balancing: Load-Balancing für Services, die in mehreren GKE-Clustern oder mehreren Regionen gehostet werden.
• Traffic-Aufteilung: explizite, gewichtete Traffic-Verteilung auf Back-Ends.

• Benutzerdefinierte Traffic-Verwaltung mit Diensterweiterungen:

  Mit Dienst-Erweiterungen haben Sie folgende Möglichkeiten:

  • Header und Nutzlasten für HTTP-Anfragen und -Antworten ändern.
  • Benutzerdefinierte Routinglogik implementieren, um den Trafficfluss zu steuern.
  • Integration in externe Dienste für Funktionen wie die Autorisierung

Hinweis: Die Unterstützung für Diensterweiterungen befindet sich in der Vorschauphase.

Unterstützung der Traffic-Verwaltung

Die verfügbaren Funktionen zur Traffic-Verwaltung hängen von der bereitgestellten GatewayClass ab. Eine vollständige Liste der Feature-Unterstützung finden Sie unter GatewayClass-Funktionen. In der folgenden Tabelle wird die GatewayClass-Unterstützung für die Traffic-Verwaltung zusammengefasst:

GatewayClass	Service-Kapazität	Traffic-Autoscaling	Multi-Cluster-Load-Balancing	Traffic-Aufteilung^1
gke-l7-global-external-managed
gke-l7-regional-external-managed
gke-l7-rilb
gke-l7-gxlb
gke-l7-global-external-managed-mc
gke-l7-regional-external-managed-mc
gke-l7-cross-regional-internal-managed-mc
gke-l7-rilb-mc
gke-l7-gxlb-mc

¹ Die Traffic-Aufteilung wird mit einzelnen Cluster-Gateways in GA unterstützt.

Traffic-Verwaltung mit Load-Balancing auf Basis benutzerdefinierter Messwerte

Google Cloud Application Load Balancer verteilen den Traffic anhand benutzerdefinierter Messwerte. Diese Messwerte können die GPU-Auslastung oder andere anwendungsspezifische Auslastungssignale umfassen. Benutzerdefinierte Messwerte bieten einen genaueren Überblick über die Leistung von Arbeitslasten. Ihre Anwendung meldet diese Messwerte mithilfe des ORCA-Standards (Open Request Cost Aggregation). Weitere Informationen finden Sie unter Benutzerdefinierte Messwerte für Application Load Balancer.

In GKE können Sie diese erweiterte Funktion zur Trafficverwaltung über die GKE Gateway API einbinden. Die API ist nützlich für Arbeitslasten mit variabler Ressourcennutzung, z. B. für die Inferenz generativer KI. Sie können benutzerdefiniertes Trafficverhalten einrichten, indem Sie die folgenden Richtlinien konfigurieren:

• GCPBackendPolicy für die Back-End-Auswahl: Mit der GCPBackendPolicy-Ressource lässt sich genau steuern, wie Back-End-Dienste eines Load-Balancers Traffic an ihre Back-Ends verteilen. Diese Richtlinie enthält bestimmte Felder, mit denen Sie verschiedene Load-Balancing-Modi konfigurieren können, z. B. die Verwendung benutzerdefinierter Messwerte. Informationen zum Konfigurieren der Back-End-Auswahl mit GCPBackendPolicy finden Sie unter Back-End-Auswahl mit GCPBackendPolicy konfigurieren.

• GCPTrafficDistributionPolicy für das Routing auf Endpunktebene: Mit GCPTrafficDistributionPolicy wird der Load-Balancing-Algorithmus für die Auswahl von Endpunkten innerhalb eines Back-Ends konfiguriert. Wenn Sie WEIGHTED_ROUND_ROBIN auswählen, verwendet der Load Balancer Gewichte, die aus gemeldeten Messwerten (einschließlich benutzerdefinierter Messwerte) abgeleitet werden, um den Traffic auf einzelne Instanzen oder Endpunkte zu verteilen. Informationen zum Konfigurieren von Messwerten auf Endpunktebene finden Sie unter Routing auf Endpunktebene mit GCPTrafficDistributionPolicy konfigurieren.

Standortbasierte Richtlinien

Sie können diese standortbasierten Richtlinien mithilfe eines Standortspezifizierers auf bestimmte Google Cloud -Zonen oder ‑Regionen anwenden. Standortspezifizierer, die für Canary-Bereitstellungen, stufenweise Roll-outs oder zum Testen von Richtlinienänderungen in isolierten Regionen nützlich sind. Weitere Informationen finden Sie unter Gateway-Ressourcen mithilfe von Richtlinien konfigurieren.

Benutzerdefinierte Messwerte für GKE-Back-Ends überwachen

Globale externe Application Load Balancer und interne Application Load Balancer bieten Logging- und Monitoringfunktionen, mit denen Sie benutzerdefinierte Messwerte beobachten können, die von Ihren GKE-Back-Ends gemeldet werden, um detaillierte Informationen zum Traffic zu erhalten. Weitere Informationen finden Sie unter Logging und Monitoring für globale externe Application Load Balancer.

Mit den GKE-Messwertlabels können Sie benutzerdefinierte Messwerte nach GKE-Dienst, Cluster und Namespace abfragen.

Wenn Sie die von Ihren GKE-Back-Ends gemeldeten benutzerdefinierten Messwerte aufrufen möchten, rufen Sie Cloud Monitoring auf und sehen Sie sich die benutzerdefinierten Messwerte unter der überwachten Ressource network.googleapis.com/loadbalancer/backend/ an. Sie können GKE-spezifische Labels verwenden, um diese Messwerte abzufragen und zu filtern.

Folgende Messwerte sind verfügbar:

• /error_rate: Fehler, die von jeder Backend-Gruppe pro Sekunde ausgegeben werden.
• /custom_metrics: Aktuelle Auslastung der einzelnen Backend-Gruppen basierend auf Ihren benutzerdefinierten Messwerten.
• /fullness: Aktuelle Auslastung (Last oder Kapazität) nach Back-End-Gruppe, die von Load-Balancern für Routing-Entscheidungen verwendet wird.
• /rate: Anfragen, die pro Sekunde von jeder Backend-Gruppe empfangen werden.

GKE-spezifische Labels, die die Überwachung dieser Messwerte verbessern, sind gke_service_name, gke_namespace und gke_cluster. Mit diesen Labels können Sie Messwertdaten nach GKE-Dienst, Namespace und Cluster aufschlüsseln. Diese GKE-Labels werden nur ausgefüllt, wenn backend_type ZONAL_NETWORK_ENDPOINT_GROUP ist.

In der folgenden Tabelle sind GKE-spezifische Labels aufgeführt:

Label	Typ	Beschreibung
gke_service_name	Messwertlabel oder Systemlabel	Der Dienstname der GKE-Ressource, falls vorhanden. Dieses Feld wird nur ausgefüllt, wenn `backend_type` ZONAL_NETWORK_ENDPOINT_GROUP ist. Bei anderen Backend-Typen ist dieses Label null.
gke_namespace	Messwertlabel oder Systemlabel	Namespace der GKE-Ressource, falls vorhanden. Dieses Feld wird nur ausgefüllt, wenn `backend_type` ZONAL_NETWORK_ENDPOINT_GROUP ist. Bei anderen Backend-Typen ist dieses Label null.
gke_cluster	Messwertlabel oder Systemlabel	Der Name des GKE-Cluster der Ressource, falls vorhanden. Dieses Feld wird nur ausgefüllt, wenn `backend_type` ZONAL_NETWORK_ENDPOINT_GROUP ist. Bei anderen Backend-Typen ist dieses Label null.

Die Logeinträge für globale externe Application Load Balancer enthalten Informationen, die Sie für das Monitoring und die Fehlerbehebung bei Ihrem HTTP(S)-Traffic verwenden können.

Globales, regionales und zonales Load-Balancing

Service-Kapazität, Standort und Zustand bestimmen, wie viel Traffic der Load-Balancer an ein bestimmtes Backend sendet. Load-Balancing-Entscheidungen werden auf den folgenden Ebenen getroffen, beginnend mit global für globale Load-Balancer und regional für regionale Load-Balancer:

• Global: Traffic wird an die am nächsten am Client liegende Google Cloud -Region mit fehlerfreien Back-Ends mit freier Kapazität gesendet. Solange die Region freie Kapazität hat, empfängt sie den gesamten nächstgelegenen Traffic. Wenn eine Region keine freie Kapazität hat, läuft der überschüssige Traffic in die nächstgelegene Region mit freier Kapazität über. Weitere Informationen finden Sie unter Globales Load-Balancing.
• Regional: Traffic wird vom Load-Balancer an eine bestimmte Region gesendet. Für den Traffic erfolgt das Load-Balancing über Zonen hinweg entsprechend der verfügbaren Bereitstellungskapazität der Zone. Weitere Informationen finden Sie unter Regionales Load-Balancing.
• Zonal: Nachdem der Traffic für eine bestimmte Zone ermittelt wurde, verteilt der Load-Balancer den Traffic gleichmäßig auf die Back-Ends innerhalb dieser Zone. Vorhandene TCP-Verbindungen und Sitzungspersistenzeinstellungen werden beibehalten, sodass zukünftige Anfragen an dieselben Backends gesendet werden, solange der Backend-Pod fehlerfrei ist. Weitere Informationen finden Sie unter Zonales Load-Balancing.

Globales Load-Balancing und Traffic-Überlauf

Informationen zum Testen der folgenden Konzepte in Ihrem eigenen Cluster finden Sie unter Kapazitätsbasiertes Load-Balancing.

Unter normalen Bedingungen wird der Traffic an das am nächsten am Client liegende Backend gesendet. Der Traffic endet an dem am nächsten am Client liegenden Point of Presence (PoP) von Google und durchquert dann das Google-Backbone, bis er das nächstgelegene Backend entsprechend der Netzwerklatenz erreicht. Wenn die Back-Ends in einer Region nicht genügend Kapazität haben, läuft der Traffic zum nächstgelegenen Cluster mit fehlerfreien Back-Ends mit freier Kapazität über. Wenn mehr als 50% der Backend-Pods innerhalb einer Zone fehlerhaft sind, erfolgt für den Traffic unabhängig von der konfigurierten Kapazität schrittweise ein Failover zu anderen Zonen oder Regionen.

Traffic-Überlauf findet nur unter folgenden Bedingungen statt:

• Sie verwenden ein Multi-Cluster-Gateway.
• Sie haben denselben Service in mehreren Clustern bereitgestellt, die vom Multi-Cluster-Gateway bedient werden.
• Sie haben Service-Kapazitäten so konfiguriert, dass der Traffic die Service-Kapazitäten in einem Cluster überschreitet, in anderen jedoch nicht.

Das folgende Diagramm zeigt, wie das globale Load-Balancing mit Traffic-Überlauf funktioniert:

Das Diagramm zeigt Folgendes:

• Ein Multi-Cluster-Gateway bietet globales Internet-Load-Balancing für den store-Service. Der Service wird in zwei GKE-Clustern bereitgestellt, einem in us-west1 und einem in europe-west1. In jedem Cluster werden zwei Replikate ausgeführt.
• Jeder Service wird mit max-rate-per-endpoint="10" konfiguriert. Dies bedeutet, dass jeder Service eine Gesamtkapazität von 2 Replikaten * 10 RPS = 20 RPS in jedem Cluster hat.
• Google-PoPs in Nordamerika erhalten 6 RPS. Der gesamte Traffic wird an das nächstgelegene fehlerfreie Backend mit freier Kapazität gesendet: den GKE-Cluster in us-west1.
• Europäische PoPs erhalten 30 kumulative Anfragen pro Sekunde. Die nächstgelegenen Back-Ends befinden sich in europe-west1, haben aber nur eine Kapazität von 20 RPS. Da die Back-Ends in us-west1 eine Überkapazität haben, laufen 10 RPS zu us-west1 über, sodass die Region insgesamt 16 RPS erhält und 8 RPS an jeden Pod verteilt.

Hinweis: Wenn Sie Single-Cluster-Gateways, einen Service vom Typ LoadBalancer oder Ingress-Ressourcen verwenden, gilt dieses Load-Balancing-Beispiel nicht, da für diese Ressourcen nur eine Load-Balancing auf einen einzelnen Cluster innerhalb einer einzelnen Region erfolgt. Multi-Cluster-Gateways werden empfohlen, wenn Sie globale Load-Balancing-Anforderungen haben.

Traffic-Überlauf verhindern

Der Traffic-Überlauf verhindert, dass die Anwendungskapazität überschritten wird, was sich auf die Leistung oder Verfügbarkeit auswirken könnte.

Möglicherweise möchten Sie den Traffic aber nicht überlaufen lassen. Latenzempfindliche Anwendungen profitieren möglicherweise nicht vom Überlauf des Traffics zu einem viel weiter entfernten Backend.

Sie können den Traffic-Überlauf mit folgenden Methoden verhindern:

• Verwenden Sie nur Single-Cluster-Gateways, die Services nur in einem einzelnen Cluster hosten können.

• Selbst wenn Multi-Cluster-Gateways verwendet werden, können Replikate einer Anwendung, die über mehrere Cluster hinweg bereitgestellt wird, als separate Services bereitgestellt werden. Aus Sicht des Gateways ermöglicht dies das Multi-Cluster-Load-Balancing, aggregiert jedoch nicht alle Endpunkte eines Service zwischen Clustern.

• Legen Sie die Service-Kapazitäten auf ein ausreichend hohes Niveau fest, das von der Traffic-Kapazität realistischerweise nie überschritten wird, es sei denn, es ist unbedingt erforderlich.

Load-Balancing innerhalb einer Region

Innerhalb einer Region wird der Traffic gemäß den verfügbaren Kapazitäten der Back-Ends auf Zonen verteilt. Hierbei wird kein Überlauf verwendet, sondern ein Load-Balancing, das direkt proportional zu den Service-Kapazitäten in jeder Zone ist. Jeder einzelne Traffic-Fluss bzw. jede einzelne Sitzung wird immer an einen einzigen, konsistenten Backend-Pod gesendet und nicht aufgeteilt.

Das folgende Diagramm zeigt, wie Traffic innerhalb einer Region verteilt wird:

Das Diagramm zeigt Folgendes:

• Ein Service wird in einem regionalen GKE-Cluster bereitgestellt. Der Service hat 4 Pods, die ungleichmäßig auf Zonen verteilt sind. 3 Pods befinden sich in Zone A, 1 Pod in Zone B und 0 Pods in Zone C.
• Der Service ist mit maxRatePerEndpoint=10 konfiguriert. Zone A hat eine Gesamtkapazität von 30 RPS, Zone B hat eine Gesamtkapazität von 10 RPS und Zone C hat eine Gesamtkapazität von 0 RPS, da sie keine Pods hat.
• Das Gateway empfängt insgesamt 16 RPS an Traffic von verschiedenen Clients. Dieser Traffic wird auf die Zonen proportional zur verbleibenden Kapazität in den einzelnen Zonen verteilt.
• Der Traffic-Fluss von einer einzelnen Quelle oder einem Client wird gemäß den Einstellungen für die Persistenz von Sitzungen konsistent auf einen einzelnen Backend-Pod verteilt. Die Verteilung der Trafficaufteilungen auf verschiedene Quell-Traffic damit einzelne Abläufe niemals aufgeteilt werden. Daher ist ein Mindestmaß an Quell- oder Clientdiversität erforderlich, um Traffic detailliert auf Back-Ends zu verteilen.

Wenn der eingehende Traffic beispielsweise von 16 RPS auf 60 RPS steigt, tritt eines der folgenden Szenarien auf:

• Wenn Sie Single-Cluster-Gateways verwenden, gibt es keine anderen Cluster oder Regionen, zu denen dieser Traffic überlaufen kann. Der Traffic wird weiterhin gemäß den relativen zonalen Kapazitäten verteilt, auch wenn eingehender Traffic die Gesamtkapazität überschreitet. Daher erhält Zone A 45 RPS und Zone B 15 RPS.
• Wenn Sie Multi-Cluster-Gateways mit Services verwenden, die auf mehrere Cluster verteilt sind, kann der Traffic zu anderen Clustern und anderen Regionen überlaufen, wie unter Globales Load-Balancing und Traffic-Überlauf beschrieben. Zone A empfängt 30 RPS, Zone B erhält 10 RPS und 20 RPS laufen zu einem anderen Cluster über.

Hinweis: Cloud Load Balancing beendet den Traffic nicht automatisch, wenn Back-Ends überlastet sind. Der Traffic läuft zu beliebigen verfügbaren Back-Ends mit freier Kapazität über. Wenn alle Back-Ends überlastet sind, wird der Überlauf-Traffic auf alle Back-Ends gemäß ihrer Gesamtkapazität verteilt. Dies überschreitet die Gesamt-Service-Kapazität.

Load-Balancing innerhalb einer Zone

Sobald der Traffic an eine Zone gesendet wurde, wird er gleichmäßig auf alle Back-Ends innerhalb dieser Zone verteilt. HTTP-Sitzungen sind je nach Einstellung der Sitzungsaffinität dauerhaft. Vorhandene TCP-Verbindungen werden nur dann zu einem anderen Backend verschoben, wenn das Backend nicht mehr verfügbar ist. Dies bedeutet, dass langlebige Verbindungen auch dann zum selben Backend-Pod geleitet werden, wenn neue Verbindungen aufgrund begrenzter Kapazität überlaufen. Der Load-Balancer priorisiert die Aufrechterhaltung vorhandener Verbindungen gegenüber neuen.

Service-Kapazität

Mit der Service-Kapazität können Sie einen Wert für die Anfragen pro Sekunde (RPS) pro Pod in einem Service definieren. Dieser Wert stellt die durchschnittlichen Anfragen pro Sekunde pro Pod dar, die ein Service durchschnittlich empfangen kann. Dieser Wert ist für Services konfigurierbar und wird für das traffic-basierte Autoscaling und das kapazitätsbasierte Load-Balancing verwendet.

Voraussetzungen

Für die Service-Kapazität gelten die folgenden Anforderungen und Einschränkungen:

• Wird nur mit den GatewayClass-Ressourcen und Ingress-Typen unterstützt, die unter Unterstützung der Traffic-Verwaltung definiert sind.
• Dies wirkt sich nur dann auf das Load-Balancing aus, wenn Sie trafficbasiertes Autoscaling oder Multi-Cluster-Gateways verwenden. Wenn Sie diese Funktionen nicht verwenden, hat die Service-Kapazität keine Auswirkungen auf den Netzwerk-Traffic.

Service-Kapazität konfigurieren

Single-Cluster-Gateways

Ihr GKE-Cluster muss die Version 1.31.1-gke.2008000 oder höher ausführen. In früheren Versionen kann die Annotation networking.gke.io/max-rate-per-endpoint wie auf dem Tab Multi-Cluster-Gateways beschrieben verwendet werden.

Wenn Sie die Service-Kapazität mit Single-Cluster-Gateways konfigurieren möchten, erstellen Sie einen Service und ein zugehöriges GCPBackendPolicy. Verwenden Sie das folgende Manifest, um einen Dienst zu erstellen:

apiVersion: v1
kind: Service
metadata:
  name: store
spec:
  ports:
  - port: 8080
    targetPort: 8080
    name: http
  selector:
    app: store
  type: ClusterIP

Konfigurieren Sie das GCPBackendPolicy-Objekt mit dem Feld maxRatePerEndpoint mit einem maximalen RPS. Verwenden Sie das folgende Manifest, um das GCPBackendPolicy-Objekt zu konfigurieren:

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: store
spec:
  default:
    maxRatePerEndpoint: RATE_PER_SECOND
  targetRef:
    group: ""
    kind: Service
    name: store

Multi-Cluster-Gateways

Wenn Sie Multi-Cluster-Gateways zum Konfigurieren der Service-Kapazität verwenden möchten, erstellen Sie einen Service mit der Annotation networking.gke.io/max-rate-per-endpoint. Verwenden Sie das folgende Manifest, um einen Dienst mit einer maximalen Anzahl von Anfragen pro Sekunde zu erstellen:

apiVersion: v1
kind: Service
metadata:
  name: store
  annotations:
    networking.gke.io/max-rate-per-endpoint: "RATE_PER_SECOND"
spec:
  ports:
  - port: 8080
    targetPort: 8080
    name: http
  selector:
    app: store
  type: ClusterIP

Ersetzen Sie RATE_PER_SECOND durch das Maximum an HTTP-/HTTPS-Anfragen pro Sekunde, die ein einzelner Pod in diesem Service empfangen soll.

Der Wert maxRatePerEndpoint schafft eine dynamische Kapazität für einen Service auf Basis der Anzahl der Pods im Service. Der gesamte Service-Kapazitätswert wird durch Multiplizieren des Werts maxRatePerEndpoint mit der Anzahl der Replikate berechnet, wie in der folgenden Formel beschrieben:

Total Service capacity = maxRatePerEndpoint * number of replicas

Wenn das Autoscaling die Anzahl der Pods innerhalb eines Service hochskaliert, wird die Gesamtkapazität des Service entsprechend berechnet. Wenn ein Service auf null Pods herunterskaliert wird, hat er keine Kapazität und empfängt keinen Traffic vom Load-Balancer.

Hinweis: Die Konfiguration der Dienstkapazität mit dem Feld maxRatePerEndpoint im GCPBackendPolicy gilt nur für eingehenden Traffic über ein unterstütztes Gateway. Das kapazitätsbasierte Load-Balancing für den Typ ClusterIP im Cluster oder für die Services vom Typ LoadBalancer wird dadurch nicht beeinflusst.

Service-Kapazität und eigenständige NEGs

Die Service-Kapazität kann auch bei Verwendung von eigenständigen NEGs konfiguriert werden, jedoch wird dabei nicht die Einstellung maxRatePerEndpoint verwendet. Bei Verwendung eigenständiger NEGs wird maxRatePerEndpoint beim Hinzufügen der NEG zu einer Backend-Service-Ressource manuell konfiguriert. Mit dem Befehl gcloud compute backend-services add-backend kann das Flag --max-rate-per-endpoint die Kapazität für jede NEG einzeln konfigurieren.

Dies kann für jeden der folgenden Workflows nützlich sein:

• Beim manuellen Bereitstellen interner und externer Load-Balancer mithilfe von eigenständigen NEGs
• Bei der Bereitstellung von Cloud Service Mesh in GKE mit eigenständigen NEGs

Beim Konfigurieren der Service-Kapazität mit eigenständigen NEGs gibt es keinen funktionalen Unterschied. Sowohl Traffic-Autoscaling als auch Traffic-Überlauf werden unterstützt.

Kapazität des Service bestimmen

Um den Wert für maxRatePerEndpoint zu ermitteln, müssen Sie die Leistungsmerkmale Ihrer Anwendungen und Ihre Load-Balancing-Ziele verstehen. Mit den folgenden Strategien können Sie die Leistungsmerkmale Ihrer Anwendung definieren:

• Beobachten Sie Ihre Anwendung sowohl in Test- als auch in Produktionsumgebungen, wenn sie ohne Service-Kapazität konfiguriert sind.

• Verwenden Sie Cloud Monitoring, um eine Korrelation zwischen Traffic-Anfragen und Ihren Service Level Objectives (SLOs) zu erstellen.

• Verwenden Sie Load-Balancer-Messwerte wie https oder request_count, um RPS-Stufen zuzuordnen.

• Definieren Sie die Leistungs-SLOs für Ihre Anwendung. Je nachdem, was Sie als „schlechte“ oder „instabile“ Leistung betrachten, können sie eine oder mehrere der folgenden sein. Alle folgenden Informationen können mithilfe von Cloud Monitoring-Load-Balancer-Messwerten erfasst werden:

  • Antwortfehlercodes
  • Antwort- oder Gesamtlatenz
  • Backend-Fehler oder -Ausfallzeiten

• Beobachten Sie Ihre Anwendung bei bestehender Traffic-Last in Test- und Produktionsumgebungen. Belasten Sie in Testumgebungen Ihre Anwendung unter zunehmender Anfragelast, um zu sehen, wie es sich auf die verschiedenen Leistungsmesswerte auswirkt, wenn der Traffic zunimmt. Beobachten Sie in Produktionsumgebungen realistische Traffic-Muster-Stufen.

Standard-Service-Kapazität

Alle an GKE-Ressourcen angehängten Dienste haben einen konfigurierten Standarddienst, auch wenn sie nicht explizit konfiguriert wurden. Weitere Informationen finden Sie unter Standard-Service-Kapazität.

In der folgenden Tabelle werden die Standardkapazitäten beschrieben:

Load-Balancing-Ressourcentyp	Standard-maxRatePerEndpoint
Ingress (intern und extern)	1 RPS
Gateway (alle GatewayClasses)	100.000.000 RPS
MultiClusterIngress	100.000.000 RPS

Traffic-basiertes Autoscaling

Traffic-basiertes Autoscaling ist eine Funktion von GKE, die Traffic-Signale von Load-Balancern nativ in Pods integriert. Traffic-basiertes Autoscaling wird nur für Single-Cluster-Gateways unterstützt.

Informationen zur Verwendung des traffic-basierten Autoscalings finden Sie unter Autoscaling auf Basis des Load-Balancer-Traffics.

Traffic-basiertes Autoscaling bietet folgende Vorteile:

• Anwendungen, die nicht streng CPU- oder arbeitsspeichergebunden sind, können Kapazitätslimits haben, die nicht in ihrer CPU- oder Arbeitsspeichernutzung widergespiegelt werden.
• Traffic oder die Anfragen pro Sekunde (RPS) sind in einigen Fällen ein einfacher zu verstehender Messwert, da sie besser die Nutzung von Anwendungen sowie Geschäftsmesswerte wie Seitenaufrufe oder aktive Nutzer pro Tag widerspiegeln.
• Der Traffic ist ein führender Indikator für die sofortige Nachfrage im Vergleich zu CPU oder Arbeitsspeicher, bei denen es sich um verzögerte Indikatoren handelt.
• Die Kombination aus CPU-, Arbeitsspeicher- und Traffic-Autoscaling-Messwerten bietet eine ganzheitliche Möglichkeit für das Autoscaling von Anwendungen, bei der mehrere Dimensionen verwendet werden, um sicherzustellen, dass ausreichend Kapazität bereitgestellt wird.

Das folgende Diagramm zeigt, wie das traffic-basierte Autoscaling funktioniert:

Das Diagramm zeigt Folgendes:

• Der Service-Inhaber konfiguriert die Service-Kapazität und eine Zielauslastung für das Deployment.
• Das Gateway empfängt von Clients Traffic, der an den store-Service gesendet wird. Das Gateway sendet Telemetriedaten zur Auslastung an das GKE-Pod-Autoscaling. Die Auslastung entspricht dem tatsächlichen Traffic, der von einem einzelnen Pod empfangen wird, geteilt durch die konfigurierte Kapazität des Pods.
• Das GKE-Pod-Autoscaling skaliert Pods je nach konfigurierter Zielauslastung hoch oder herunter.

Verhalten von Autoscaling

Im folgenden Diagramm ist dargestellt, wie das traffic-basierte Autoscaling bei einer Anwendung funktioniert, die 10 RPS über den Load-Balancer empfängt:

Im Diagramm hat der Service-Inhaber die Kapazität des Speicher-Service auf 10 RPS konfiguriert. Dies bedeutet, dass jeder Pod maximal 10 RPS empfangen kann. Für den HorizontalPodAutoscaler ist averageValue auf 70gesetzt. Dies bedeutet, dass die Zielauslastung 70 % von 10 RPS pro Pod beträgt.

Das Autoscaling versucht, Replikate zu skalieren, um die folgende Gleichung zu erreichen:

replicas = ceiling[ current traffic / ( averageValue * maxRatePerEndpoint) ]

Im Diagramm ergibt diese Gleichung Folgendes:

ceiling[ 10 rps / (0.7 * 10 rps) ] = ceiling[ 1.4 ] = 2 replicas

10 RPS an Traffic führen zu zwei Replikaten. Jedes Replikat erhält 5 RPS, was unter der Zielauslastung von 7 RPS liegt.

Hinweis: Änderungen der Traffic-Mengen oder Traffic-Spitzen können dazu führen, dass das Autoscaling die Gleichung für die Zielreplikate annähert. Unter stabilen Bedingungen nähert sich die Anzahl der Replikate dem Ziel an, ist aber möglicherweise nicht immer genau, insbesondere bei schwankendem Traffic.

Traffic-Aufteilung

Bei der Traffic-Aufteilung wird ein explizites Verhältnis verwendet, das als Gewichtung bezeichnet wird und den Anteil der HTTP-Anfragen definiert, die an einen Service gesendet werden. Mit HTTPRoute-Ressourcen können Sie Gewichtungen für eine Liste von Services konfigurieren. Die relative Gewichtung zwischen Services definiert die Aufteilung des Traffics zwischen ihnen. Dies ist nützlich, um Traffic während Roll-outs, Canary-Änderungen oder in Notfällen aufzuteilen.

Das folgende Diagramm zeigt ein Beispiel für eine Konfiguration der Traffic-Aufteilung:

Das Diagramm zeigt Folgendes:

• Der Dienstinhaber konfiguriert zwei Dienste für eine einzelne Route, wobei eine Regel den Traffic auf 90 % für store-v1 und 10 % auf store-v2 verteilt.
• Das Gateway empfängt Traffic von Clients, die zur URL der Geschäftsanwendung weiterleiten. Traffic wird gemäß der konfigurierten Regel aufgeteilt. 90 % der Trafficrouten nach store-v1 und 10 % der Routen nach store-v2.

Die Traffic-Aufteilung wird zwischen Services im selben Cluster und auch zwischen Services in verschiedenen Clustern unterstützt:

• Traffic-Aufteilung zwischen Services: Wird zum Aufteilen des Traffics für Roll-outs von Anwendungsversionen verwendet. Im Beispiel zur Traffic-Aufteilung haben Sie zwei separate Deployments, store-v1 und store-v2, die jeweils einen eigenen Service, store-v1 und store-v2, haben. Die Gewichtungen werden zwischen den beiden Services so konfiguriert, dass der Traffic schrittweise verschoben wird, bis store-v2 vollständig eingeführt ist.

  Hinweis: Die GatewayClass gke-l7-gxlb unterstützt keine Traffic-Aufteilung.

• Traffic-Aufteilung zwischen ServiceImports: Wird zum Verschieben des Traffics zu oder von bestimmten Clustern zu Wartungs-, Migrations- oder Notfallzwecken verwendet. ServiceImports stellen Multi-Cluster-Services dar und ermöglichen die Traffic-Aufteilung zwischen verschiedenen Services in verschiedenen Clustern. Die Übung Blau/Grün-Multi-Cluster-Routing mit Gateway zeigt, wie der Traffic auf Cluster aufgeteilt wird.

  Hinweis: Die GatewayClass gke-l7-gxlb-mc unterstützt keine Traffic-Aufteilung.

Gewichtung im Vergleich zu Kapazität

Gewichtungen und Kapazitäten steuern beide, wie viel Traffic an verschiedene Services gesendet wird. Obwohl sie ähnliche Auswirkungen haben, funktionieren sie unterschiedlich und haben unterschiedliche Anwendungsfälle. Sie können und sollten zusammen verwendet werden, aber für verschiedene Zwecke.

Gewicht

Die Gewichtung ist eine explizite Steuermöglichkeit für den Traffic. Sie definiert den genauen Anteil des Traffics, unabhängig vom eingehenden Traffic und von der Backend-Auslastung. Wenn im Beispiel zur Traffic-Aufteilung store-v2 überlastet ist oder alle zugehörigen Replikate fehlgeschlagen sind, werden 10 % des Traffics weiterhin store-v2 zugewiesen, was zur Folge hat, dass Traffic unterbrochen wird. Das liegt daran, dass die Gewichtung den Anteil des Traffics nicht basierend auf der Auslastung oder dem Status ändert.

Für die folgenden Anwendungsfälle eignet sich die Gewichtung am besten:

• Traffic bei Roll-outs zwischen verschiedenen Versionen eines Service verschieben
• Manuelles Onboarding von Services mit expliziten Traffic-Aufteilungen
• Traffic für Notfall- oder Wartungszwecke von einer Reihe von Back-Ends wegleiten

Kapazität

Die Kapazität ist eine implizite Steuermöglichkeit für den Traffic. Sie definiert den Anteil des Traffics indirekt, da er von der Menge des eingehenden Traffics, der Backend-Auslastung und dem Quellstandort des Traffics abhängt. Die Kapazität ist eine inhärente Eigenschaft eines Service und wird in der Regel wesentlich seltener aktualisiert.

Die Kapazität eignet sich am besten für die folgenden Anwendungsfälle:

• Verhinderung einer Backend-Überlastung während Traffic-Spitzen
• Steuerung der Autoscaling-Rate in Bezug auf den Traffic

Das Konfigurieren der Service-Kapazität für den Überlauf von Traffic ist möglicherweise nicht immer das gewünschte Verhalten. Betrachten Sie das Beispiel für globales Load-Balancing. Die Service-Kapazität schützt Back-Ends durch den Überlauf von Traffic vor einer Überlastung. Dies kann jedoch zu zusätzlicher Latenz bei Anfragen führen, die übergelaufen sind, da diese Anfragen in eine entferntere Region geleitet werden.

Wenn Ihre Anwendung nicht sehr empfindlich auf Überlastung reagiert, sollten Sie eine sehr hohe Service-Kapazität konfigurieren, damit der Traffic wahrscheinlich nicht in eine andere Region überläuft. Wenn die Verfügbarkeit oder Latenz Ihrer Anwendung empfindlich auf Überlastung reagiert, ist ein Überlauf des Traffic in andere Cluster oder Regionen möglicherweise besser, als übermäßigen Traffic von überlasteten Back-Ends verarbeiten zu lassen. Weitere Informationen zum Konfigurieren der Service-Kapazität für Ihre Anwendung finden Sie unter Kapazität des Service bestimmen.

Nächste Schritte

• Gateways bereitstellen
• Multi-Cluster-Gateways bereitstellen