Cloud Service Mesh でのトラフィック管理に関する問題の解決
このセクションでは、Cloud 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 のネットワーク名前空間に適用されていない場合に発生する可能性があります。次の原因が考えられます。
- istio-cni の不完全なインストール
- ワークロード Pod の権限が不十分(
CAP_NET_ADMIN
権限が付与されていない)
Istio CNI プラグインを使用している場合は、指示に完全に従っていることを確認します。istio-cni-node
コンテナの準備が完了していることを確認し、ログを確認します。問題が解決しない場合は、ホストノードにセキュアシェル(SSH)を確立し、ノードログで nsenter
コマンドを検索して、エラーの有無を確認します。
Istio CNI プラグインを使用していない場合は、ワークロード 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
アプリケーション ワークロードに再試行リクエスト メカニズムを追加します。
ゲートウェイのリスト取得で何も返されない
症状: Cloud Service Mesh のゲートウェイが正常に作成された後、kubectl get gateway --all-namespaces
を使用してゲートウェイのリストを取得しようとすると、No resources found
が返されます。
この問題は GKE 1.20 以降で発生する可能性があります。その理由は、GKE ゲートウェイ コントローラが自動的に GKE Gateway.networking.x-k8s.io/v1alpha1
リソースをクラスタにインストールするためです。この問題を回避する方法は次のとおりです。
クラスタ内に複数のゲートウェイ カスタム リソースがあるかどうかを確認します。
kubectl api-resources | grep gateway
出力例:
gateways gw networking.istio.io/v1beta1 true Gateway gatewayclasses gc networking.x-k8s.io/v1alpha1 false GatewayClass gateways gtw networking.x-k8s.io/v1alpha1 true Gateway
apiVersion
networking.istio.io/v1beta1
と記載されたゲートウェイ以外のエントリがリストに含まれる場合は、kubectl
コマンドで完全なリソース名または区別できる略称を使用します。たとえば、kubectl get gateway
の代わりにkubectl get gw
またはkubectl get gateways.networking.istio.io
を実行することによって、Istio ゲートウェイがリストに含まれるようになります。
この問題の詳細については、Kubernetes ゲートウェイと Istio ゲートウェイをご覧ください。