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

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

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

  • istio-system 名前空間、または自動サイドカー インジェクションが有効になっている名前空間で作成された 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 に割り当てられたリソースが不足しているか、クラスタサイズが非常に大きいため、構成の伝播が遅くなることがあります。

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

  1. クラスタ内 Cloud Service Mesh で、モニタリング ツール（prometheus、Stackdriver など）で istiod によるリソース使用率が高い場合は、そのリソースの割り当てを増やします。たとえば、istiod デプロイの CPU やメモリ上限を増やします。これは一時的な解決策であるため、リソース消費量を抑える方法を検討することをおすすめします。

  2. この問題が大規模なクラスタやデプロイで発生している場合は、サイドカー リソースを構成することで、各プロキシに push される構成状態の量を減らします。

  3. クラスタ内 Cloud Service Mesh で問題が解決しない場合は、istiod を水平にスケーリングしてみてください。

  4. 他のトラブルシューティングの手順をすべて行っても問題が解決しない場合は、デプロイと発生した問題の詳細を記載したバグを報告します。こちらの手順に沿って、CPU / メモリ プロファイルをバグレポートに追加します。可能であれば、クラスタサイズ、Pod の数、サービスの数などの詳細も追加します。