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

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

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

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

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