Gateway-Traffic-Verwaltung

Autopilot Standard

---

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

Ü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

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.

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. Die Traffic-Aufteilung wird mit einzelnen Cluster-Gateways in GA unterstützt.

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-rilb-mc
gke-l7-gxlb-mc

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

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 weniger 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 max-rate-per-endpoint="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

Erstellen Sie zum Konfigurieren der Service-Kapazität einen Service mit der Annotation networking.gke.io/max-rate-per-endpoint. Das folgende Manifest beschreibt einen Service mit einer maximalen Anzahl von Anfragen pro Sekunde:

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 max-rate-per-endpoint 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 max-rate-per-endpoint mit der Anzahl der Replikate berechnet, wie in der folgenden Formel beschrieben:

Total Service capacity = max-rate-per-endpoint * 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 Service-Kapazität mit der Annotation max-rate-per-endpoint gilt nur für eingehenden Traffic über ein unterstütztes Gateway. Das kapazitätsbasierte Load-Balancing für das ClusterIP-Load-Balancing im Cluster oder für 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 Annotation max-rate-per-endpoint verwendet. Bei Verwendung eigenständiger NEGs wird max-rate-per-endpoint 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 max-rate-per-endpoint 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 mit dem Feld "Annotation" konfiguriert wurden. Weitere Informationen finden Sie unter Standard-Service-Kapazität.

In der folgenden Tabelle werden die Standardkapazitäten beschrieben:

Load-Balancing-Ressourcentyp	Standard-max-rate-per-endpoint
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 averageUtilization 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 / ( averageUtilization * max-rate-per-endpoint) ]

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 6 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