Cloud Service Mesh でのリソース制限の問題の解決

このセクションでは、Cloud Service Mesh の一般的な問題とその解決方法について説明します。さらにサポートが必要な場合は、サポートの利用をご覧ください。

Cloud Service Mesh のリソース制限の問題は、次のいずれかが原因で発生します。

istio-system Namespace、または自動サイドカーインジェクションが有効になっている Namespace で作成された LimitRange オブジェクト。
ユーザー定義の制限が小さすぎる。
ノードでメモリまたはリソースが不足している。

リソースの問題の潜在的な症状:

エラー Envoy proxy NOT ready が表示され、Cloud Service Mesh がコントロールプレーンから構成を受信できない状態が繰り返し発生する。このエラーが起動時に数回表示されるのは正常な状態ですが、それ以外の場合は問題です。
ネットワークの問題で Pod またはノードに接続できない。
出力に STALE ステータスを示す istioctl proxy-status が含まれている。
ノードのログに OOMKilled メッセージが記録されている。
コンテナによるメモリ使用量: kubectl top pod POD_NAME --containers
ノード内の Pod によるメモリ使用量: kubectl top node my-node
Envoy のメモリ不足: kubectl get pods の出力にステータス OOMKilled が含まれている。

サイドカーでの構成の受信に長い時間がかかる

istiod に割り当てられたリソースが不足しているか、クラスタサイズが非常に大きい場合、構成の伝播が遅くなることがあります。

この問題には、次のような解決方法が考えられます。

クラスタ内 Cloud Service Mesh において、モニタリングツール（prometheus、Stackdriver など）で istiod によるリソース使用率が高い場合は、そのリソースの割り当てを増やします。たとえば、istiod Deployment の CPU やメモリの上限を増やします。これは一時的な解決策であるため、リソース消費量を抑える方法を検討することをおすすめします。
この問題が大規模なクラスタや Deployment で発生している場合は、サイドカーリソースを構成することで、各プロキシに push される構成状態の量を減らします。
クラスタ内 Cloud Service Mesh で問題が解決しない場合は、istiod を水平にスケーリングしてみてください。
他のトラブルシューティングの手順をすべて行っても問題が解決しない場合は、Deployment と発生した問題の詳細を記載したバグを報告します。こちらの手順に沿って、CPU / メモリプロファイルをバグレポートに追加します。可能であれば、クラスタサイズ、Pod の数、Service の数などの詳細も追加します。