Best Practices für die Skalierung von Cloud Service Mesh auf der GKE

In diesem Leitfaden werden Best Practices zur Behebung von Skalierungsproblemen für verwaltete Cloud Service Mesh-Architekturen in der Google Kubernetes Engine beschrieben. Das Hauptziel dieser Empfehlungen ist, die optimale Leistung, Zuverlässigkeit und Ressourcennutzung für Ihre Microservices-Anwendungen zu gewährleisten, wenn diese wachsen.

Informationen zu den Einschränkungen der Skalierbarkeit finden Sie unter Skalierungsgrenzen für Cloud Service Mesh.

Die Skalierbarkeit von Cloud Service Mesh auf der GKE hängt von der effizienten Ausführung der beiden Hauptkomponenten ab: der Datenebene und der Steuerungsebene. In diesem Dokument geht es hauptsächlich um die Skalierung der Datenebene.

Skalierungsprobleme der Steuerungsebene und der Datenebene identifizieren

In Cloud Service Mesh können Skalierungsprobleme entweder in der Steuerungsebene oder in der Datenebene auftreten. So können Sie feststellen, mit welcher Art von Skalierungsproblem Sie konfrontiert sind:

Symptome von Skalierungsproblemen der Steuerungsebene

Langsamer Service Discovery:Es dauert lange, bis neue Dienste oder Endpunkte erkannt und verfügbar werden.

Verzögerungen bei der Konfiguration:Es dauert lange, bis Änderungen an Regeln für die Trafficverwaltung oder an Sicherheitsrichtlinien weitergegeben werden.

Erhöhte Latenz bei Vorgängen der Steuerungsebene:Vorgänge wie das Erstellen, Aktualisieren oder Löschen von Cloud Service Mesh-Ressourcen werden langsam oder reagieren nicht mehr.

Fehler im Zusammenhang mit Traffic Director:In Cloud Service Mesh-Logs oder Messwerten der Steuerungsebene können Fehler auftreten, die auf Probleme mit der Konnektivität, Ressourcenüberlastung oder API-Drosselung hinweisen.

Umfang der Auswirkungen:Probleme mit der Steuerungsebene wirken sich in der Regel auf das gesamte Mesh aus und führen zu einer weit verbreiteten Leistungsminderung.

Weitergabe der Konfiguration

Bei der Verwendung von verwaltetem Cloud Service Mesh ist es wichtig, die Erwartungen hinsichtlich der Latenz bei der Weitergabe der Konfiguration zu verstehen.

Da die Steuerungsebene die globale Infrastruktur orchestriert, dauert es länger, bis Änderungen an Konfigurationsressourcen wie VirtualService und DestinationRule an die Sidecars weitergegeben werden. Plattformen für die kontinuierliche Bereitstellung sollten sich nicht auf statische Zeitverzögerungen oder strenge Zeitfenster für die Weitergabe der Konfiguration verlassen. Stattdessen sollten Sie dafür sorgen, dass Ihre Rollout-Vorgänge idempotent sind, und aktiv prüfen, ob die Trafficumstellung oder die Weitergabe der Konfiguration erfolgreich abgeschlossen wurde, bevor Sie mit den nächsten Schritten fortfahren. Entfernen Sie alle Abhängigkeiten von Zeitangaben, mit Ausnahme einer dedizierten Übergangszeit, die angewendet wird, nachdem bestätigt wurde, dass die richtige Konfiguration vorhanden ist.

Symptome von Skalierungsproblemen der Datenebene

Erhöhte Latenz bei der Dienst-zu-Dienst-Kommunikation:Anfragen an einen Dienst im Mesh haben eine höhere Latenz oder es treten Zeitüberschreitungen auf, aber die CPU-/Arbeitsspeicherauslastung in den Containern des Dienstes ist nicht erhöht.

Hohe CPU- oder Arbeitsspeicherauslastung in Envoy-Proxys:Eine hohe CPU- oder Arbeitsspeicherauslastung kann darauf hindeuten, dass die Proxys Schwierigkeiten haben, die Trafficlast zu bewältigen.

Lokale Auswirkungen:Probleme mit der Datenebene wirken sich in der Regel auf bestimmte Dienste oder Arbeitslasten aus, je nach Trafficmustern und Ressourcennutzung der Envoy-Proxys.

