このページは Apigee と Apigee ハイブリッドに適用されます。
Apigee Edge のドキュメントを表示する。
 
Istio 404(Not Found)エラー
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]