Esta página se aplica à Apigee e à Apigee híbrida.
Confira a documentação da 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 as informações a seguir sejam úteis para você identificar os problemas.
Conflito de gateway com caractere curinga
Só pode haver uma definição de gateway que use um valor de host curinga "*". Se você tiver implantou qualquer outro elemento que inclua um gateway com caractere curinga, as chamadas do cliente falharão com o status 404.
Exemplo:
$ istioctl get gateways GATEWAY NAME HOSTS NAMESPACE AGE bookinfo-gateway * default 20s httpbin-gateway * default 3s
Nesse caso, você precisa excluir ou alterar um dos gateways em conflito.
Pesquisar onde a rota está falhando
O Istio é como uma cebola (talvez um Ogro), que tem camadas. Uma maneira sistemática de depurar um erro 404 é de dentro para fora.
Carga de trabalho de back-end
Verifique se é possível acessar a carga de trabalho do arquivo secundário:
kubectl exec $WORKLOAD_POD -c istio-proxy -- curl localhost:80/headers
Arquivo secundário de back-end
Defina o endereço do serviço e receba o endereço IP do pod da carga de trabalho.
SERVICE=httpbin.default.svc.cluster.local:80 POD_IP=$(kubectl get pod $WORKLOAD_POD -o jsonpath='{.status.podIP}')
Acesse a carga de trabalho pelo arquivo secundário:
kubectl exec $WORKLOAD_POD -c istio-proxy -- curl -v http://$SERVICE/headers --resolve "$SERVICE:$POD_IP"
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
Gateway ou arquivo secundário de front-end
Acesse o serviço pelo gateway:
kubectl -n istio-system exec $GATEWAY_POD -- curl -v http://$SERVICE/header
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
Análises ausentes
Se você não visualizar as análises na IU do Analytics, considere estas possíveis causas:
- O consumo da Apigee pode demorar alguns minutos.
- O registro de acesso do gRPC do Envoy não foi configurado corretamente.
- O Envoy não consegue acessar o serviço remoto.
- Falha no upload do serviço remoto.
Chave de API ausente ou inválida que não foi rejeitada
Se a validação da chave de API não estiver funcionando corretamente, considere estas possíveis causas:
Proxy direto
Verifique a configuração de ext-authz
.
- Verifique se o listener está configurado para interceptação.
- Verifique a configuração de
ext-authz
.
Solicitações inválidas estão sendo verificadas e permitidas
- Serviço remoto configurado para falha na abertura.
- Envoy não configurado para verificações RBAC.
Para informações sobre como resolver esses problemas, consulte o seguinte tópico da documentação do
Envoy: Autorização externa (em inglês)
e consulte as informações sobre a propriedade failure_mode_allow
. Essa propriedade
permite alterar o comportamento do filtro em caso de erros.
JWT ausente ou inválido que não foi rejeitado
A causa provável é que o filtro JWT do Envoy não está configurado.
Falha em uma chave de API válida
Causas prováveis
- O Envoy não consegue acessar o serviço remoto
- Suas credenciais não são válidas
- Produto da API da Apigee não configurado para destino e ambiente
- O Envoy não tem acesso ao produto da API Apigee
Etapas da solução de problemas
Verificar seu produto de API na Apigee
- Ele está ativado em seu ambiente (teste x produção)?
O produto precisa estar vinculado ao mesmo ambiente que o serviço remoto.
- Ele está vinculado ao destino que você está acessando?
Verifique a seção Apigee remote service targets. Lembre-se de que o nome do serviço precisa ser um nome de host totalmente qualificado. Se for um serviço do Istio, o nome será algo como
helloworld.default.svc.cluster.local
code>, que representa o serviçohelloworld
no namespacedefault
. - O caminho do recurso corresponde à sua solicitação?
Lembre-se de que um caminho como
/
ou/**
corresponderá a qualquer caminho. Também é possível usar os caracteres curinga "*" ou "**" para fazer a correspondência. - Você tem um app do desenvolvedor?
O produto da API precisa estar vinculado a um app do desenvolvedor para verificar as chaves dele.
- O transactionConfigType da API Apigee está definido como remotoservice?
Verifique a configuração do produto da API usando a API Apigee Management e confirme se
operationConfigType
está definido comoremoteservice
.
Verificar sua solicitação
- Você está transmitindo a chave do consumidor no
x-api-key header
Exemplo:
curl http://localhost/hello -H "x-api-key: wwTcvmHvQ7Dui2qwj43GlKJAOwmo"
- Você está usando uma boa chave do consumidor?
Verifique se as credenciais do app que você está usando foram aprovadas para seu produto de API.
Verificar os registros do serviço remoto
- Inicie o serviço remoto com a geração de registros em
debug level
. Consulte Como configurar níveis de registro de serviço remoto.Use a opção
-l debug
na linha de comando. Por exemplo:apigee-remote-service-envoy -l debug
- Tente acessar seu destino e verifique os registros
Verifique os registros de uma linha que tenham esta aparência:
Resolve api: helloworld.default.svc.cluster.local, path: /hello, scopes: [] Selected: [helloworld] Eliminated: [helloworld2 doesn't match path: /hello]
Como configurar níveis de registro do serviço remoto
Com uma sinalização de linha de comando, é possível iniciar o serviço remoto em um dos seguintes modos de depuração, em ordem detalhada, em que debug
é mais detalhado e error
é o menor:
debug
: o modo de geração de registros mais detalhado.info
: o padrão.warn
error
: modo de geração de registros menos detalhado.
Por exemplo, para iniciar o serviço no nível debug
:
apigee-remote-service-envoy -l debug