Probleme mit Sidecar-Proxys in Cloud Service Mesh beheben

In diesem Abschnitt werden häufige Probleme mit Cloud Service Mesh-Sidecar-Proxys erläutert. Außerdem erfahren Sie, wie Sie und sie zu lösen. 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:

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  values:
    global:
      proxy:
        resources:
          requests:
               memory: 128Mi
          limits:
               memory: 1Gi

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.