Datenebene skalieren

Verwenden Sie die folgenden Techniken, um die Datenebene zu skalieren:

Horizontales Pod-Autoscaling (HPA) für Arbeitslasten konfigurieren

Mit Horizontal Pod Autoscaling (HPA) können Sie Arbeitslasten dynamisch mit zusätzlichen Pods basierend auf der Ressourcennutzung skalieren. Beachten Sie bei der Konfiguration von HPA Folgendes:

  • Verwenden Sie den Parameter --horizontal-pod-autoscaler-sync-period für kube-controller-manager, um die Abrufrate des HPA-Controllers anzupassen. Die Standardabrufrate beträgt 15 Sekunden. Sie sollten sie möglicherweise senken, wenn Sie schnellere Trafficspitzen erwarten. Weitere Informationen dazu, wann HPA mit GKE verwendet werden sollte, finden Sie unter Horizontales Pod-Autoscaling.

  • Das Standardskalierungsverhalten kann dazu führen, dass eine große Anzahl von Pods gleichzeitig bereitgestellt (oder beendet) wird, was zu einer Spitze bei der Ressourcennutzung führen kann. Verwenden Sie Skalierungsrichtlinien um die Rate zu begrenzen, mit der Pods bereitgestellt werden können.

  • Verwenden Sie EXIT_ON_ZERO_ACTIVE_CONNECTIONS um zu vermeiden, dass Verbindungen während der Herunterskalierung getrennt werden.

Weitere Informationen zu HPA finden Sie in der Kubernetes-Dokumentation unter Horizontales Pod-Autoscaling.

Envoy-Proxykonfiguration optimieren

Berücksichtigen Sie die folgenden Empfehlungen, um die Envoy-Proxykonfiguration zu optimieren:

Ressourcenlimits

Sie können Ressourcenanfragen und ‑limits für Envoy-Sidecars in Ihren Pod-Spezifikationen definieren. So vermeiden Sie Ressourcenkonflikte und sorgen für eine gleichbleibende Leistung.

Sie können Ressourcenlimits für bestimmte Arbeitslasten mit Ressourcenannotationen in Ihren Pod-Spezifikationen überschreiben.

Die optimalen Ressourcenlimits für Ihre Envoy-Proxys hängen von Faktoren wie Trafficvolumen, Arbeitslastkomplexität und GKE-Knotenressourcen ab. Überwachen und optimieren Sie Ihr Service Mesh kontinuierlich , um eine optimale Leistung zu gewährleisten.

Wichtiger Hinweis :

  • Dienstqualität (Quality of Service, QoS) : Wenn Sie sowohl Anfragen als auch Limits festlegen, haben Ihre Envoy-Proxys eine vorhersehbare Dienstqualität.

Dienstabhängigkeiten eingrenzen

Sie können den Abhängigkeitsgraphen Ihres Mesh-Netzwerks reduzieren, indem Sie alle Abhängigkeiten über die Sidecar API deklarieren. Dadurch wird die Größe und Komplexität der Konfiguration begrenzt, die an eine bestimmte Arbeitslast gesendet wird. Das ist für größere Mesh-Netzwerke von entscheidender Bedeutung.

Das folgende Beispiel zeigt den Trafficgraphen für die Beispielanwendung „Online Boutique“.

Traffic-Diagramm für die Beispielanwendung „Online Boutique“ mit vielen Knoten

Viele dieser Dienste sind Blätter im Graphen und benötigen daher keine Informationen zum ausgehenden Traffic für die anderen Dienste im Mesh. Sie können eine Sidecar-Ressource anwenden, die den Umfang der Sidecar-Konfiguration für diese Blattdienste begrenzt, wie im folgenden Beispiel gezeigt.

apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: leafservices
  namespace: default
spec:
  workloadSelector:
    labels:
      app: cartservice
      app: shippingservice
      app: productcatalogservice
      app: paymentservice
      app: emailservice
      app: currencyservice
  egress:
  -   hosts:
    -   "~/*"

Details zur Bereitstellung dieser Beispielanwendung finden Sie unter Beispielanwendung „Online Boutique“.

Ein weiterer Vorteil der Sidecar-Eingrenzung ist die Reduzierung unnötiger DNS-Abfragen. Durch die Eingrenzung von Dienstabhängigkeiten wird sichergestellt, dass ein Envoy-Sidecar nur DNS-Abfragen für Dienste ausführt, mit denen es tatsächlich kommunizieren wird, und nicht für jeden Cluster im Service Mesh.

