このセクションでは、Anthos Service Mesh のサイドカー プロキシの一般的な問題とその解決方法について説明します。さらにサポートが必要な場合は、サポートの利用をご覧ください。
OOM イベントが原因で istio-proxy
コンテナが強制終了された
このセクションでは、istio-proxy
コンテナが SystemOOM
イベントによって強制終了されず、Kubernetes ノードが MemoryPressure
の状態でないことを前提としています。istio-proxy
サイドカー コンテナには、デフォルトでリソースの上限があります。istio プロキシ コンテナが 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
サイドカー コンテナのメモリ フットプリントを低減することです。デフォルトでは、すべてのサイドカー プロキシは、メッシュ内の他のワークロード インスタンスに到達するために必要な構成でプログラムされます。Istio は、カスタム リソース定義 Sidecar
によって、サイドカー プロキシにプログラミングされたエンドポイントの数を制限し、istio-proxy
コンテナのメモリ消費量を減らします。