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