Für alle groß angelegten Bereitstellungen, bei denen Probleme mit großen Konfigurationsgrößen in den Sidecars auftreten, wird die Eingrenzung von Dienstabhängigkeiten dringend für die Mesh-Skalierbarkeit empfohlen.

Wenn Sie den Konfigurationsumfang für alle Arbeitslasten in einem einzelnen Namespace begrenzen möchten, erstellen Sie eine Sidecar-Ressource in diesem Namespace. Dadurch wird allen Envoy-Proxys in diesem Namespace mitgeteilt, dass sie nur Konfigurationen für Dienste im eigenen Namespace erhalten sollen.

apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: sidecar
  namespace: my-app
spec:
  egress:
  -   hosts:
    -   "my-app/*"

Sie können das Standardverhalten für jeden Namespace in Ihrem Mesh anwenden, indem Sie eine einzelne Sidecar-Ressource auf den Root-Namespace anwenden, in der Regel „istio-system“.

Die folgende Sidecar-Ressource beschränkt den ausgehenden Traffic jedes Sidecars im Mesh auf Dienste, die sich im eigenen Namespace befinden.

apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: sidear
  namespace: istio-system
spec:
  egress:
  -   hosts:
    -   "./*"

In Cloud Service Mesh ist die Gesamtzahl der Sidecar-Ressourcen begrenzt, die in einem einzelnen Mesh erstellt werden können. Aufgrund dieser Einschränkung wird empfohlen, Sidecars auf Namespace-Ebene zu erstellen.

Trafficaufteilung optimieren

Wenn Sie häufig Traffic umleiten, z. B. bei progressiven Rollouts oder Blue/Green-Bereitstellungen, wirkt sich die Methode, mit der Sie Traffic aufteilen, auf die Konfigurationslatenz aus.

  • Teilmengen für schnelle Umstellungen vermeiden:Wenn Sie Traffic mit subset-Feldern in Ihrem VirtualService in Kombination mit einer DestinationRule aufteilen, erstellt, trennt und verbindet die Steuerungsebene schnell zugrunde liegende Gruppen von Netzwerkendpunkten (Network Endpoint Groups, NEGs). Diese Abstimmung führt zu erheblichen Verzögerungen von mehreren Minuten, was dazu führen kann, dass bei schnellen automatisierten Rollouts Zwischengewichte für den Traffic übersprungen werden.
  • Hostbasiertes Routing bevorzugen:Konfigurieren Sie Ihre Bereitstellungen so, dass anstelle von Teilmengen die hostbasierte Trafficaufteilung verwendet wird. Durch das Routing von Traffic zwischen völlig unterschiedlichen unterstützenden Kubernetes-Diensten basierend auf VirtualService-Hostkonfigurationen vermeidet die Steuerungsebene die Verarbeitung von NEG-Konfigurationen. Dadurch wird der Infrastruktur-Aufwand reduziert und die Weitergabe der Konfiguration erfolgt viel schneller.

Überwachen und optimieren

Nachdem Sie die ersten Ressourcenlimits festgelegt haben, ist es wichtig, Ihre Envoy-Proxys zu überwachen, um sicherzustellen, dass sie optimal funktionieren. Verwenden Sie GKE-Dashboards, um die CPU- und Arbeitsspeicherauslastung zu überwachen und die Ressourcenlimits nach Bedarf anzupassen.

