Questa pagina si applica ad Apigee e Apigee hybrid.
Visualizza la documentazione di
Apigee Edge.
Errore 404 (non trovato) di Istio
Il debug di un errore 404 (Non trovato) su Istio può essere frustrante. Spero che questo ti dia un punto di partenza per capire dove potrebbero verificarsi problemi.
Conflitto di gateway jolly
Può esistere una sola definizione di gateway che utilizza un valore di host con carattere jolly "*". Se hai eseguito il deployment di altri elementi che includono un gateway jolly, le chiamate client non andranno a buon fine e verrà restituito lo stato 404.
Esempio:
$ istioctl get gateways GATEWAY NAME HOSTS NAMESPACE AGE bookinfo-gateway * default 20s httpbin-gateway * default 3s
In questo caso, devi eliminare o modificare uno dei gateway in conflitto.
Cerca il punto in cui il percorso non funziona
Istio è come una cipolla (o, forse, un orco), ha degli strati. Un modo sistematico per eseguire il debug di un errore 404 è procedere verso l'esterno dal target.
Il workload di backend
Verifica di poter accedere al workload dal sidecar:
kubectl exec $WORKLOAD_POD -c istio-proxy -- curl localhost:80/headers
Il file collaterale di backend
Imposta l'indirizzo del servizio e ottieni l'indirizzo IP del pod del workload.
SERVICE=httpbin.default.svc.cluster.local:80 POD_IP=$(kubectl get pod $WORKLOAD_POD -o jsonpath='{.status.podIP}')
Accedi al workload tramite il sidecar:
kubectl exec $WORKLOAD_POD -c istio-proxy -- curl -v http://$SERVICE/headers --resolve "$SERVICE:$POD_IP"
In alternativa, se Istio mTLS è abilitato:
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
Il gateway (o un sidecar frontend)
Accedi al servizio dal gateway:
kubectl -n istio-system exec $GATEWAY_POD -- curl -v http://$SERVICE/header
In alternativa, se Istio mTLS è abilitato:
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
Analisi mancanti
Se non visualizzi le analisi nell'interfaccia utente di Analytics, prendi in considerazione le seguenti possibili cause:
- L'inserimento di Apigee può subire un ritardo di alcuni minuti
- Log di accesso gRPC di Envoy non configurato correttamente
- Envoy non riesce a raggiungere il servizio remoto
- Il servizio remoto non riesce a caricare
Chiave API mancante o errata non rifiutata
Se la convalida della chiave API non funziona correttamente, considera queste possibili cause:
Proxy diretto
Controlla la configurazione di ext-authz
.
- Assicurati che il listener sia configurato per l'intercettazione.
- Controlla la configurazione di
ext-authz
.
Le richieste non valide vengono controllate e consentite
- Servizio remoto configurato per l'apertura in caso di errore
- Envoy non è configurato per i controlli RBAC
Per informazioni su come risolvere questi problemi, consulta l'argomento della seguente documentazione di Envoy: Autorizzazione esterna e consulta le informazioni sulla proprietà failure_mode_allow
. Questa proprietà
ti consente di modificare il comportamento del filtro in caso di errori.
JWT mancante o non valido non rifiutato
La causa probabile è che il filtro JWT Envoy non è configurato.
La chiave API valida non funziona
Cause probabili
- Envoy non riesce a raggiungere il servizio remoto
- Le tue credenziali non sono valide
- Prodotto API Apigee non configurato per target e ambiente
Passaggi per la risoluzione dei problemi
Controlla il tuo prodotto API su Apigee
- È abilitato per il tuo ambiente (test o produzione)?
Il prodotto deve essere associato allo stesso ambiente del servizio remoto.
- È associato al target a cui stai accedendo?
Controlla la sezione Target del servizio remoto Apigee. Ricorda che il nome del servizio deve essere un nome host completo. Se si tratta di un servizio Istio, il nome sarà simile a
helloworld.default.svc.cluster.local
code> - che rappresenta il serviziohelloworld
nello spazio dei nomidefault
. - Il percorso della risorsa corrisponde alla tua richiesta?
Ricorda che un percorso come
/
o/**
corrisponderà a qualsiasi percorso. Puoi anche utilizzare i caratteri jolly "*" o "**" per la corrispondenza. - Hai un'app sviluppatore?
Il prodotto API deve essere associato a un'app per sviluppatori per verificarne le chiavi.
Controllare la richiesta
- Stai passando la chiave utente in
x-api-key header
Esempio:
curl http://localhost/hello -H "x-api-key: wwTcvmHvQ7Dui2qwj43GlKJAOwmo"
- Stai utilizzando una chiave consumer valida?
Assicurati che le credenziali dell'app che stai utilizzando siano approvate per il tuo prodotto API.
Controllare i log del servizio remoto
- Avvia il servizio remoto con la registrazione in
debug level
Utilizza l'opzione
-l debug
nella riga di comando. - Tentare di accedere al target e controllare i log
Controlla i log per una riga simile alla seguente:
Resolve api: helloworld.default.svc.cluster.local, path: /hello, scopes: [] Selected: [helloworld] Eliminated: [helloworld2 doesn't match path: /hello]