Risoluzione dei problemi

Stai visualizzando la documentazione di Apigee Edge.
Consulta la documentazione di Apigee X. info

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 esserci problemi.

Conflitto tra gateway jolly

Può esistere una sola definizione di gateway che utilizza un valore host jolly "*". Se hai implementato altro che includa un gateway con caratteri 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.

Traccia il punto in cui la route non funziona

Istio è come una cipolla (o, forse, un orco), ha degli strati. Un modo sistematico per eseguire il debug di un errore 404 è lavorare verso l'esterno a partire dalla destinazione.

Il workload di backend

Verifica di poter accedere al workload dal sidecar:

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

Il sidecar 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 carico di lavoro 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 mTLS di Istio è 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 esame 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 caricamento di Remote Service non riesce

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.

Sidecar
  • 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 il fail open
  • Envoy non configurato per i controlli RBAC

Per informazioni su come risolvere questi problemi, consulta l'argomento della 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 la destinazione e l'ambiente

Procedura 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.localcode> - che rappresenta il servizio helloworld nello spazio dei nomi default.

  • 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 per sviluppatori?

    Per controllare le chiavi, il prodotto API deve essere associato a un'app per sviluppatori.

Controlla la tua richiesta

  • Stai passando la chiave consumer in x-api-key header

    Esempio:

    curl http://localhost/hello -H "x-api-key: wwTcvmHvQ7Dui2qwj43GlKJAOwmo"
  • Stai utilizzando una chiave utente valida?

    Assicurati che le credenziali dell'app che stai utilizzando siano approvate per il tuo prodotto API.

Controllare i log del servizio remoto

  1. Avvia il servizio remoto con il logging all'indirizzo debug level. Consulta Impostare i livelli di log del servizio remoto.

    Utilizza l'opzione -l debug nella riga di comando. Ad esempio:

    apigee-remote-service-envoy -l debug
  2. Tentativo di accesso al target e controllo dei log

    Controlla i log per trovare una riga simile a questa:

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

    3. Impostazione dei livelli di log del servizio remoto

    Utilizzando un flag della riga di comando, puoi avviare il servizio remoto in una delle seguenti modalità di debug, in ordine di verbosità, dove debug è la più dettagliata e error la meno:

    • debug: la modalità di logging più dettagliata.
    • info: l'impostazione predefinita.
    • warn
    • error: modalità di logging meno dettagliata.

    Ad esempio, per avviare il servizio al livello debug: 

    apigee-remote-service-envoy -l debug