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

In diesem Leitfaden werden Best Practices zum Beheben von Skalierungsproblemen für verwaltete Cloud Service Mesh-Architekturen in der Google Kubernetes Engine beschrieben. Das Hauptziel dieser Empfehlungen besteht darin, für Ihre wachsenden Mikroservice-Anwendungen eine optimale Leistung, Zuverlässigkeit und Ressourcennutzung zu gewährleisten.

Die Skalierbarkeit von Cloud Service Mesh in GKE hängt vom effizienten Betrieb 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 unterscheiden

In Cloud Service Mesh können Skalierungsprobleme entweder auf der Steuerungsebene oder auf der Datenebene auftreten. So können Sie feststellen, welche Art von Skalierungsproblem vorliegt:

Symptome von Skalierungsproblemen der Steuerungsebene

Langsame Diensterkennung: Es dauert lange, bis neue Dienste oder Endpunkte erkannt und verfügbar werden.

Konfigurationsverzögerungen:Änderungen an Regeln zur Verkehrsverwaltung oder Sicherheitsrichtlinien werden erst nach einer langen Zeit übernommen.

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

Fehler im Zusammenhang mit Traffic Director:In den Cloud Service Mesh-Logs oder den Steuerungsebenenmesswerten können Fehler auftreten, die auf Probleme mit der Konnektivität, der Ressourcenausschöpfung oder der API-Drosselung hinweisen.

Umfang der Auswirkungen:Probleme mit der Steuerebene wirken sich in der Regel auf das gesamte Mesh aus und beeinträchtigen die Leistung erheblich.

Symptome von Skalierungsproblemen auf Datenebene

Erhöhte Latenz bei der Kommunikation zwischen Diensten: Bei Anfragen an einen In-Mesh-Dienst treten eine höhere Latenz oder Zeitüberschreitungen auf, aber die CPU-/Speichernutzung 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 die Verkehrslast nicht bewältigen können.

Lokales Problem: Probleme auf der Datenebene wirken sich in der Regel auf bestimmte Dienste oder Arbeitslasten aus, je nach Traffic-Mustern und Ressourcennutzung der Envoy-Proxys.

Datenebene skalieren

Mit den folgenden Methoden können Sie die Datenebene skalieren:

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

Mit dem horizontalen Pod-Autoscaling (HPA) können Sie Arbeitslasten dynamisch mit zusätzlichen Pods skalieren, je nach Ressourcenauslastung. Beachten Sie beim Konfigurieren von HPA Folgendes:

  • Verwenden Sie den Parameter --horizontal-pod-autoscaler-sync-period, um kube-controller-manager, die Polling-Rate des HPA-Controllers anzupassen. Die Standardabfragerate beträgt 15 Sekunden. Sie können sie niedriger festlegen, wenn Sie schnellere Traffic-Spitzen erwarten. Weitere Informationen dazu, wann Sie HPAs mit GKE verwenden sollten, finden Sie unter Horizontales Pod-Autoscaling.

  • Das standardmäßige Skalierungsverhalten kann dazu führen, dass eine große Anzahl von Pods gleichzeitig bereitgestellt (oder beendet) wird, was zu einem Anstieg der Ressourcennutzung führen kann. Sie können Skalierungsrichtlinien verwenden, um die Rate zu begrenzen, mit der Pods bereitgestellt werden können.

  • Verwenden Sie EXIT_ON_ZERO_ACTIVE_CONNECTIONS, um zu verhindern, dass Verbindungen beim Skalieren beendet werden.

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

Envoy-Proxykonfiguration optimieren

Beachten Sie die folgenden Empfehlungen, um die Envoy-Proxy-Konfiguration zu optimieren:

Ressourcenlimits

Sie können Ressourcenanforderungen und ‑limits für Envoy-Sidecars in Ihren Pod-Spezifikationen definieren. So wird eine Ressourcenkonflikt verhindert und eine gleichbleibende Leistung sichergestellt.

Sie können auch standardmäßige Ressourcenlimits für alle Envoy-Proxys in Ihrem Mesh mithilfe von Ressourcenanmerkungen konfigurieren.

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

