Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Probleme mit Ressourcenlimits 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.
Probleme mit Cloud Service Mesh-Ressourcenlimits können folgende Ursachen haben:
LimitRange-Objekte, die im Namespace istio-system oder in einem beliebigen Namespace mit aktivierter automatischer Sidecar-Einfügung erstellt wurden
Zu niedrige benutzerdefinierte Limits
Knoten mit einem Mangel an freiem Arbeitsspeicher oder anderen Ressourcen
Mögliche Symptome bei Ressourcenproblemen:
Cloud Service Mesh empfängt wiederholt keine Konfiguration von der Steuerungsebene, was durch den Fehler Envoy proxy NOT ready angezeigt wird. Wenn Sie diesen Fehler einige Male beim Start sehen, ist das normal. Ansonsten ist es jedoch ein Problem.
Netzwerkprobleme bei einigen Pods oder Knoten, die nicht mehr erreichbar sind.
Für istioctl proxy-status wird in der Ausgabe der Status STALE angezeigt.
OOMKilled-Nachrichten in den Logs eines Knotens.
Arbeitsspeichernutzung durch Container: kubectl top pod POD_NAME --containers.
Arbeitsspeichernutzung durch Pods in einem Knoten: kubectl top node my-node.
Nicht genügend Arbeitsspeicher: Für kubectl get pods wird in der Ausgabe der Status OOMKilled angezeigt.
Sidecars benötigen sehr lange, um die Konfiguration zu erhalten
Eine langsame Konfigurationsweitergabe kann auf unzureichende Ressourcen zurückzuführen sein, die istiod zugewiesen sind oder zu viel Cluster enthalten.
Es gibt mehrere Lösungsansätze für dieses Problem:
Wenn Ihre Monitoringtools (prometheus, stackdriver usw.) für das In-Cluster-Cloud Service Mesh eine hohe Auslastung einer Ressource von istiod zeigen, erhöhen Sie die Zuweisung dieser Ressource, beispielsweise um das CPU- oder Arbeitsspeicherlimit der istiod-Bereitstellung zu erhöhen. Dies ist eine temporäre Lösung. Wir empfehlen Ihnen, Methoden zur Reduzierung des Ressourcenverbrauchs zu überprüfen.
Wenn dieses Problem in einem großen Cluster oder Deployment auftritt, reduzieren Sie den Konfigurationsstatus, der an jeden Proxy gesendet wird, indem Sie Sidecar-Ressourcen konfigurieren.
Wenn das Problem bei einem clusterinternen Cloud Service Mesh weiterhin besteht, versuchen Sie, istiod horizontal zu skalieren.
Sollten Sie auch alle anderen Schritte zur Fehlerbehebung ausführen, melden Sie einen Programmfehler, der das Deployment beschreibt, und die beobachteten Probleme. Gehen Sie so vor und fügen Sie nach Möglichkeit ein CPU-/Speicherprofil in den Fehlerbericht ein, zusammen mit einer detaillierten Beschreibung der Clustergröße, der Anzahl der Pods und der Anzahl der Dienste.
[[["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-18 (UTC)."],[],[],null,["# Resolving resource limit issues in Cloud Service Mesh\n=====================================================\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\nCloud Service Mesh resource limit problems can be caused by any of the\nfollowing:\n\n- `LimitRange` objects created in the `istio-system` namespace or any namespace with automatic sidecar injection enabled.\n- User-defined limits that are set too low.\n- Nodes run out of memory or other resources.\n\nPotential symptoms of resource problems:\n\n- Cloud Service Mesh repeatedly not receiving configuration from the control plane indicated by the error, `Envoy proxy NOT ready`. Seeing this error a few times at startup is normal, but otherwise it is a concern.\n- Networking problems with some pods or nodes that become unreachable.\n- `istioctl proxy-status` showing `STALE` statuses in the output.\n- `OOMKilled` messages in the logs of a node.\n- Memory usage by containers: `kubectl top pod POD_NAME --containers`.\n- Memory usage by pods inside a node: `kubectl top node my-node`.\n- Envoy out of memory: `kubectl get pods` shows status `OOMKilled` in the output.\n\nSidecars take a long time to receive configuration\n--------------------------------------------------\n\nSlow configuration propagation can occur due to insufficient resources allocated\nto `istiod` or an excessively large cluster size.\n\nThere are several possible solutions to this problem:\n\n1. For in-cluster Cloud Service Mesh, if your monitoring tools (prometheus,\n stackdriver, etc.) show high utilization of a resource by `istiod`, increase\n the allocation of that resource, for example increase the CPU or memory limit\n of the `istiod` deployment. This is a temporary solution and we recommended\n that you investigate methods for reducing resource consumption.\n\n2. If you encounter this issue in a large cluster or deployment, reduce the\n amount of configuration state pushed to each proxy by configuring\n [Sidecar resources](https://istio.io/v1.24/docs/reference/config/networking/sidecar/).\n\n3. For in-cluster Cloud Service Mesh, if the problem persists, try\n horizontally scaling `istiod`.\n\n4. If all other troubleshooting steps fail to resolve the problem, report a bug\n detailing your deployment and the observed problems. Follow\n [these steps](https://github.com/istio/istio/wiki/Analyzing-Istio-Performance)\n to include a CPU/Memory profile in the bug report if possible, along with a\n detailed description of cluster size, number of pods, and number of services."]]
