このセクションでは、Anthos Service Mesh の一般的な問題とその解決方法について説明します。さらにサポートが必要な場合は、サポートの利用をご覧ください。
Istiod ログの API サーバー接続エラー
次のようなエラーが発生した場合、Istiod は apiserver に接続できません。
error k8s.io/client-go@v0.18.0/tools/cache/reflector.go:125: Failed to watch *crd.IstioSomeCustomResource`…dial tcp 10.43.240.1:443: connect: connection refused
正規表現文字列 /error.*cannot list resource/ を使用すると、ログでこのエラーを見つけることができます。
通常、このエラーは一時的なものであり、kubectl を使用してプロキシのログに到達した場合は、問題がすでに解決されている可能性があります。このエラーは通常、アップグレードまたは自動スケーリングの変更のために高可用性構成内にない API サーバーが再起動した場合など、API サーバーを一時的に使用できなくなるイベントが原因で発生します。
istio-init コンテナがクラッシュする
この問題は、Pod の iptables ルールが Pod のネットワーク名前空間に適用されていない場合に発生する可能性があります。次の原因が考えられます。
- Pod のセキュリティ ポリシー（PSP）に過度の制限が適用されている
- istio-cni の不完全なインストール
- ワークロード Pod の権限が不十分（
CAP_NET_ADMIN権限が付与されていない）
CAP_NET_ADMIN 権限を制限する Pod セキュリティ ポリシーを使用している場合は、代わりに Istio CNI プラグインを使用するように切り替えてください。
Istio CNI プラグインを使用している場合は、指示に完全に従っていることを確認します。istio-cni-node コンテナの準備が完了していることを確認し、ログを確認します。問題が解決しない場合は、ホストノードにセキュアシェル（SSH）を確立し、ノードログで nsenter コマンドを検索して、エラーの有無を確認します。
Istio CNI プラグインまたは Pod セキュリティ ポリシーを使用しない場合は、ワークロード Pod に、サイドカー インジェクタによって自動的に設定された CAP_NET_ADMIN 権限が付与されていることを確認してください。
Pod の起動後に接続が拒否される
Pod が起動し、connection refused のエンドポイントへの接続を試行している場合は、isto-proxy コンテナよりも前にアプリケーション コンテナを起動した可能性があります。この例の場合、アプリケーション コンテナはリクエストを istio-proxy に送信していますが、istio-proxy はまだポートをリッスンしていないため、接続は拒否されます。
この場合は、次のことが可能です。
アプリケーションが 200 コードを受け取るまで、
istio-proxyhealth エンドポイントに継続的なリクエストを行うようにアプリケーションの起動コードを変更します。istio-proxyhealth エンドポイントは次のとおりです。http://localhost:15020/healthz/readyアプリケーション ワークロードに再試行リクエスト メカニズムを追加します。