このセクションでは、Anthos Service Mesh の一般的な問題とその解決方法について説明します。さらにサポートが必要な場合は、サポートの利用をご覧ください。
Anthos Service Mesh のリソース制限の問題は、次のいずれかが原因で発生します。
istio-system名前空間、または自動サイドカー インジェクションが有効になっている名前空間で作成されたLimitRangeオブジェクト。- ユーザー定義の制限が小さすぎる。
- ノードでメモリまたはリソースが不足している。
リソースの問題の潜在的な症状:
- エラー
Envoy proxy NOT readyが発生し、Anthos Service Mesh がistiodから構成を受信できない状態が繰り返し発生する。このエラーが起動時に表示された場合は問題ありません。これは正常な状態です。ただし、それ以外の場合は問題です。 - ネットワークの問題で Pod またはノードに接続できない。
- 出力に
STALEステータスを示すistioctl proxy-statusが含まれている。 - ノードのログに
OOMKilledメッセージが記録されている。 - コンテナによるメモリ使用量:
kubectl top pod POD_NAME --containers - ノード内の Pod によるメモリ使用量:
kubectl top node my-node - Envoy のメモリ:
kubectl get podsの出力にステータスOOMKilledが含まれている。
Istio サイドカーでの構成の受信に長い時間がかかる
istiod に割り当てられたリソースが不足しているか、クラスタサイズが非常に大きいため、構成の伝播が遅くなることがあります。
この問題には、次のような解決方法が考えられます。
モニタリング ツール（prometheus、Stackdriver など）で
istiodによるリソース使用率が高い場合は、そのリソースの割り当てを増やします。たとえば、istiodデプロイの CPU やメモリ上限を増やします。これは一時的な解決策であるため、リソース消費量を抑える方法を検討することをおすすめします。この問題が大規模なクラスタやデプロイで発生している場合は、サイドカー リソースを構成することで、各プロキシに push される構成状態の量を減らします。
問題が解決しない場合は、
istiodを水平にスケーリングしてみてください。他のトラブルシューティングの手順をすべて行っても問題が解決しない場合は、デプロイと発生した問題の詳細を記載したバグを報告します。こちらの手順に沿って、CPU / メモリ プロファイルをバグレポートに追加します。可能であれば、クラスタサイズ、Pod の数、サービスの数などの詳細も追加します。