Cloud Service Mesh でサイドカー プロキシの問題を解決する

このセクションでは、Cloud 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 コンテナのメモリ消費量を減らします。