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 リソースをクラスタにインストールするためです。この問題を回避する方法は次のとおりです。

  1. クラスタ内に複数のゲートウェイ カスタム リソースがあるかどうかを確認します。

    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

  2. apiVersion networking.istio.io/v1beta1 と記載されたゲートウェイ以外のエントリがリストに含まれる場合は、kubectl コマンドで完全なリソース名または区別できる略称を使用します。たとえば、kubectl get gateway の代わりに kubectl get gw または kubectl get gateways.networking.istio.io を実行することによって、Istio ゲートウェイがリストに含まれるようになります。

この問題の詳細については、Kubernetes ゲートウェイと Istio ゲートウェイをご覧ください。