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

{default_version.


%20%20%20%E7%99%E7%97%90%E7%99%9%E8%E%E7%9F%B1%20%20%20%E4%E2%E7%9B%21%20%20%E2B%E2%E7%97%20%20%23%24%23%20%E7%E7%E7%97%23%23%21%21%21%21%20%23%2023 及{3}B2B{3} V3" "%1" "%20%1" "%20%1" "%21%20%10 吗%20%20%10808083223%23%23 中为什么%2B2 解释 {/2}

本部分介绍常见的 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 容器的内存消耗。