トラブルシューティング

<ph type="x-smartling-placeholder"></ph> 現在、Apigee Edge のドキュメントが表示されています。
Apigee X のドキュメント
詳細

Istio 404(見つかりません)エラー

Istio で 404(Not Found)エラーをデバッグする場合、時間がかかることがあります。このドキュメントは、問題の原因追及の出発点として役立つことを目的としています。

ワイルドカード ゲートウェイの競合

ホスト値にワイルドカード「*」を使用できるゲートウェイ定義は 1 つだけです。ワイルドカード ゲートウェイを含む別のものをデプロイしていると、クライアントの呼び出しが 404 ステータスで失敗します。

例:

$ istioctl get gateways
GATEWAY NAME         HOSTS     NAMESPACE   AGE
bookinfo-gateway     *         default     20s
httpbin-gateway      *         default     3s

その場合は、競合しているゲートウェイのいずれかを削除または変更する必要があります。

ルートが失敗している場所を突き止める

Istio はタマネギ(もしくは、Ogre)のようにレイヤで構成されています。404 を体系的にデバッグするには、対象から離れるようにデバッグする必要があります。

バックエンド ワークロード

サイドカーからワークロードにアクセスできることを確認します。

kubectl exec $WORKLOAD_POD -c istio-proxy -- curl localhost:80/headers

バックエンド サイドカー

サービス アドレスを設定して、ワークロード Pod の IP アドレスを取得します。

SERVICE=httpbin.default.svc.cluster.local:80
  POD_IP=$(kubectl get pod $WORKLOAD_POD -o jsonpath='{.status.podIP}')

サイドカーを使用してワークロードにアクセスします。

kubectl exec $WORKLOAD_POD -c istio-proxy -- curl -v http://$SERVICE/headers --resolve "$SERVICE:$POD_IP"

Istio mTLS が有効になっている場合:

kubectl exec $WORKLOAD_POD -c istio-proxy -- curl -v https://$SERVICE/headers --resolve "$SERVICE:$POD_IP" --key /etc/certs/key.pem --cert /etc/certs/cert-chain.pem --cacert /etc/certs/root-cert.pem --insecure

ゲートウェイ(またはフロントエンド サイドカー)

ゲートウェイからサービスにアクセスします。

kubectl -n istio-system exec $GATEWAY_POD -- curl -v http://$SERVICE/header

Istio mTLS が有効になっている場合:

kubectl -n istio-system exec $GATEWAY_POD -- curl -v https://$SERVICE/headers --key /etc/certs/key.pem --cert /etc/certs/cert-chain.pem --cacert /etc/certs/root-cert.pem --insecure

分析が表示されない

Analytics UI に分析結果が表示されない場合は、次のような原因が考えられます。

  • Apigee の取り込みに数分間の遅延がある
  • Envoy gRPC アクセスログが正しく構成されていない
  • Envoy がリモート サービスに到達できない
  • リモート サービスがアップロードできない

API キーが存在しないか、不正な API キーが拒否されない

API キーの検証が正しく動作しない場合は、次の原因が考えられます。

直接プロキシ

ext-authz 構成を確認します。

サイドカー
  • インターセプト用のリスナーが構成されていることを確認します。
  • ext-authz 構成を確認します。

無効なリクエストがチェックされているが、許可されている

  • リモート サービスがフェール オープンに構成されている
  • Envoy が RBAC チェック用に構成されていない

このような問題に対処する方法については、Envoy のドキュメントで外部承認をご覧ください。また、failure_mode_allow プロパティに関する情報もご覧ください。このプロパティを使用すると、エラーに対するフィルタの動作を変更できます。

JWT が存在しないか、不正な JWT が拒否されない

原因として、Envoy JWT フィルタが構成されていないことが考えられます。

有効な API キーが失敗する

考えられる原因

  • Envoy がリモート サービスに到達できない
  • 認証情報が無効である
  • ターゲットと環境用に Apigee API プロダクトが構成されていない

トラブルシューティング手順

Apigee で API サービスを確認する

  • 環境(テスト環境と本番環境)で有効になっていますか?

    このプロダクトは、リモート サービスと同じ環境にバインドする必要があります。

  • アクセスするターゲットにバインドされていますか?

    Apigee リモート サービス ターゲット セクションを確認します。サービス名は、完全修飾ホスト名にする必要があります。Istio サービスの場合、この名前は helloworld.default.svc.cluster.localcode> のようになります。これは、default 名前空間内の helloworld サービスを表します。

  • リソースパスはリクエストと一致していますか?

    //** のようなパスは、どのパスとも一致します。マッチングでは、ワイルドカードとして「*」または「**」を使用できます。

  • デベロッパー アプリがありますか?

    キーを確認するには、API プロダクトがデベロッパー アプリにバインドされている必要があります。

リクエストを確認する

  • コンシューマ キーを x-api-key header に渡していますか?

    例:

    curl http://localhost/hello -H "x-api-key: wwTcvmHvQ7Dui2qwj43GlKJAOwmo"
  • 適切なコンシューマ キーを使用していますか?

    使用しているアプリの認証情報が、API サービスに対して承認されていることを確認します。

リモート サービスのログを確認する

  • debug level でロギングを使用してリモート サービスを開始する

    コマンドラインで -l debug オプションを使用します。

  • ターゲットにアクセスを試みて、ログを確認する

    ログで次のような行を確認します。

    Resolve api: helloworld.default.svc.cluster.local, path: /hello, scopes: []
    Selected: [helloworld]
    Eliminated: [helloworld2 doesn't match path: /hello]