Wichtige Hinweise:

  • 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 das Abhängigkeitsdiagramm Ihres Meshes verkleinern, indem Sie alle Abhängigkeiten über die Sidecar API deklarieren. Dadurch werden die Größe und Komplexität der Konfiguration begrenzt, die an eine bestimmte Arbeitslast gesendet wird. Das ist bei größeren Meshes entscheidend.

Im folgenden Beispiel sehen Sie das Traffic-Diagramm für die Beispielanwendung der Onlineboutique.

Beispielanwendung „Online Boutique“ – Traffic-Grafikbaum mit vielen Blättern

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, um den Geltungsbereich der Sidecar-Konfiguration für diese untergeordneten Dienste einzuschränken, 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:
    -   "~/*"

Weitere Informationen zum Bereitstellen dieser Beispielanwendung finden Sie unter Beispielanwendung „Online Boutique“.

Ein weiterer Vorteil von Sidecar-Scopes ist die Reduzierung unnötiger DNS-Abfragen. Durch die Begrenzung von Dienstabhängigkeiten wird sichergestellt, dass ein Envoy-Sidecar nur DNS-Abfragen für Dienste stellt, mit denen es tatsächlich kommuniziert, anstatt für jeden Cluster im Service Mesh.

Bei groß angelegten Bereitstellungen, bei denen Probleme mit großen Konfigurationsgrößen in den Sidecars auftreten, wird für die Mesh-Skalierung dringend empfohlen, Dienstabhängigkeiten einzugrenzen.

Überwachen und optimieren

Nachdem Sie die anfänglichen 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 Arbeitsspeichernutzung zu überwachen und die Ressourcenlimits nach Bedarf anzupassen.

Um festzustellen, ob ein Envoy-Proxy erhöhte Ressourcenlimits benötigt, überwachen Sie den Ressourcenverbrauch bei typischen und Spitzenverkehrsbedingungen. Achten Sie auf Folgendes:

  • Hohe CPU-Auslastung:Wenn die CPU-Auslastung von Envoy konstant an das Limit herankommt oder es überschreitet, kann es zu Problemen bei der Verarbeitung von Anfragen kommen, was zu einer erhöhten Latenz oder zu abgelehnten Anfragen führt. Sie sollten das CPU-Limit erhöhen.

    In diesem Fall sollten Sie die horizontale Skalierung verwenden. Wenn der Sidecar-Proxy die Anfragen jedoch nicht so schnell wie der Anwendungscontainer verarbeiten kann, erzielen Sie mit der Anpassung der CPU-Limits möglicherweise die besten Ergebnisse.

  • Hohe Arbeitsspeichernutzung:Wenn die Arbeitsspeichernutzung von Envoy das Limit erreicht oder überschreitet, werden möglicherweise Verbindungen getrennt oder es kommt zu OOM-Fehlern (Out-of-Memory). Erhöhen Sie das Speicherlimit, um diese Probleme zu vermeiden.

  • Fehlerprotokolle:Prüfen Sie die Envoy-Protokolle auf Fehler im Zusammenhang mit der Ressourcenausschöpfung, z. B. Upstream-Verbindungsfehler, Trennung oder Zurücksetzen vor Headern oder zu viele geöffnete Dateien. Diese Fehler können darauf hinweisen, dass der Proxy mehr Ressourcen benötigt. Weitere Informationen zu Fehlern im Zusammenhang mit Skalierungsproblemen finden Sie in der Dokumentation zur Fehlerbehebung bei der Skalierung.

  • Leistungsmesswerte:Hier können Sie wichtige Leistungsmesswerte wie die Latenz von Anfragen, Fehlerraten und den Durchsatz beobachten. Wenn Sie eine Leistungsverschlechterung feststellen, die mit einer hohen Ressourcennutzung zusammenhängt, müssen Sie die Limits möglicherweise erhöhen.

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

Resilienz aufbauen

Sie können die folgenden Einstellungen anpassen, um die Steuerungsebene zu skalieren:

Ausreißererkennung

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

  • Schlüsselkonfiguration:
    • outlierDetection: Einstellungen, die die Bereinigung von fehlerhaften Hosts aus dem Load-Balancing-Pool steuern.
  • Vorteile:Es wird dafür gesorgt, dass sich im Load Balancing-Pool eine fehlerfreie Gruppe von Hosts befindet.

