Gateway-Traffic-Verwaltung

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 der Methode GKE-Gateway-Controller GKE-Nutzer können die Trafficverwaltung deklarativ und Kubernetes-nativ steuern.

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.

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.

• 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:

Regionales und zonales Load Balancing

Service-Kapazität, Standort und Zustand bestimmen, wie viel Traffic der Load-Balancer an ein bestimmtes Backend sendet. Entscheidungen über das Load Balancing werden auf den folgenden Ebenen getroffen:

• Regional: 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.

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.

• 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 ansteigt, gibt es gibt es keine anderen Cluster, in die dieser Traffic überläuft. 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.

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 verwenden. Andernfalls hat die Dienstkapazität keine Auswirkungen auf den Netzwerkverkehr.

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.

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 nützlich sein, wenn Sie interne und externe Load-Balancer manuell mithilfe von eigenständigen NEGs bereitstellen.

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.

• 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:

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.

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.

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

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

Nächste Schritte

• Gateways bereitstellen