次の方法で共有

Istio サービス メッシュ アドオンイングレス ゲートウェイのトラブルシューティング

  • [アーティクル]

この記事では、Azure Kubernetes Service (AKS) の Istio サービス メッシュ アドオンに関する ingress ゲートウェイ の問題をトラブルシューティングする方法について説明します。 Istio イングレス ゲートウェイは Envoy ベースのリバース プロキシであり、受信トラフィックをメッシュ内のワークロードにルーティングするために使用できます。

Istio ベースのサービス メッシュ アドオンには、次のイングレス ゲートウェイ オプションが用意されています。

  • プライベート IP アドレスを使用する内部イングレス ゲートウェイ。

  • パブリックにアクセス可能な IP アドレスを使用する外部イングレス ゲートウェイ。

Note

Microsoft では、内部または外部のイングレス ゲートウェイの IP アドレスのカスタマイズはサポートされていません。 Istio サービス メッシュ アドオンに対する IP カスタマイズの変更はすべて元に戻されます。

アドオンは、リビジョンごとに Istio イングレス ゲートウェイ ポッドとデプロイをデプロイします。 カナリア アップグレードを実行していてクラスターに 2 つのコントロール プレーン リビジョンがインストールされている場合は、両方のリビジョンにわたって複数のイングレス ゲートウェイ ポッドのトラブルシューティングが必要になる場合があります。

トラブルシューティングのチェックリスト

手順 1: ファイアウォールまたは NSG 規則によってイングレス ゲートウェイがブロックされていないことを確認する

受信ゲートウェイへのトラフィックをブロックするファイアウォールまたは Network セキュリティ グループ (NSG) 規則 がないことを確認します。 受信トラフィックを する宛先ネットワーク アドレス変換 (DNAT) 規則を明示的に追加し Azure Firewall 経由でイングレス ゲートウェイに追加する必要があります。

手順 2: ゲートウェイ、仮想サービス、および宛先ルールを正しく構成する

イングレス ゲートウェイ経由のトラフィック ルーティング用にゲートウェイ、仮想サービス、および宛先ルールを構成する場合は、次の手順に従います。

  1. 外部ゲートウェイまたは内部ゲートウェイをそれぞれ使用している場合は、ゲートウェイ リソースのイングレス ゲートウェイ セレクターが次のいずれかのテキスト値に設定されていることを確認します。

    • istio: aks-istio-ingressgateway-external
    • istio: aks-istio-ingressgateway-internal

  2. ゲートウェイと仮想サービスでポートが正しく設定されていることを確認します。 ゲートウェイの場合、ポートはhttpの場合は80、httpsの場合は443に設定する必要があります。 仮想サービスの場合、ポートは、アプリケーションの対応するサービスがリッスンしているポートに設定する必要があります。

  3. ゲートウェイと仮想サービスの両方の hosts 仕様内でサービスが公開されていることを確認します。 要求で Host ヘッダーに関連する問題が発生した場合は、この サンプル ゲートウェイ構成など、アスタリスク ワイルドカード ("*") を含むすべてのホストを許可リストに追加してみてください。 ただし、運用プラクティスとして許可リストを修正しないことをお勧めします。 また、 hosts 仕様は明示的に 構成する必要があります。

手順 3: イングレス ゲートウェイ ポッドの正常性を修正する

イングレス ゲートウェイ ポッドがクラッシュした場合、または準備完了状態に表示されない場合は、Istio デーモン (istiod) コントロール プレーン ポッドが準備完了状態であることを確認します。 イングレス ゲートウェイは、 istiod リリースの準備ができているかによって異なります。

istiod ポッドが準備完了状態で表示されない場合は、Istio カスタム リソース定義 (CRD) と base Helm チャートが正しくインストールされていることを確認します。 そのためには、次のコマンドを実行します。

helm ls --all --all-namespaces

アドオンのインストールがイングレス ゲートウェイに対して特別に構成されていない、より広範なエラーが表示される場合があります。

istiod ポッドが正常であっても、イングレス ゲートウェイ ポッドが応答していない場合は、aks-istio-ingress名前空間の次のイングレス ゲートウェイ リソースを調べて、詳細情報を収集します。

  • Helm リリース
  • 展開
  • Service

さらに、ゲートウェイとサイドカーのデバッグの詳細については、 General Istio サービス メッシュ アドオンのトラブルシューティングを参照してください。

手順 4: リソース使用率を構成する

リソース使用率が高い場合は、Istiod の既定の最小/最大レプリカ設定が十分でない場合に発生します。 この場合は、 horizontal ポッドの自動スケール 構成を変更します。

手順 5: セキュリティで保護されたイングレス ゲートウェイのトラブルシューティング

単純な TLS または相互 TLS を使用してセキュリティで保護された HTTPS サービスを公開するように 外部イングレス ゲートウェイが構成されている場合次のトラブルシューティング手順に従います。

  1. 次のコマンドの出力に基づいて、 INGRESS_HOST_EXTERNAL 環境変数と SECURE_INGRESS_PORT_EXTERNAL 環境変数の値が有効であることを確認します。

    kubectl -n aks-istio-ingress get service aks-istio-ingressgateway-external

  2. ゲートウェイ コントローラーのログでエラー メッセージを確認します。

    kubectl logs -n aks-istio-ingress <gateway-service-pod>

  3. シークレットが aks-istio-ingress 名前空間に作成されていることを確認します。

    kubectl -n aks-istio-ingress get secrets

Azure Kubernetes Service 用の Istio サービス メッシュ アドオンの Secure イングレス ゲートウェイの例、 productpage-credential シークレットを一覧表示する必要があります。

Azure Key Vault シークレット プロバイダー アドオンを有効にしたら、アドオンのユーザー割り当てマネージド ID へのアクセス権を Azure Key Vault に付与する必要があります。 Azure Key Vault へのアクセスを正しく設定しないと、 productpage-credential シークレットが作成されなくなります。

SecretProviderClass リソースを作成した後、シークレットが Azure Key Vault からクラスターに同期されるようにするには、このリソースを参照するサンプル ポッド secrets-store-sync-productpageが正常にデプロイされていることを確認します。

関連情報

サードパーティの情報に関する免責事項

この資料に記載されているサードパーティ製品は、マイクロソフトと関連のない他社の製品です。 明示的か黙示的かにかかわらず、これらの製品のパフォーマンスや信頼性についてマイクロソフトはいかなる責任も負わないものとします。

サードパーティのお問い合わせ窓口に関する免責事項

サードパーティのお問い合わせ窓口に関する情報は、ユーザーの便宜のために提供されているものであり、 この連絡先情報は、予告なしに変更される可能性があります。 マイクロソフトは、掲載されている情報に対して、いかなる責任も負わないものとします。

お問い合わせはこちらから

質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。