Weitere Informationen finden Sie in der Istio-Dokumentation unter Außergewöhnliche Werte erkennen.

Neuversuche

Sie können vorübergehende Fehler minimieren, indem Sie fehlgeschlagene Anfragen automatisch noch einmal versuchen.

  • Schlüsselkonfiguration:
    • attempts: Anzahl der Wiederholungsversuche.
    • perTryTimeout: Zeitlimit pro Wiederholungsversuch. Legen Sie einen kürzeren Wert als das Gesamtzeitlimit fest. Damit wird festgelegt, wie lange Sie bei jedem einzelnen Wiederholungsversuch warten.
    • retryBudget: Maximale Anzahl gleichzeitiger Wiederholungen.
  • Vorteile:Höhere Erfolgsraten für Anfragen, geringere Auswirkungen von sporadischen Fehlern.

Zu berücksichtigende Faktoren:

  • Idempotency: Der Vorgang, der wiederholt werden soll, muss idempotent sein, d. h., er kann ohne unbeabsichtigte Nebenwirkungen wiederholt werden.
  • Max. Wiederholungen:Begrenzen Sie die Anzahl der Wiederholungen (z. B. auf maximal drei), um Endlosschleifen zu vermeiden.
  • Schutzschalter: Integrieren Sie Wiederholungen in Schutzschalter, um Wiederholungen zu verhindern, wenn ein Dienst wiederholt fehlschlägt.

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

Zeitlimits

Mit Zeitüberschreitungen können Sie die maximale Zeit für die Anfrageverarbeitung festlegen.

  • Schlüsselkonfiguration:
    • timeout: Zeitüberschreitung bei Anfrage für einen bestimmten Dienst.
    • idleTimeout: Zeit, in der eine Verbindung inaktiv bleiben kann, bevor sie geschlossen wird.
  • Vorteile: Verbesserte Systemreaktionsfähigkeit, Verhinderung von Ressourcenlecks, Härtung gegen schädlichen Traffic.

Zu berücksichtigende Faktoren:

  • Netzwerklatenz:Berücksichtigen Sie die erwartete Umlaufzeit (Round-Trip-Time, RTT) zwischen den Diensten. Lassen Sie einen Puffer für unerwartete Verzögerungen.
  • Dienstabhängigkeitsdiagramm:Bei verketteten Anfragen muss das Zeitlimit eines aufrufenden Dienstes kürzer sein als das kumulative Zeitlimit seiner Abhängigkeiten, um kaskadierende Fehler zu vermeiden.
  • Art der Vorgänge:Für lang andauernde Aufgaben sind möglicherweise deutlich längere Zeitüberschreitungen erforderlich als für die Datenabfrage.
  • Fehlerbehandlung:Timeouts sollten die entsprechende Fehlerbehandlungslogik auslösen (z.B. Wiederholung, Fallback, Schutzschalter).

Weitere Informationen finden Sie in der Istio-Dokumentation unter Zeitüberschreitungen.

Überwachen und optimieren

Beginnen Sie mit den Standardeinstellungen für Zeitüberschreitungen, Ausreißererkennung und Wiederholungen und passen Sie sie dann nach und nach an Ihre spezifischen Dienstanforderungen und beobachteten Traffic-Muster an. Sehen Sie sich beispielsweise an, wie lange Ihre Dienste in der Regel für eine Antwort benötigen. Passen Sie dann die Zeitüberschreitungen an die spezifischen Merkmale der einzelnen Dienste oder Endpunkte an.

Telemetrie

Verwenden Sie Telemetry, 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. Einbindung in Cloud Monitoring für Visualisierung und Benachrichtigungen.
  • Verteiltes Tracing:Aktivieren Sie die Einbindung des verteilten Tracings in Cloud Trace, um detaillierte Informationen zu den Anfrageflüssen in Ihren Diensten zu erhalten.
  • Logging:Konfigurieren Sie das Zugriffs-Logging, um detaillierte Informationen zu Anfragen und Antworten zu erfassen.

Weitere Informationen