문제 해결

<ph type="x-smartling-placeholder"></ph> 현재 Apigee Edge 문서를 보고 있습니다.
Apigee X 문서.
정보

Istio 404(찾을 수 없음) 오류

Istio에서 404(찾을 수 없음) 오류를 디버깅하면 실망할 수 있습니다. 문제가 발생했을 수 있는 위치를 추적할 수 있기를 바랍니다.

와일드 카드 게이트웨이 충돌

와일드 카드 '*' 호스트 값을 사용하는 게이트웨이 정의는 하나만 가능합니다. 와일드 카드 게이트웨이가 포함된 항목을 배포한 경우, 클라이언트 호출 시 404 상태로 실패합니다.

예:

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

이 경우에는 충돌하는 게이트웨이 중 하나를 삭제하거나 변경해야 합니다.

경로가 실패한 trace

Istio에는 양파(또는 오그르)처럼 레이어가 있습니다. 404를 디버깅하는 체계적인 방법은 대상의 바깥쪽으로 작업하는 것입니다.

백엔드 워크로드

사이드카에서 워크로드에 액세스할 수 있는지 확인합니다.

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

백엔드 사이드카

서비스 주소를 설정하고 워크로드 Pod의 IP 주소를 가져옵니다.

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

사이드카를 통해 워크로드에 액세스합니다.

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

또는 Istio mTLS가 사용 설정됩니다.

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

게이트웨이(또는 프런트엔드 사이드카)

게이트웨이에서 서비스에 액세스합니다.

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

또는 Istio mTLS가 사용 설정됩니다.

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

애널리틱스 누락됨

애널리틱스 UI에 애널리틱스가 표시되지 않는다면 다음과 같은 원인을 고려해 보세요.

  • Apigee 입고는 몇 분 지연될 수 있습니다.
  • Envoy gRPC 액세스 로그가 올바르게 구성되지 않았습니다.
  • Envoy가 원격 서비스에 연결할 수 없습니다.
  • 원격 서비스가 업로드를 실패했습니다.

누락되거나 잘못된 API 키가 거부되지 않음

API 키 검증이 제대로 작동하지 않는다면 다음과 같은 원인을 고려해 보세요.

직접 프록시

ext-authz 구성을 확인합니다.

사이드카
  • 리스너가 인터셉트에 대해 구성되어 있는지 확인하세요.
  • ext-authz 구성을 확인합니다.

잘못된 요청 확인 및 허용 중

  • 오류 발생 시 원격 서비스를 구성합니다.
  • RBAC 확인에 대해 Envoy가 구성되지 않았습니다.

이 문제를 해결하는 방법에 대한 자세한 내용은 외부 승인이라는 Envoy 문서를 참조하고, failure_mode_allow 속성에 대한 정보를 참조합니다. 이 속성을 사용하면 오류 시 필터의 동작을 변경할 수 있습니다.

누락되거나 잘못된 JWT가 거부되지 않음

Envoy JWT 필터가 구성되지 않았기 때문일 수 있습니다.

유효한 API 키 실패

가능한 원인

  • Envoy가 원격 서비스에 연결할 수 없습니다.
  • 사용자 인증 정보가 올바르지 않습니다.
  • 대상 및 env에 대해 Apigee API 제품이 구성되지 않았습니다.

문제해결 단계

Apigee에서 API 제품 확인

  • 환경(test와 prod)에 사용 설정되어 있나요?

    제품이 원격 서비스와 동일한 환경에 바인딩되어야 합니다.

  • 액세스하는 대상에 결합되어 있나요?

    Apigee 원격 서비스 대상 섹션을 확인합니다. 서비스 이름은 정규화된 호스트 이름이어야 합니다. Istio 서비스의 경우 이름이 helloworld.default.svc.cluster.localcode>와 같이 지정됩니다. 이 이름은 default 네임스페이스의 helloworld 서비스를 나타냅니다.

  • 리소스 경로가 요청과 일치하나요?

    / 또는 /**와 같은 경로는 모든 경로와 일치합니다. 또한 일치에 '*' 또는 '**' 와일드 카드를 사용할 수도 있습니다.

  • 개발자 앱이 있나요?

    키 확인을 위해서는 API 제품이 개발자 앱에 바인딩되어야 합니다.

요청 확인

  • x-api-key header에서 고객 키를 전달하나요?

    예:

    curl http://localhost/hello -H "x-api-key: wwTcvmHvQ7Dui2qwj43GlKJAOwmo"
  • 올바른 고객 키를 사용하나요?

    사용 중인 앱의 사용자 인증 정보가 API 제품에 승인되었는지 확인합니다.

원격 서비스 로그 확인

  • debug level에서 로깅으로 원격 서비스 시작

    명령줄에서 -l debug 옵션을 사용합니다.

  • 대상 액세스를 시도하고 로그 확인

    로그에서 다음과 비슷한 줄을 찾습니다.

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