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

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.

Busca 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

Estadísticas faltantes

Si no ve las estadísticas en la IU de Analytics, tenga en cuenta las siguientes causas posibles:

  • 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 no válida

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

Proxy directo

Verifica la configuración ext-authz.

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

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

  • Servicio remoto configurado para la apertura ante fallas
  • 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 no válido

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

Falla la clave de API válida

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
  • Envoy no conoce el producto de la API de Apigee

Pasos para solucionar problemas

Verifica tu producto de API en Apigee

  • ¿Está habilitado para tu entorno (prueba y prod)?

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

  • ¿Está vinculado con el objetivo al que estás accediendo?

    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 recursos 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 para desarrolladores?

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

  • ¿El objeto operationConfigType del Producto de API de Apigee está configurado como remoteservice?

    Verifica la configuración del producto de API con la API de administración de Apigee y confirma que operationConfigType esté configurado como remoteservice.

Verifica tu solicitud

  • Debes pasar 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

  1. Inicia el servicio remoto con registro a debug level. Consulta Configura los niveles de registro del servicio remoto.

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

    apigee-remote-service-envoy -l debug
  2. Intenta acceder a tu objetivo y verifica 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]

Configura los niveles de registro de servicio remoto

Con una marca de línea de comandos, puedes iniciar el servicio remoto en uno de los siguientes modos de depuración, en orden de verbosidad, en el que debug es el más detallado y error es el menos detallado:

  • debug: Es el modo de registro más detallado.
  • info: Es el valor predeterminado.
  • warn
  • error: Es el modo de registro menos detallado

Por ejemplo, para iniciar el servicio en el nivel de debug, haz lo siguiente: 

apigee-remote-service-envoy -l debug