이 페이지는 Cloud Translation API를 통해 번역되었습니다.

문제 해결

<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]