解决 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 容器的内存消耗量。