현재 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 제품 확인
- 환경 (테스트 및 프로덕션)에 사용 설정되어 있나요?
제품이 원격 서비스와 동일한 환경에 바인딩되어야 합니다.
- 액세스 중인 타겟에 바인딩되어 있나요?
Apigee 원격 서비스 대상 섹션을 확인합니다. 서비스 이름은 정규화된 호스트 이름이어야 합니다. Istio 서비스의 경우 이름이
helloworld.default.svc.cluster.local
code>와 같이 지정됩니다. 이 이름은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]