Um festzustellen, ob ein Envoy-Proxy höhere Ressourcenlimits benötigt, überwachen Sie den Ressourcenverbrauch unter normalen und Spitzen-Verkehrslagen. Achten Sie auf Folgendes:

  • Hohe CPU-Auslastung:Wenn die CPU-Auslastung von Envoy regelmäßig das Limit erreicht oder überschreitet, kann es Schwierigkeiten haben, Anfragen zu verarbeiten, was zu einer erhöhten Latenz oder zu verworfenen Anfragen führen kann. Erhöhen Sie das CPU-Limit.

    In diesem Fall sind Sie möglicherweise geneigt, horizontal zu skalieren. Wenn der Sidecar-Proxy jedoch die Anfragen nicht so schnell verarbeiten kann wie der Anwendungscontainer, kann die Anpassung der CPU-Limits die besten Ergebnisse liefern.

  • Hohe Arbeitsspeicherauslastung:Wenn die Arbeitsspeicherauslastung von Envoy das Limit erreicht oder überschreitet, kann es zu Verbindungsabbrüchen oder Fehlern aufgrund von Arbeitsspeichermangel (Out of Memory, OOM) kommen. Erhöhen Sie das Arbeitsspeicherlimit, um diese Probleme zu vermeiden.

  • Fehlerlogs:Prüfen Sie die Logs von Envoy auf Fehler im Zusammenhang mit Ressourcenüberlastung, z. B. upstream connect error, disconnect or reset before headers oder too many open files. Diese Fehler können darauf hindeuten, dass der Proxy mehr Ressourcen benötigt. Weitere Fehler im Zusammenhang mit Skalierungsproblemen finden Sie in der Dokumentation zur Fehlerbehebung bei der Skalierung.

  • Leistungsmesswerte:Überwachen Sie wichtige Leistungsmesswerte wie Anfragelatenz, Fehlerraten und Durchsatz. Wenn Sie eine Leistungsminderung feststellen, die mit einer hohen Ressourcennutzung zusammenhängt, müssen Sie möglicherweise die Limits erhöhen.

Wenn Sie Ressourcenlimits für Ihre Proxys auf Datenebene aktiv festlegen und überwachen, können Sie sicherstellen, dass Ihr Service Mesh in der GKE effizient skaliert wird.

Steuerungsebene skalieren

In diesem Abschnitt werden die Einstellungen beschrieben, die Sie für die Skalierung Ihrer Steuerungsebene anpassen können.

Auswahlregeln für die Erkennung

Auswahlregeln für die Erkennung sind ein Feld in der MeshConfig, mit dem Sie die Namespaces angeben können, die von Steuerungsebenen bei der Berechnung von Konfigurationsupdates für Sidecars berücksichtigt werden.

Standardmäßig überwacht Cloud Service Mesh alle Namespaces im Cluster. Das kann für große Cluster, die nicht alle Ressourcen überwachen müssen, ein Engpass sein.

Verwenden Sie discoverySelectors, um die Rechenlast auf der Steuerungsebene zu reduzieren, indem Sie die Anzahl der Kubernetes-Ressourcen (z. B. Dienste, Pods und Endpunkte) begrenzen, die überwacht und verarbeitet werden.

Bei Verwendung der TRAFFIC_DIRECTOR-Implementierung der Steuerungsebene erstellt Cloud Service Mesh nur Google Cloud Ressourcen wie Backend- Dienste und Gruppen von Netzwerkendpunkten für Kubernetes-Ressourcen in Namespaces , die in discoverySelectors angegeben sind.

Weitere Informationen finden Sie in der Istio-Dokumentation unter Auswahlregeln für die Erkennung.

Konfigurationsumfang minimieren

Verwenden Sie Auswahlregeln für die Erkennung, um den Konfigurations umfang zu begrenzen. Sie können die Sidecar-Konfiguration für ausgehenden Traffic verwenden, um die Arbeitsspeicherauslastung des Proxys zu begrenzen. Die Sidecar API erstellt jedoch komplexere Konfigurationen. Verwenden Sie die Sidecar API nur, um erhebliche Leistungsprobleme auf Datenebene zu beheben, da sie die Last der Steuerungsebene erhöht und die allgemeine Skalierbarkeit des Mesh-Netzwerks reduziert.

Resilienz einbauen

Sie können die folgenden Einstellungen anpassen, um die Resilienz Ihres Service Mesh zu erhöhen:

Ausreißererkennung

Die Ausreißererkennung überwacht Hosts in einem Upstream-Dienst und entfernt sie aus dem Load-Balancing-Pool, wenn ein bestimmter Fehlerschwellenwert erreicht wird.

  • Wichtige Konfiguration:
    • outlierDetection: Einstellungen, die die Bereinigung von fehlerhaften Hosts aus dem Load-Balancing-Pool steuern.
  • Vorteile:Sorgt für eine gesunde Anzahl von Hosts im Load-Balancing-Pool.

Weitere Informationen finden Sie in der Istio-Dokumentation unter Ausreißererkennung.

Neuversuche

