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