解决 Cloud Service Mesh 中的 Sidecar 代理问题

本部分介绍常见的 Cloud Service Mesh Sidecar 代理问题以及如何解决 并加以解决。 如果您需要其他帮助，请参阅获取支持。

由于 OOM 事件，istio-proxy 容器被终止

在本部分中，我们假设 istio-proxy 容器未被 SystemOOM 事件终止，并且 kubernetes 节点不在 MemoryPressure 条件中。istio-proxy Sidecar 容器默认具有资源限制。如果 istio-proxy 容器使用 Reason: OOMKilled 终止，则必须了解 Envoy 耗用内存的原因。

如果您遇到生产环境服务中断，一种快速解决方法是提高使用 IstioOperator 的所有容器的限制：

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

如果您遇到特定工作负载方面的问题，只需添加以下注释，即可更改针对这些工作负载的限制。

  • sidecar.istio.io/proxyMemory
  • sidecar.istio.io/proxyMemoryLimit

请确保您的限制不会低于默认值。

长期解决方案是减少 istio-proxy Sidecar 容器的内存占用。默认情况下，所有 Sidecar 代理都会使用必要的配置进行编程，以访问网格中的任何其他工作负载实例。Istio 提供自定义资源定义 Sidecar 来限制编程到 Sidecar 代理的端点数量， 减少 istio-proxy 容器的内存消耗量。