Stai visualizzando la documentazione di Apigee Edge.
Vai alla
documentazione di Apigee X. informazioni
Errore Istio 404 (non trovato)
Il debug di un errore 404 (non trovato) su Istio può essere frustrante. Ci auguriamo che questo ti aiuti a capire dove potrebbero andare storti.
Conflitto tra gateway con caratteri jolly
Può esistere una sola definizione di gateway che utilizza un valore host con carattere jolly "*". Se hai eseguito il deployment di qualsiasi altro elemento che include un gateway con caratteri jolly, le chiamate client non andranno a buon fine con lo stato 404.
Esempio:
$ istioctl get gateways GATEWAY NAME HOSTS NAMESPACE AGE bookinfo-gateway * default 20s httpbin-gateway * default 3s
In questo caso, dovrai eliminare o modificare uno dei gateway in conflitto.
Individua i punti in cui il percorso non funziona
Istio è una cipolla (o forse un orco) con diversi livelli. Un modo sistematico per eseguire il debug di un errore 404 consiste nell'eseguire l'elaborazione a partire dal target.
Il carico di lavoro di backend
Verifica di poter accedere al carico di lavoro dal file collaterale:
kubectl exec $WORKLOAD_POD -c istio-proxy -- curl localhost:80/headers
Il file collaterale di backend
Imposta l'indirizzo di servizio e ottieni l'indirizzo IP del pod del carico di lavoro.
SERVICE=httpbin.default.svc.cluster.local:80 POD_IP=$(kubectl get pod $WORKLOAD_POD -o jsonpath='{.status.podIP}')
Accedi al carico di lavoro tramite il sidecar:
kubectl exec $WORKLOAD_POD -c istio-proxy -- curl -v http://$SERVICE/headers --resolve "$SERVICE:$POD_IP"
Oppure, 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
Oppure, 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
Dati e analisi mancanti
Se non visualizzi i dati e le analisi nell'interfaccia utente di Analytics, considera le seguenti possibili cause:
- L'accettazione di Apigee può essere ritardata di alcuni minuti
- Log degli accessi gRPC Envoy non configurato correttamente
- Envoy non riesce a raggiungere il servizio remoto
- Il servizio remoto non riesce a caricare
Una chiave API mancante o non valida non viene rifiutata
Se la convalida della chiave API non funziona correttamente, prendi in considerazione le seguenti 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 sono in fase di controllo e autorizzazione
- Servizio remoto configurato per mancata apertura
- Envoy non configurato per i controlli RBAC
Per informazioni su come risolvere questi problemi, consulta il seguente argomento della documentazione Envoy: Autorizzazione esterna, e fai riferimento alle 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 che non viene rifiutato
La causa probabile è che il filtro JWT di Envoy non sia configurato.
Errore di chiave API valida
Probabili cause
- Envoy non riesce a raggiungere il servizio remoto
- Le tue credenziali non sono valide
- Prodotto API Apigee non configurato per target ed env
Procedura per la risoluzione dei problemi
Controlla il tuo prodotto API su Apigee
- È abilitato per il tuo ambiente (di test o di produzione)?
Il prodotto deve essere associato allo stesso ambiente del servizio remoto.
- È legato al target a cui stai accedendo?
Controlla la sezione Target di 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 caratteri jolly "*" o "**" per le corrispondenze. - Hai un'app per sviluppatori?
Il prodotto API deve essere associato a un'app sviluppatore per verificare le relative chiavi.
Verifica la tua richiesta
- Stai passando la chiave utente nel
x-api-key header
Esempio:
curl http://localhost/hello -H "x-api-key: wwTcvmHvQ7Dui2qwj43GlKJAOwmo"
- Stai utilizzando una chiave consumatore 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 il logging in
debug level
Utilizza l'opzione
-l debug
nella riga di comando. - Prova ad accedere alla destinazione e controlla i log
Controlla se nei log è presente una riga simile alla seguente:
Resolve api: helloworld.default.svc.cluster.local, path: /hello, scopes: [] Selected: [helloworld] Eliminated: [helloworld2 doesn't match path: /hello]