Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Probleme mit Sidecar-Proxys in Cloud Service Mesh beheben
In diesem Abschnitt werden häufig auftretende Probleme mit Cloud Service Mesh-Sidecar-Proxys und deren Behebung erläutert.
Weitere Informationen finden Sie unter Support.
Der istio-proxy-Container wurde aufgrund eines OOM-Ereignisses beendet
In diesem Abschnitt wird davon ausgegangen, dass der Container istio-proxy nicht von einem SystemOOM-Ereignis beendet wird und sich der Kubernetes-Knoten nicht in der Bedingung MemoryPressure befindet.
Für den Sidecar-Container istio-proxy gelten standardmäßig Ressourcenlimits.
Wenn der „istio-proxy”-Container mit Reason: OOMKilled beendet wird, müssen Sie wissen, warum Envoy den Speicher beansprucht.
Bei einem Produktionsausfall können Sie die Limits für alle Container mit IstioOperator schnell erhöhen:
Wenn dieses Problem bei bestimmten Arbeitslasten auftritt, können Sie das Limit nur für diese Arbeitslasten ändern. Fügen Sie dazu die folgenden Annotationen hinzu.
sidecar.istio.io/proxyMemory
sidecar.istio.io/proxyMemoryLimit
Achten Sie darauf, dass keines der Limits niedriger ist als der Standardwert.
Die langfristige Lösung besteht darin, den Arbeitsspeicherbedarf Ihrer istio-proxy-Sidecar-Container zu reduzieren. Standardmäßig sind alle Sidecar-Proxys mit der erforderlichen Konfiguration programmiert, um eine beliebige andere Arbeitslastinstanz im Mesh zu erreichen.
Istio bietet die benutzerdefinierte Ressourcendefinition Sidecar, um die Anzahl der auf Sidecar-Proxys programmierten Endpunkte zu begrenzen und damit den Speicherverbrauch des istio-proxy-Containers zu reduzieren.
[[["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 sidecar proxies issues in Cloud Service Mesh\n======================================================\n\nThis section explains common Cloud Service Mesh sidecar proxies problems and how to\nresolve them.\nIf you need additional assistance, see [Getting support](/service-mesh/v1.25/docs/getting-support).\n\nThe `istio-proxy` container is killed because of a OOM event\n------------------------------------------------------------\n\nIn this section we assume that the `istio-proxy` container is not killed by a\n`SystemOOM` event, and the kubernetes node is not in `MemoryPressure` condition.\nThe `istio-proxy` sidecar container has by default [resource limits](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits).\nIf the istio-proxy container gets killed with `Reason: OOMKilled` it is necessary\nto understand why Envoy is consuming the memory.\n\nIf you are facing a production outage, a quick workaround is to raise the limits\nfor all containers using `IstioOperator`: \n\n ---\n apiVersion: install.istio.io/v1alpha1\n kind: IstioOperator\n spec:\n values:\n global:\n proxy:\n resources:\n requests:\n memory: 128Mi\n limits:\n memory: 1Gi\n\nIf you are facing this issue with specific workloads, you can change the limit\njust on those workloads by adding the following\n[annotations](https://istio.io/v1.24/docs/reference/config/annotations/).\n\n- `sidecar.istio.io/proxyMemory`\n- `sidecar.istio.io/proxyMemoryLimit`\n\nPlease make sure you don't have limits that are lower of the default values.\n| **Note:** because this container is injected at the Pod creation, this setting will be effective only for newly created Pods.\n\nThe long term solution is to reduce the memory footprint of your `istio-proxy`\nsidecar containers. By default all sidecar proxies are programmed with the\nnecessary configuration to reach any other workload instance in the mesh.\nIstio provides the [custom resource definition `Sidecar`](https://istio.io/v1.24/docs/reference/config/networking/sidecar/)\nto limit the number of endpoints programmed to sidecar proxies, and therefore\nreduce the memory consumption of the `istio-proxy` container."]]
