Solução de problemas

Você está vendo a documentação do Apigee Edge.
Acesse a documentação da Apigee X.
informações

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.

Exemplos

$ 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.

Descubra 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 estiver vendo análises na interface do Google 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.

Arquivo secundário
  • 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

Etapas da solução de problemas

Verificar seu produto de API na Apigee

  • Ele está ativado no 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.localcode>, que representa o serviço helloworld no namespace default.

  • 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.

Verificar sua solicitação

  • Você está transmitindo a chave do cliente no x-api-key header

    Exemplos

    curl http://localhost/hello -H "x-api-key: wwTcvmHvQ7Dui2qwj43GlKJAOwmo"
  • Você está usando uma boa chave do cliente?

    Verifique se as credenciais do app que você está usando foram aprovadas para seu produto de API.

Verificar os registros do serviço remoto

  1. 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. Exemplo:

    apigee-remote-service-envoy -l debug
  2. Tentar acessar seu destino e verificar 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]
    
  3. 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