<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.local
code> のようになります。これは、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]