Solución de problemas

Estás consultando la documentación de Apigee Edge.
Consulta la documentación de Apigee X.
Información

Error 404 (No encontrado) de Istio

La depuración de un error 404 (Not Found) en Istio puede ser frustrante. Con suerte, esto te dará la posibilidad de comenzar a hacer un seguimiento de los errores que se produjeron.

Conflicto de la puerta de enlace con comodín

Solo puede haber una definición de puerta de enlace que use un valor comodín “*” de host. Si implementaste cualquier otro elemento que incluya una puerta de enlace con comodín, las llamadas del cliente fallarán con un estado 404.

Ejemplo:

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

En ese caso, deberás borrar o cambiar una de las puertas de enlace conflictivas.

Haz un seguimiento para ver dónde falla la ruta

Istio es como una cebolla (o, tal vez, un ogro), tiene capas. Una forma sistemática de depurar un error 404 es trabajar de forma exterior al destino.

La carga de trabajo del backend

Verifica que puedas acceder a la carga de trabajo desde el archivo adicional:

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

El archivo adicional del backend

Configura la dirección del 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 archivo adicional:

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

O bien, si Istio mTLS está habilitado, haz lo siguiente:

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 puerta de enlace (o un archivo adicional de frontend)

Accede al servicio desde la puerta de enlace:

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

O bien, si Istio mTLS está habilitado, haz lo siguiente:

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 ves estadísticas en la IU de Analytics, considera estas posibles causas:

  • El ingreso de Apigee puede demorar unos minutos
  • El registro de acceso de Envoy gRPC no se configuró correctamente
  • Envoy no puede acceder al servicio remoto
  • Error en la carga del servicio remoto

No se rechaza la clave de API faltante o incorrecta

Si la validación de la clave de API no funciona correctamente, considera las siguientes causas posibles:

Proxy directo

Verifica la configuración de ext-authz.

Archivo adicional
  • Asegúrate de que el objeto de escucha esté configurado para la interceptación.
  • Verifica la configuración de ext-authz.

Se están verificando y permitiendo las solicitudes no válidas

  • Servicio remoto configurado para las fallas cuando se abre
  • Envoy no está configurado para las verificaciones de RBAC

Para obtener información sobre cómo abordar estos problemas, consulta el siguiente tema de la documentación de Envoy Autorización externa y la información sobre la propiedad failure_mode_allow. Esta propiedad te permite cambiar el comportamiento del filtro según los errores.

No se rechaza el JWT faltante o incorrecto

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

La clave de API válida falla

Causas posibles

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

Pasos para solucionar problemas

Verifica tu producto de API en Apigee

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

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

  • ¿Está vinculado al destino al que accedes?

    Consulta la sección Destinos del servicio remoto de Apigee. Recuerda que el nombre del servicio debe ser un nombre de host completo. Si es un servicio de Istio, el nombre será similar a helloworld.default.svc.cluster.localcode>, que representa el servicio helloworld en el espacio de nombres default.

  • ¿La ruta de acceso del recurso coincide con tu solicitud?

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

  • ¿Tienes una app de desarrollador?

    El Producto de API debe estar vinculado a una app para desarrolladores para verificar sus claves.

Verifica tu solicitud

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

    Ejemplo:

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

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

Verifica 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 destino y verificar los registros

    Revisa los registros de una línea que tenga un aspecto similar al siguiente:

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