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

In dieser Anleitung 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 den Cloud Service Mesh-Logs oder den 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.

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- und 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 dem horizontalen Pod-Autoscaling (HPA) können Sie Arbeitslasten dynamisch mit zusätzlichen Pods skalieren, basierend auf der Ressourcennutzung. 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 diesen Wert möglicherweise senken, wenn Sie schnellere Trafficspitzen erwarten. Weitere Informationen dazu, wann HPA mit der 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

Beachten 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 auch Standardressourcenlimits für alle Envoy-Proxys in Ihrem Mesh mit Ressourcen annotationen konfigurieren.

Die optimalen Ressourcenlimits für Ihre Envoy-Proxys hängen von Faktoren wie Trafficvolumen, Komplexität der Arbeitslast 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 eingrenzen, 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 Meshs von entscheidender Bedeutung.

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

Baumdiagramm mit vielen Blättern für den Traffic der Beispielanwendung „Online Boutique“

Viele dieser Dienste sind Blätter im Graphen und benötigen daher keine Egress-Informationen 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 Skalierbarkeit des Meshs 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 werden alle Envoy-Proxys in diesem Namespace angewiesen, nur Konfigurationen für Dienste im eigenen Namespace zu empfangen.

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 Stamm-Namespace anwenden, in der Regel „istio-system“.

Die folgende Sidecar-Ressource beschränkt den Egress-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.

Ü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 ständig an das Limit heranreicht oder es ü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 sollten Sie möglicherweise horizontal skalieren. Wenn der Sidecar-Proxy die Anfragen jedoch nicht so schnell wie der Anwendungscontainer verarbeiten kann, kann die Anpassung der CPU-Limits die besten Ergebnisse liefern.

  • Hohe Arbeitsspeicherauslastung:Wenn die Arbeitsspeicherauslastung von Envoy an das Limit heranreicht oder es ü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 Datenebenen-Proxys aktiv festlegen und überwachen, können Sie sicherstellen, dass Ihr Service Mesh in der GKE effizient skaliert.

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 ein Engpass für große Cluster sein, bei denen nicht alle Ressourcen überwacht werden müssen.

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 Ressourcen wie Backend-Dienste und Gruppen von Netzwerkendpunkten für Kubernetes-Ressourcen in Namespaces, die in discoverySelectors angegeben sind. Google Cloud

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

Resilienz einbauen

Sie können die folgenden Einstellungen anpassen, um die Resilienz in Ihr Service Mesh einzubauen:

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:Es wird ein fehlerfreier Satz von Hosts im Load-Balancing-Pool beibehalten.

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.
  • Arten von Vorgängen:Lang andauernde Aufgaben erfordern möglicherweise deutlich längere Zeitlimits als 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 jedes Dienstes oder Endpunkts 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 Tracings 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