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

まとめ

この記事では、イングレス トラフィック ルーティングの問題をすばやく解決できるように、Azure Kubernetes Service (AKS)での Istio サービス メッシュ アドオン ゲートウェイ API イングレスのトラブルシューティングについて説明します。

従来の Istio イングレス ゲートウェイと同様に、Istio アドオンのゲートウェイ API ベースのイングレス ゲートウェイは、Envoy ベースのリバース プロキシです。 ゲートウェイ API ベースのイングレスに Istio アドオンを使用するには、クラスターに AKS Managed Gateway API CRD をインストールする必要があります。

トラブルシューティングの前に

続行する前に、次のアクションを実行します。

  • クラスターに Managed Gateway API CRD を インストールします。
  • Istio アドオンがインストールされていて、マイナー リビジョン asm 以降のリビジョンasm-1-26オンになっていることを確認します。 インストール ガイドに従って、Istio アドオンとアップグレード ドキュメントを有効にして、以前のリビジョンを使用している場合はメッシュをasm-1-26にアップグレードします。

トラブルシューティングのシナリオ

次の状況は、AKS での Istio サービス メッシュ アドオン ゲートウェイ API イングレスの一般的なトラブルシューティング シナリオです。

アプリケーション ルーティング ゲートウェイ API の実装の互換性と移行

アプリケーション ルーティング ゲートウェイ API 実装と Istio サービス メッシュ アドオンを同時に使用することはできません。 最初に 1 つを無効にしてから、別の操作でもう一方を有効にする必要があります。 また、gatewayClassNameのGatewaysをapprouting-istioからapproutingに更新する必要があります。

以前にアプリケーション ルーティング Istio Gateway API Implementation を使用した後、Istio アドオンに移行した後、Istio アドオン コントロール プレーンが既存の Gateway リソースの所有権を取得して調整できないようにする問題が発生した場合は、 istiod デプロイを再起動してみてください。 また、 istiod ログで、 Gateway リソースの監視と所有権の取得に関連するエラーがないか調べます。

ネットワーク、ファイアウォール、ロード バランサーのエラー

Istio アドオンの使用時に発生する可能性がある一般的なネットワーク、ファイアウォール、ロード バランサーのエラーをトラブルシューティングするには、次の手順に従います。

手順 1: Azure Load Balancer の正常性プローブが適切に構成されていることを確認する

Istio アドオンは、正常性プローブを構成するために、Azure Load Balancer のアノテーションを Gateway サービスに追加します。

次の例を参照してください。

service.beta.kubernetes.io/port_<gateway_port>_health-probe_port: "10256"

service.beta.kubernetes.io/port_<gateway_port>_health-probe_protocol: http

service.beta.kubernetes.io/port_<gateway_port>_health-probe_request-path: /healthz

これらの注釈は、ポッドにトラフィックを転送する前に、ノードまたはバックエンド ポッドの正常性プローブのパス、プロトコル、ポートをAzure Load Balancerに示します。 既定では、この構成により、ノード上のkube-proxyインスタンスが正常であり、宛先ポッドにトラフィックを転送できることを確認するために、ポートはkube-proxyがリッスンしているポートに設定されます。

クラスターで kubectl get service <gateway-svc-name> -n <gateway-svc-namespace> -o yaml を実行して、この設定を確認します。 サービスにこれらの注釈がない場合、または独自のリソースのカスタマイズでこれらの注釈を上書きした場合、失敗した正常性プローブによって、Azure Load Balancerから Istio Gateway API デプロイへのトラフィックがブロックされる可能性があります。

正常性プローブのパス、ポート、またはプロトコル用のAzure Load Balancer アノテーションをGatewayオブジェクトに直接追加するか、レベルの ConfigMap または GatewayClassごとの ConfigMap をGatewayして追加します。

次のGatewayカスタマイズを行います（たとえば、Gatewayポート80でリッスンする）。

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
...
...
spec:
  infrastructure:
    annotations:
      service.beta.kubernetes.io/port_80_health-probe_port: "10256"
      service.beta.kubernetes.io/port_80_health-probe_protocol: http
      service.beta.kubernetes.io/port_80_health-probe_request-path: /healthz

ConfigMap のカスタマイズ:

apiVersion: v1
kind: ConfigMap
data:
  service: |
    metadata:
      annotations:
        service.beta.kubernetes.io/port_80_health-probe_port: "10256"
        service.beta.kubernetes.io/port_80_health-probe_protocol: http
        service.beta.kubernetes.io/port_80_health-probe_request-path: /healthz

また、LoadBalancer のクラスターのインフラストラクチャ リソース グループにある Settings> セクションで を確認することで、正常性プローブが失敗しているかどうかを確認することもできます。

