Esta página foi traduzida pela API Cloud Translation.

Resolução de problemas

Esta página aplica-se ao Apigee e ao Apigee Hybrid.

Veja a documentação do Apigee Edge.

Erro 404 (Não encontrado) do Istio

A depuração de um erro 404 (Não encontrado) no Istio pode ser frustrante. Esperamos que isto lhe dê um ponto de partida para descobrir onde as coisas podem estar a correr mal.

Conflito de gateway de caráter universal

Só pode existir uma definição de gateway que use um valor de anfitriões "*" com caráter universal. Se tiver implementado qualquer outra coisa que inclua um gateway com carateres universais, as chamadas de cliente falham com o estado 404.

Exemplo:

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

Se for o caso, tem de eliminar ou alterar um dos gateways em conflito.

Pesquise onde o trajeto está a falhar

O Istio é como uma cebola (ou, talvez, um ogre), tem camadas. Uma forma sistemática de depurar um erro 404 é trabalhar a partir do destino.

A carga de trabalho de back-end

Valide se consegue aceder à carga de trabalho a partir do sidecar:

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

O ficheiro complementar de back-end

Defina a morada de serviço e obtenha o endereço IP do pod de carga de trabalho.

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

Aceda à carga de trabalho através do sidecar:

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

Em alternativa, se o mTLS do Istio estiver ativado:

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

O gateway (ou um sidecar de frontend)

Aceda ao serviço a partir do gateway:

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

Em alternativa, se o mTLS do Istio estiver ativado:

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

Estatísticas em falta

Se não estiver a ver estatísticas na IU do Analytics, considere estas possíveis causas:

A receção do Apigee pode ter um atraso de alguns minutos
O registo de acesso gRPC do Envoy não está configurado corretamente
O Envoy não consegue aceder ao serviço remoto
O serviço remoto está a falhar o carregamento

Chave da API em falta ou incorreta não rejeitada

Se a validação da chave da API não estiver a funcionar corretamente, considere estas possíveis causas:

Proxy direto

Verifique a configuração do ext-authz.

Sidecar

Certifique-se de que o ouvinte está configurado para interceção.
Verifique a configuração do ext-authz.

As solicitações inválidas estão a ser verificadas e permitidas

Serviço remoto configurado para abertura em caso de falha
O Envoy não está configurado para verificações de RBAC

Para obter informações sobre como resolver estes problemas, consulte o tópico Autorização externa da seguinte documentação do Envoy e consulte informações sobre a propriedade failure_mode_allow. Esta propriedade permite-lhe alterar o comportamento do filtro em caso de erros.

O JWT em falta ou inválido não está a ser rejeitado

A causa provável é que o filtro JWT do Envoy não está configurado.

A chave da API válida falha

Causas prováveis

O Envoy não consegue aceder ao serviço remoto
As suas credenciais não são válidas
O produto de API Apigee não está configurado para o destino e o ambiente

Passos de resolução de problemas

Verifique o seu produto de API no Apigee

Está ativado para o seu ambiente (teste vs. produção)?
O produto tem de estar associado ao mesmo ambiente que o seu serviço remoto.
Está associado ao destino ao qual está a aceder?
Verifique a secção Alvos de serviços remotos do Apigee. Tenha em atenção que o nome do serviço tem de ser um nome de anfitrião totalmente qualificado. Se for um serviço Istio, o nome será algo como helloworld.default.svc.cluster.localcode> , que representa o serviço helloworld no espaço de nomes default.
O caminho do recurso corresponde ao seu pedido?
Lembre-se de que um caminho como / ou /** corresponde a qualquer caminho. Também pode usar carateres universais "*" ou "**" para fazer correspondências.
Tem uma app de programador?
O produto da API tem de estar associado a uma app de programador para verificar as respetivas chaves.

Verifique o seu pedido

Está a transmitir a chave de consumidor no x-api-key header