Dépannage

<ph type="x-smartling-placeholder"></ph> Vous consultez la documentation Apigee Edge.
Accédez à la page Documentation sur Apigee X. En savoir plus

Erreur 404 (introuvable) Istio

Le débogage d'une erreur 404 (introuvable) sur Istio peut s'avérer frustrant. Nous espérons que ces informations vous aideront à identifier les problèmes éventuels.

Conflit de passerelle générique

Il ne peut y avoir qu'une seule définition de passerelle qui utilise une valeur d'hôte générique "*". Si vous avez déployé autre chose qui inclut une passerelle générique, les appels client échouent avec l'état 404.

Exemple :

$ istioctl get gateways
GATEWAY NAME         HOSTS     NAMESPACE   AGE
bookinfo-gateway     *         default     20s
httpbin-gateway      *         default     3s

Si tel est le cas, vous devez supprimer ou modifier l'une des passerelles en conflit.

Identifier l'origine de l'échec de la route

Tout comme un oignon (ou peut-être un ogre), Istio a des couches. Une manière systématique de déboguer une erreur 404 est de partir de la cible et de s'en éloigner.

Charge de travail de backend

Vérifiez que vous pouvez accéder à la charge de travail à partir du side-car :

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

Side-car de backend

Définissez l'adresse de service et obtenez l'adresse IP du pod de la charge de travail.

SERVICE=httpbin.default.svc.cluster.local:80
  POD_IP=$(kubectl get pod $WORKLOAD_POD -o jsonpath='{.status.podIP}')

Accédez à la charge de travail via le side-car :

kubectl exec $WORKLOAD_POD -c istio-proxy -- curl -v http://$SERVICE/headers --resolve "$SERVICE:$POD_IP"

Ou, si Istio mTLS est activé :

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

Passerelle (ou side-car d'interface)

Accédez au service à partir de la passerelle :

kubectl -n istio-system exec $GATEWAY_POD -- curl -v http://$SERVICE/header

Ou, si Istio mTLS est activé :

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

Données analytiques manquantes

Si aucune donnée analytique n'apparaît dans l'UI Analytics, vous pouvez envisager les causes suivantes :

• L'intégration Apigee peut être retardée de quelques minutes.
• Le journal d'accès gRPC Envoy n'est pas configuré correctement.
• Envoy ne peut pas accéder au service distant.
• L'importation du service distant échoue.

Clé API manquante ou incorrecte non refusée

Si la validation des clés API ne fonctionne pas correctement, voici quelques causes possibles :

Proxy direct

Vérifiez la configuration ext-authz.

• Assurez-vous que l'écouteur est configuré pour l'interception.
• Vérifiez la configuration ext-authz.

Les requêtes incorrectes sont vérifiées et autorisées.

• Le service distant a une configuration ouverte ("fail open").
• Envoy n'est pas configuré pour les vérifications RBAC.

Pour en savoir plus sur la résolution de ces problèmes, consultez la page suivante sur la documentation Envoy : External Authorization (Autorisation externe), et référez-vous aux informations sur la propriété failure_mode_allow. Cette propriété vous permet de modifier le comportement du filtre en cas d'erreur.

JWT manquant ou incorrect non refusé

La cause la plus probable est que le filtre JWT Envoy n'est pas configuré.

Échec d'une clé API valide

Causes probables

• Envoy ne peut pas accéder au service distant.
• Vos identifiants ne sont pas valides.
• Le produit d'API Apigee n'est pas configuré pour la cible et l'environnement.

Procédure de dépannage

Vérifier votre produit d'API sur Apigee

• Est-il activé pour votre environnement (test ou production) ?

  Le produit doit être lié au même environnement que votre service distant.

• Est-il lié à la cible à laquelle vous accédez ?

  Consultez la section Cibles de services distants d'Apigee. N'oubliez pas que le nom du service doit être un nom d'hôte complet. S'il s'agit d'un service Istio, le nom ressemblera à helloworld.default.svc.cluster.localcode>, qui représente le service helloworld dans l'espace de noms default.

• Le chemin de ressource correspond-il à votre requête ?

  N'oubliez pas qu'un chemin d'accès tel que / ou /** correspond à n'importe quel chemin. Vous pouvez également utiliser les caractères génériques "*" ou "**" pour la mise en correspondance.

• Avez-vous une application de développement ?

  Le produit d'API doit être lié à une application de développement pour vérifier ses clés.

Vérifier votre requête

• Transmettez-vous la clé client dans le x-api-key header ?

  Exemple :

  curl http://localhost/hello -H "x-api-key: wwTcvmHvQ7Dui2qwj43GlKJAOwmo"

• Utilisez-vous une clé client valide ?

  Vérifiez que les identifiants de l'application que vous utilisez sont approuvés pour votre produit d'API.

Vérifier les journaux du service distant

1. Démarrez le service distant avec la journalisation sur le debug level. Consultez la section Définir les niveaux de journalisation du service distant.

   Utilisez l'option -l debug sur la ligne de commande. Exemple :

   apigee-remote-service-envoy -l debug

2. Tentez d'accéder à votre cible et vérifiez les journaux.

   Dans les journaux, recherchez une ligne qui ressemble à ce qui suit :

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

Définir les niveaux de journalisation du service distant

À l'aide d'un indicateur de ligne de commande, vous pouvez démarrer le service distant dans l'un des modes de débogage suivants, par ordre de verbosité, où debug est la plus détaillée et error la moins détaillée :

• debug : mode de journalisation le plus détaillé
• info : valeur par défaut
• warn
• error : mode de journalisation le moins détaillé

Par exemple, pour démarrer le service au niveau debug :

apigee-remote-service-envoy -l debug