Note

これらの正常性プローブは、"クラスター" の既定の externalTrafficPolicy 設定用に構成されます。 spec.externalTrafficPolicy を "ローカル" に設定した場合は、 GatewayClass レベルの ConfigMap またはゲートウェイごとの ConfigMap で、次の注釈の設定を解除する必要があります。

 service: |
    spec:
       externalTrafficPolicy: Local
    metadata:
      annotations:
        service.beta.kubernetes.io/port_80_health-probe_port:
        service.beta.kubernetes.io/port_80_health-probe_protocol:
        service.beta.kubernetes.io/port_80_health-probe_request-path:

手順 2: ファイアウォールまたは NSG 規則でイングレス トラフィックがブロックされていないことを確認する

ファイアウォールまたはネットワーク セキュリティ グループ (NSG) 規則によってイングレス ゲートウェイへのトラフィックがブロックされていないことを確認します。

ユーザー ノード プールのサブネットのみにトラフィックを許可するように制限を設定するかどうかを再確認します。 ゲートウェイ API ポッドが システム ノード プールにスケジュールされている場合、これらのポッドへの受信トラフィックがブロックされる可能性があります。 この問題に対処するには、システム ノード プールのサブネットへのトラフィックを許可します。

ゲートウェイの構成に関する問題

ゲートウェイ構成の問題をトラブルシューティングするには、次の手順に従います。

手順 1: gatewayClassName が > に設定されていることを確認する istio

作成したすべてのGatewaysで、spec.gatewayClassNameがistioに設定されていることを確認します。 アプリケーション ルーティング ゲートウェイ API の実装を使用している場合は、spec.gatewayClassNameを approuting-istio に設定します。

手順 2: クロス名前空間参照を確認する

Gatewayとそれぞれのルートをデプロイする名前空間に応じて、同じ名前空間または異なる名前空間間のルートのみを許可するようにGatewayspec.listeners.allowedRoutes値を設定します。 同様に、ルートの spec.parentRefs 値を設定して、正しい Gateway を参照し、クロス名前空間 Gateway 参照に適切な名前空間を指定します。 詳細については、 クロス名前空間ルーティングに関するゲートウェイ API のドキュメントを参照してください。

同様に、 ReferenceGrants を使用して、ルートから他の名前空間のバックエンドへのクロス名前空間を有効にします。

手順 3: AKS マネージド istio-gateway-class-defaults ConfigMap との競合がないことを確認する

マネージド ゲートウェイ API の CRD と Istio アドオンを一緒に有効にするときに、AKS が istio-gateway-class-defaults ConfigMap をプロビジョニングして調整していることを確認します。 istio-gateway-class-defaults名前空間に aks-istio-system ConfigMap を作成したことがある場合は、マネージド ゲートウェイ API の CRD を有効にする前に、セルフマネージド ConfigMap インスタンスを削除して、AKS で管理される ConfigMap の調整との競合を回避します。

手順 4: ルーティング規則が競合しないことを確認する

1 つの Gateway リソースに複数のルートをアタッチできますが、各要求に一致できるルート ルールは 1 つだけです。 ルールが重複すると、多くの場合、競合やマージの問題が発生します。

手順 5: プログラミング エラーの Gateway とルートを調べる

Gatewayのプログラムされた状態が failed または unknown の場合は、Gateway オブジェクトを調べて詳細を確認します。 kubectl get gateway <gateway-name> -n <gateway-namespace> -o yaml および kubectl describe gateway <gateway-name> -n <gateway-namespace> を実行します。 ゲートウェイ オブジェクトの STATUS で、プログラミングの問題やその他のエラーを確認します。

HTTPRoutesを実行して、ルートの状態 (GRPCRoutesやkubectl describe httproute <route-name> -n <route-namespace> -o yamlなど) を確認してください。

手順 6: istiod と Gateway ログでエラーを調べる

istiod ログには、Gatewayプログラミング関連のエラーに関する追加の詳細が含まれている場合があります。 ゲートウェイが正常にプログラムされ、ポッドのデプロイが作成されたが、その他の問題が発生した場合は、 Gateway ポッド ログで潜在的なエラーがないか調べます。 Gateway ポッドのデプロイ名は、<gateway-name>-istioという形式に従います。

手順 7: プロキシ ポッド Gateway 検査する

Gatewayプロキシポッドが失敗しておらず、メモリの問題が原因でOOMKilledしていないことを確認します。 Gatewayを使用して、デプロイ リソースの要求と制限、およびの水平ポッド オートスケーラー (HPA) を構成できます。

手順 8: Gateway リソース名が有効であることを確認する

