Risoluzione dei problemi

Questa pagina si applica a Apigee e Apigee ibridi.

Visualizza la documentazione di Apigee Edge.

Errore Istio 404 (non trovato)

Il debug di un errore 404 (Non trovato) su Istio può essere frustrante. Spero che queste informazioni ti aiutino a capire dove potrebbero esserci dei problemi.

Conflitto gateway con caratteri jolly

Può esistere una sola definizione di gateway che utilizza un valore hosts jolly "*". Se hai eseguito il deployment di altri elementi che includono un gateway con caratteri jolly, le chiamate client non andranno a buon fine con uno 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 i punti in cui si verifica un errore nel percorso

Istio è come una cipolla (o forse un orco), ha strati. Un metodo sistematico di debug un errore 404 è procedere all'esterno del target.

Il carico di lavoro di backend

Verifica di poter accedere al carico di lavoro dal sidecar:

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

Il sidecar di backend

Imposta l'indirizzo del servizio e ricevi 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 e analisi nell'interfaccia utente di Analytics, considera queste possibili cause:

  • L'inserimento di Apigee può subire un ritardo di alcuni minuti
  • Il 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 non valida che non viene 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'intercetta.
  • 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 la seguente documentazione di Envoy Autorizzazione esterna, e consulta le informazioni sulla proprietà failure_mode_allow. Questa proprietà consente di modificare il comportamento del filtro in caso di errori.

JWT mancante o non valido non viene rifiutato

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

Chiave API valida non riuscita

Cause probabili

  • Envoy non riesce a raggiungere il servizio remoto
  • Le tue credenziali non sono valide
  • Prodotto API Apigee non configurato per target ed env
  • Envoy non è a conoscenza del prodotto API Apigee

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.

  • È vincolato al target a cui accedi?

    Controlla la sezione Target di 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à ad esempio 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 "*" o "**" caratteri jolly per trovare corrispondenze.

  • Hai un'app sviluppatore?

    Il prodotto API deve essere associato a un'app per sviluppatori per consentirne il controllo delle chiavi.

  • L'attributo operationConfigType del prodotto API Apigee è impostato su remoteservice?

    Controlla la configurazione del prodotto API utilizzando l'API di gestione Apigee e verifica che operationConfigType sia impostato su remoteservice.

Controlla la tua richiesta

  • Stai passando la chiave consumer nel 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 in debug level. Consulta Impostazione dei livelli di log di servizio remoto.

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

    apigee-remote-service-envoy -l debug
  2. Tenta di accedere al target e controllare 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]

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 livello di dettaglio, dove debug è il più dettagliato e error è il meno dettagliato:

  • debug: la modalità di logging più dettagliata.
  • info: il valore predefinito.
  • warn
  • error - Modalità di logging meno dettagliata.

Ad esempio, per avviare il servizio a livello debug: 

apigee-remote-service-envoy -l debug