Sie können vorübergehende Fehler beheben, indem Sie fehlgeschlagene Anfragen automatisch wiederholen.

  • Wichtige Konfiguration:
    • attempts: Anzahl der Wiederholungsversuche.
    • perTryTimeout: Zeitlimit pro Wiederholungsversuch. Legen Sie diesen Wert kürzer als das Gesamttimeout fest. Er bestimmt, wie lange Sie auf jeden einzelnen Wiederholungsversuch warten.
    • retryBudget: Maximale Anzahl gleichzeitiger Wiederholungsversuche.
  • Vorteile:Höhere Erfolgsraten für Anfragen, geringere Auswirkungen von zeitweiligen Fehlern.

Zu berücksichtigende Faktoren :

  • Idempotenz:Stellen Sie sicher, dass der wiederholte Vorgang idempotent ist. Das bedeutet, dass er ohne unbeabsichtigte Nebenwirkungen wiederholt werden kann.
  • Maximale Anzahl von Wiederholungsversuchen:Begrenzen Sie die Anzahl der Wiederholungsversuche (z.B. maximal 3), um Endlosschleifen zu vermeiden.
  • Schutzschaltungen:Integrieren Sie Wiederholungsversuche mit Schutzschaltungen, um Wiederholungsversuche zu verhindern, wenn ein Dienst ständig fehlschlägt.

Weitere Informationen finden Sie in der Istio-Dokumentation unter Neuversuche.

Zeitlimits

Mit Zeitlimits können Sie die maximale Zeit definieren, die für die Verarbeitung von Anfragen zulässig ist.

  • Wichtige Konfiguration:
    • timeout: Zeitlimit für Anfragen für einen bestimmten Dienst.
    • idleTimeout: Zeit, die eine Verbindung inaktiv bleiben kann, bevor sie geschlossen wird.
  • Vorteile:Verbesserte Systemreaktionsfähigkeit, Vermeidung von Ressourcenlecks, Schutz vor böswilligem Traffic.

Zu berücksichtigende Faktoren :

  • Netzwerklatenz:Berücksichtigen Sie die erwartete Umlaufzeit (Round-Trip Time, RTT) zwischen Diensten. Lassen Sie etwas Puffer für unerwartete Verzögerungen.
  • Dienstabhängigkeitsgraph:Bei verketteten Anfragen muss das Zeitlimit eines aufrufenden Dienstes kürzer sein als das kumulative Zeitlimit seiner Abhängigkeiten, um Fehlerkaskaden zu vermeiden.
  • Vorgangstypen:Für zeitaufwendige Aufgaben sind möglicherweise deutlich längere Zeitlimits erforderlich als für Datenabrufe.
  • Fehlerbehebung:Zeitlimits sollten eine entsprechende Fehlerbehandlungslogik auslösen (z.B. Wiederholungsversuch, Fallback, Schutzschaltung).

Weitere Informationen finden Sie in der Istio-Dokumentation unter Zeitlimits.

Überwachen und optimieren

Beginnen Sie mit den Standardeinstellungen für Zeitlimits, Ausreißererkennung und Wiederholungsversuche und passen Sie sie dann schrittweise an die spezifischen Anforderungen Ihres Dienstes und die beobachteten Trafficmuster an. Sehen Sie sich beispielsweise reale Daten dazu an, wie lange Ihre Dienste in der Regel für eine Antwort benötigen. Passen Sie dann die Zeitlimits an die spezifischen Merkmale der einzelnen Dienste oder Endpunkte an.

Telemetrie

Verwenden Sie Telemetrie, um Ihr Service Mesh kontinuierlich zu überwachen und die Konfiguration anzupassen, um Leistung und Zuverlässigkeit zu optimieren.

  • Messwerte:Verwenden Sie umfassende Messwerte, insbesondere Anfragevolumen, Latenz und Fehlerraten. Integrieren Sie Cloud Monitoring für Visualisierung und Benachrichtigungen.
  • Verteiltes Tracing: Aktivieren Sie die Integration des verteilten Tracing mit Cloud Trace, um detaillierte Einblicke in die Anfrageströme in Ihren Diensten zu erhalten.
  • Protokollierung: Konfigurieren Sie die Zugriffsprotokollierung , um detaillierte Informationen zu Anfragen und Antworten zu erfassen.

Weitere Informationen