既定では、Istio コントロール プレーンは、GatewayClass名istio (またはapprouting-istioの) を、Gateway用にプロビジョニングするリソースの名前に追加します。 リソース名は 63 文字未満でなければならず、有効な DNS 名である必要もあります。 名前が無効な場合、 istiod は Gateway リソースをプロビジョニングしませんが、 error ログを出力します。

Gatewayを使用してgateway.istio.io/name-override リソースに注釈を付けて、プロビジョニングされたリソースの名前をオーバーライドできます。

手順 9: GatewayClass が作成されていることを確認する

GatewayClass istioが作成されていることを確認します。 確認するには、 kubectl get gatewayclassを実行します。 GatewayClassがまだ作成されていない場合は、クラスターでの Managed Gateway API CRD インストールを有効にしていることを確認します。 Managed Gateway API CRD がインストールされていても、 GatewayClass がまだ作成されていない場合は、 istiod ログでエラーがないか調べます。

Note

アプリケーション ルーティング ゲートウェイ API 実装を使用している場合は、作成されたGatewayClassをapprouting-istioする必要があります。

競合を回避するには、Managed Gateway API で Istio アドオンを有効にする前に、クラスターに GatewayClassistio がデプロイされていないことも確認してください。 また、Istio アドオンと同時にインストールされた GatewayClassistio (Open-Source Istio など) を調整する別の Istio ベースのコントローラーがないことを確認します。

マイナー改訂のアップグレードと改訂ラベルの問題

既定では、Istio アドオンのマイナー リビジョン アップグレード中に、クラスターに 2 つのコントロール プレーンを同時にデプロイした場合、次の例に示すように、ゲートウェイに特定のGatewayリビジョンのラベルを付けない場合、より高いリビジョンはasm リソースの所有権を取得します。

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: httpbin-gateway
  labels:
    istio.io/rev: asm-1-26
spec:
  gatewayClassName: istio

マイナー リビジョンのアップグレード中に、ゲートウェイのポッドとデプロイが自動的に更新され、新しいプロキシ マイナー イメージ バージョンが、後のコントロール プレーンのマイナー リビジョンに対応することを確認します。 バージョンが更新されていない場合は、 istiod 展開を再起動してみてください。

asmリビジョンを持つようにゲートウェイに明示的にラベルを付ける場合は、アップグレード操作を完了またはロールバックする前に、それに応じて再ラベル付けします。

ゲートウェイ リソースのカスタマイズに関する問題

Istio アドオンでは、ゲートウェイ用 に作成されるリソースのカスタマイズ がサポートされています。 サポートされているリソースの種類は次のとおりです。

  • デプロイメント
  • サービス
  • 水平ポッド オートスケーラー (HPA)
  • PodDisruptionBudget (PDB)

Gateway リソースの構成に関連する問題については、次のトラブルシューティング手順に従ってください。

手順 1: カスタマイズ フィールドが許可リストにあることを確認する

GatewayClass レベルの ConfigMap と Gateway レベルの ConfigMap の両方のカスタマイズに、特定のリソースの許可リストにあるフィールドのみが含まれていることを確認します。

手順 2: GatewayClass レベルの ConfigMap が正しく構成されていることを確認する

Istio アドオンは、クラスターで Managed Gateway API のインストールを有効にすると、GatewayClass名前空間に istio-gateway-class-defaults レベルの ConfigMap aks-istio-systemを自動的にデプロイします。

Note

Managed Gateway API CRD をインストールした後、 istio-gateway-class-defaults ConfigMap がデプロイされるまでに最大 5 分かかる場合があります。

この ConfigMap を編集する場合は、 gateway.istio.io/defaults-for-class ラベルを istio に設定したままにしてください。 一度にデプロイできる GatewayClassレベルの ConfigMap は 1 つだけです。

手順 3: ゲートウェイ レベルの ConfigMap カスタマイズを確認する

GatewayClass レベルの ConfigMap と Gateway レベルの ConfigMap の両方がデプロイされている場合は、Gateway レベルの ConfigMap のカスタマイズが優先されます。 ゲートウェイに必要なリソースのカスタマイズが、 Gateway レベルの ConfigMap で設定されていることを確認します。 spec.infrastructure.parametersRef フィールドがそのゲートウェイの正しい ConfigMap を参照していることを確認します。

手順 4: ゲートウェイ リソース伝達エラーを検査する

Gatewayのカスタマイズがそれぞれのリソースに反映されない場合は、インデント、正しいフィールド名、スペルなどの点で ConfigMap 仕様が有効であることを確認します。 また、 istiod ログを調べて、問題がゲートウェイのテンプレートのレンダリングまたはリソースの作成に影響するかどうかを確認する必要もあります。

  • Last updated on