Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Skalierungsprobleme in Cloud Service Mesh beheben
In diesem Abschnitt werden häufig auftretende Cloud Service Mesh-Probleme und deren Behebung erläutert. Weitere Informationen finden Sie unter Support.
Skalierungsfaktoren
Istiod sendet die Konfiguration mithilfe eines langlebigen gRPC-Streams an jede Sidecar-Datei. Sie hat mehrere Merkmale, die sich auf die Skalierung auswirken:
Die Größe der zu generierenden Konfiguration:
Gesamtzahl der Dienste/Pods und Istio-Ressourcen.
Passen Sie bei der Verwendung von Istiod im großen Maßstab die Einstellungen für die Sidecar-Datei an, um die Konfiguration zu verkleinern.
Die Änderungsrate in der Umgebung:
Wenn ein neuer Dienst erstellt oder die Istio-Konfiguration geändert wird, werden vollständige Aktualisierungen an Proxys gesendet.
Das Hinzufügen neuer Endpunkte beeinträchtigt die Leistung nur wenig, da nur inkrementelle Aktualisierungen gesendet werden.
Die Anzahl der Proxys, für die eine Konfiguration generiert wird:
Wird von der Anzahl der Gateways und Pods mit einer Sidecar-Datei beeinflusst.
Aspekte bei der Skalierung
Istiod lässt sich gut skalieren, sowohl vertikal (große Anfragen) als auch horizontal (mehr Replikate). Achten Sie darauf, dass die CPU-Limits nicht zu restriktiv sind. Wenn Istiod das CPU-Limit erreicht, kann eine Drosselung auftreten, was sich negativ auf die Konfigurationsverteilung auswirkt. Bei Leistungsproblemen sollten Sie eventuell ein Upgrade auf die neueste Version von Cloud Service Mesh durchführen, da jede Version Leistungsoptimierungen beinhaltet.
Große Änderungen der Clustergröße können aufgrund der langlebigen Verbindungen eine vorübergehend unausgeglichene Last verursachen. Dieses Problem wird durch ein maximales Verbindungsalter von 30 Minuten abgemildert, was eventuell Fehlermeldungen in Envoy verursacht (z. B. gRPC config stream
closed: 13), wodurch die Last auf natürliche Weise wieder ausgeglichen werden kann.
Sie können dieses Problem auch abmildern, indem Sie mehrere Replikate von Istiod verwenden (Standardeinstellung ist 2 Replikate) und eine Vorskalierung durchführen, wenn Sie extreme vertikale Skalierungen erwarten.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-08-19 (UTC)."],[],[],null,["# Resolving scaling issues in Cloud Service Mesh\n==============================================\n\n| **Note:** This guide only supports Cloud Service Mesh with Istio APIs and does not support Google Cloud APIs. For more information see, [Cloud Service Mesh overview](/service-mesh/v1.25/docs/overview).\n\nThis section explains common Cloud Service Mesh problems and how to resolve\nthem. If you need additional assistance, see\n[Getting support](/service-mesh/v1.25/docs/getting-support).\n\nScaling factors\n---------------\n\n[Istiod](https://istio.io/v1.24/blog/2020/istiod/)\nsends configuration to each sidecar using a long-lived gRPC stream. It has\nseveral characteristics that affect scaling:\n\n- The size of the configuration to generate:\n - Total number of services/pods \\& Istio resources\n - For large scale, adjust settings for the [Sidecar](https://istio.io/v1.24/docs/reference/config/networking/sidecar/) to reduce the configuration size.\n- The rate of change in the environment:\n - When a new service is created or the Istio configuration is changed, full updates are sent to proxies.\n - Adding new endpoints is inexpensive for performance, because only incremental updates are sent.\n- The number of proxies for which configuration is generated:\n - Affected by the number of gateways and pods with a sidecar.\n\nScaling considerations\n----------------------\n\nIstiod scales well vertically (large requests) and horizontally (more\nreplicas). Ensure that your CPU limits are not too restrictive; if Istiod\nreaches the CPU limit, throttling may occur which will negatively affect\nconfiguration distribution. If you encounter performance issues, consider\nupgrading to the latest version of Cloud Service Mesh, as each version has\nperformance optimizations.\n\nFor more guidance on scaling your mesh, see the\n[Scalability best practices guide](/service-mesh/v1.25/docs/operate-and-maintain/scalability-best-practices).\n\nUnbalanced load\n---------------\n\nLarge changes in cluster size might cause a temporarily unbalanced load, due to\nthe long-lived connections. This is mitigated by a 30 minute maximum connection\nage, which might result in error messages in Envoy, such as `gRPC config stream\nclosed: 13`, which allows the load to naturally rebalance.\n\nMitigate this issue by having multiple replicas of Istiod (the default is 2\nreplicas), and pre-scaling if you expect extreme cluster scale-ups."]]
