Anthos Service Mesh でのトラフィック管理に関する問題の解決

このセクションでは、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-proxy health エンドポイントに継続的なリクエストを行うようにアプリケーションの起動コードを変更します。istio-proxy health エンドポイントは次のとおりです。

    http://localhost:15020/healthz/ready
    
  • アプリケーション ワークロードに再試行リクエスト メカニズムを追加します。