Risoluzione dei problemi

Questa pagina si applica ad Apigee e Apigee hybrid.

Visualizza la documentazione di Apigee Edge.

Errore 404 (non trovato) Istio

Il debug di un errore 404 (Non trovato) su Istio può essere frustrante. Speriamo che in questo modo potrai iniziare a capire dove potrebbero verificarsi problemi.

Conflitto tra gateway con caratteri jolly

Può esistere una sola definizione di gateway che utilizza un valore host "*" con il carattere jolly. Se hai eseguito il deployment di qualsiasi altro elemento che includa un gateway con caratteri jolly, le chiamate client avranno esito negativo 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.

Cerca un punto in cui il percorso non è corretto

Istio è una cipolla (o forse un orco) e ha dei livelli. Un modo sistematico per eseguire il debug di un errore 404 è analizzare al di fuori del 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 recupera 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 file collaterale:

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 dati di analisi nell'interfaccia utente di Analytics, valuta le seguenti possibili cause:

  • L'importazione di Apigee può subire ritardi 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

Chiave API mancante o non valida che 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.

Sidecar
  • Assicurati che il listener sia configurato per l'intercetta.
  • Controlla la configurazione di ext-authz.

Le richieste non valide sono in fase di controllo e autorizzazione

  • Servizio remoto configurato per fail open
  • Envoy non configurato per i controlli RBAC

Per informazioni su come risolvere questi problemi, consulta il seguente argomento della documentazione Envoy: Autorizzazione esterna e 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 che non viene rifiutato

La causa probabile è che il filtro JWT Envoy non sia configurato.

Chiave API valida non riuscita

Cause probabili

  • Envoy non riesce a contattare il servizio remoto
  • Le tue credenziali non sono valide
  • Prodotto API Apigee non configurato per destinazione ed env

Passaggi per la risoluzione dei problemi

Controlla il tuo prodotto API su Apigee

  • È abilitata per il tuo ambiente (test o produzione)?

    Il prodotto deve essere associato allo stesso ambiente del servizio remoto.

  • È legato al target a cui stai accedendo?

    Controlla la sezione Target dei servizi remoti 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?

    Il prodotto API deve essere associato a un'app sviluppatore per verificare le relative chiavi.

Controlla la tua richiesta

  • Stai passando la chiave utente nel x-api-key header

    Esempio:

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

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

Controlla 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

    Verifica 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]