Solución de problemas

Esta página se aplica a Apigee y Apigee Hybrid.

Consulta la documentación de Apigee Edge.

Error 404 (Not Found) de Istio

Depurar un error 404 (no encontrado) en Istio puede ser frustrante. Esperamos que esto te dé un punto de partida para averiguar dónde puede haber problemas.

Conflicto de pasarela comodín

Solo puede haber una definición de pasarela que use el valor de comodín "*" en el campo de hosts. Si has implementado cualquier otro elemento que incluya una pasarela comodín, las llamadas de los clientes fallarán con el estado 404.

Ejemplo:

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

Si es así, tendrás que eliminar o cambiar una de las pasarelas en conflicto.

Buscar dónde falla la ruta

Istio es como una cebolla (o, quizás, un ogro): tiene capas. Una forma sistemática de depurar un error 404 es trabajar desde el destino hacia fuera.

La carga de trabajo del backend

Verifica que puedes acceder a la carga de trabajo desde el sidecar:

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

El sidecar de backend

Define tu dirección de servicio y obtén la dirección IP del pod de la carga de trabajo.

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

Accede a la carga de trabajo a través del sidecar:

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

O bien, si mTLS de Istio está habilitado:

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

La pasarela (o un sidecar frontend)

Accede al servicio desde la pasarela:

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

O bien, si mTLS de Istio está habilitado:

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

Faltan estadísticas

Si no ve las analíticas en la interfaz de usuario de Analytics, puede deberse a los siguientes motivos:

  • La ingesta de Apigee puede retrasarse unos minutos
  • El registro de acceso gRPC de Envoy no está configurado correctamente
  • Envoy no puede acceder al servicio remoto
  • Remote Service is failing upload

No se rechaza una clave de API que falta o no es válida

Si la validación de la clave de API no funciona correctamente, ten en cuenta estas posibles causas:

Proxy directo

Comprueba la configuración de ext-authz.

Sidecar
  • Asegúrate de que el receptor esté configurado para interceptar.
  • Comprueba la configuración de ext-authz.

Se están comprobando y permitiendo solicitudes no válidas

  • Servicio remoto configurado para permitir el acceso en caso de fallo
  • Envoy no está configurado para comprobaciones de RBAC

Para obtener información sobre cómo solucionar estos problemas, consulta el tema Autorización externa de la documentación de Envoy y la información sobre la propiedad failure_mode_allow. Esta propiedad te permite cambiar el comportamiento del filtro en caso de error.

No se rechaza un JWT incorrecto o que falta

La causa probable es que el filtro JWT de Envoy no está configurado.

La clave de API válida falla

Causas probables

  • Envoy no puede acceder al servicio remoto
  • Tus credenciales no son válidas
  • El producto de API de Apigee no está configurado para el destino y el entorno

Pasos para solucionar el problema

Comprobar tu producto de API en Apigee

  • ¿Está habilitada en tu entorno (prueba o producción)?

    El producto debe estar vinculado al mismo entorno que tu servicio remoto.

  • ¿Está vinculada al objetivo al que estás accediendo?

    Consulta la sección Objetivos de servicio remoto de Apigee. Recuerda que el nombre del servicio debe ser un nombre de host completo. Si se trata de un servicio de Istio, el nombre será algo parecido a helloworld.default.svc.cluster.localcode> - que representa el servicio helloworld en el espacio de nombres default.

  • ¿La ruta del recurso coincide con tu solicitud?

    Recuerda que una ruta como / o /** coincidirá con cualquier ruta. También puedes usar los comodines "*" o "**" para buscar coincidencias.

  • ¿Tienes una aplicación de desarrollador?

    El producto de API debe estar vinculado a una aplicación para desarrolladores para comprobar sus claves.

Comprobar la solicitud

  • ¿Estás transfiriendo la clave de consumidor en el x-api-key header

    Ejemplo:

    curl http://localhost/hello -H "x-api-key: wwTcvmHvQ7Dui2qwj43GlKJAOwmo"
  • ¿Estás usando una clave de consumidor adecuada?

    Asegúrate de que las credenciales de la aplicación que estás usando estén aprobadas para tu producto de API.

Consultar los registros del servicio remoto

  • Inicia el servicio remoto con el registro en debug level

    Usa la opción -l debug en la línea de comandos.

  • Intenta acceder a tu objetivo y consulta los registros

    Busca en los registros una línea similar a esta:

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