이 주제에서는 메시지 프로세서의 문제를 해결하는 단계를 설명하고 문제를 해결합니다. 메시지 프로세서는 apigee-runtime
구성요소의 일부입니다. 런타임 서비스 구성 개요도 참조하세요.
HTTP 상태 코드 500으로 준비 프로브 실패
증상
하나 이상의 apigee-runtime
pod가 준비 상태가 아닙니다.
오류 메시지
kubectl
을 사용하여 실패한 apigee-runtime
pod를 설명하면 다음 오류가 표시됩니다.
Readiness probe failed: HTTP probe failed with statuscode: 500
예를 들면 다음과 같습니다.
kubectl describe pod -n hybrid \ apigee-runtime-apigee-gcp-prod1-test-blue-67db4f457b-9c7c7 ... apigee-runtime-apigee-gcp-prod1-test-blue-67db4f457b-9c7c7 Readiness probe failed: HTTP probe failed with statuscode: 500 ...
가능한 원인
이 오류는 메시지 프로세서가 트래픽을 제공하는 데 사용할 수 있는 활성 계약이 없음을 의미합니다. 이 상태에서는 메시지 프로세서가 자체적으로 '준비'라고 할 수 없습니다.
원인 | 설명 |
---|---|
Synchronizer에서 관리 영역으로의 연결 문제 | Synchronizer에서 관리 영역으로 연결할 수 없습니다. 이 문제는 일반적으로 contractProvider URL을 재정의하고 잘못된 서비스 계정으로 연결하는 경우에 발생합니다. 예를 들어 프로덕션 서버를 가리키는 contractProvider URL로 스테이징 배포에 대한 서비스 계정을 구성하는 경우입니다.
|
메시지 프로세서에서 동기화 담당자로의 연결 문제 | 새 MP가 자동 확장 또는 pod 다시 시작의 일부로 나타나는 경우 이 오류가 표시될 수 있습니다. 일반적으로 이 문제는 synchronizer가 다운되고 MP가 계약을 로드할 수 없을 때 발생합니다. |
진단: Synchronizer에서 관리 영역으로의 연결 문제
Synchronizer와 관리 영역 연결 문제를 진단하려면 다음 안내를 따르세요.
- 클러스터의 포드를 나열합니다.
kubectl get pods -n namespace
apigee-synchronizer
포드에서 셸을 엽니다.kubectl exec -it -n namespace synchronizer-pod-name bash
예를 들면 다음과 같습니다.
kubectl exec -it -n apigee apigee-synchronizer-apigee-gcp-prod1-test-blue-cnj5x bash
- 다음 디렉터리로 이동합니다.
cd /opt/apigee/var/log/apigee-synchronizer
ls
dr-xr-sr-x 4 apigee apigee 4096 Sep 12 16:52 750 drwxr-sr-x 2 apigee apigee 4096 Sep 12 16:52 cachedFiles -rw-r--r-- 1 apigee apigee 22295 Sep 12 16:52 config.log -rw-r--r-- 1 apigee apigee 76 Sep 12 16:52 versions.properties version.properties
에서 활성 버전을 확인하세요. 예를 들면 다음과 같습니다.cat versions.properties #active repository version #Sat Dec 14 19:45:00 GMT 2019 active.version=749
active.version
값이 계약 폴더 번호의 이름과 일치하는지 확인합니다. 위 예시에서(아래에서도 표시됨) 폴더 이름은750
이므로 일치하지 않습니다.dr-xr-sr-x 4 apigee apigee 4096 Sep 12 16:52 750
- Pod 셸을 종료합니다.
해결 방법
version.properties
가 없거나 위에 설명된 대로 버전 불일치가 발생한 경우 동기화 담당자 로그를 확인하여 가장 최신 계약이 다운로드되고 있지 않은 이유를 확인합니다. 예를 들면 다음과 같습니다.
kubectl logs -f -n namespace synchronizer-pod-name
동기화 담당자 로그 해석에 대한 자세한 내용은 동기화 담당자 로그를 참조하세요.
Synchronizer가 다운되면 apigeectl
을 사용하여 다시 시작해 봅니다. 예를 들면 다음과 같습니다.
$APIGEECTL_HOME/apigeectl apply -f overrides/overrides.yaml --org --env env-name
진단: 메시지 프로세서에서 Synchronizer로의 연결 문제
메시지 프로세서와 Synchronizer의 연결 문제를 진단하려면 다음을 수행하세요.
- 클러스터의 포드를 나열합니다.
kubectl get pods -n namespace
- 계약이 다운로드되지 않는 이유를 알아보려면 런타임 로그를 확인합니다.
kubectl logs -f -n namespace pod-name
예를 들면 다음과 같습니다.
kubectl logs -f -n apigee apigee-runtime-apigee-gcp-prod1-test-blue-67db4f457b-9c7c7
새 MP가 자동 확장 또는 Pod 재시작의 일부로 나타나는 경우 MP가 계약을 로드하지 못할 수 있습니다. 일반적으로 Synchronizer가 다운되면 문제가 발생하고 MP가 계약을 로드하지 못하게 됩니다. 예를 들면 다음과 같습니다.
2019-09-13 16:59:24,331 podName:N/A ipAddress:N/A dpColor:N/A HttpClient@331886186-301 DEBUG o.e.j.c.AbstractConnectionPool - AbstractConnectionPool$1.failed() : Connection 1/64 creation failed java.net.UnknownHostException: apigee-synchronizer-apigee-gcp-prod1-test.hybrid.svc.cluster.local at java.net.InetAddress.getAllByName0(InetAddress.java:1281) at java.net.InetAddress.getAllByName(InetAddress.java:1193) at java.net.InetAddress.getAllByName(InetAddress.java:1127) at org.eclipse.jetty.util.SocketAddressResolver$Async.lambda$resolve$1(SocketAddressResolver.java:167) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:672) at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:590) at java.lang.Thread.run(Thread.java:748) at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:590) at java.lang.Thread.run(Thread.java:748)
해결 방법
Synchronizer를 다시 시작해 보세요. 예를 들면 다음과 같습니다.
$APIGEECTL_HOME/apigeectl apply -f overrides/overrides.yaml --org --env env-name
잘못된 암호화 키에 대한 준비 프로브 실패
증상
apigee-runtime
pod가 준비 상태가 아닙니다.
진단
kubectl
을 사용하여 실패한 apigee-runtime
pod를 설명하면 다음 오류가 표시됩니다. Readiness probe failed: Probe hybrid-encryption-key-validation-probe failed
.
예를 들면 다음과 같습니다.
$ kubectl describe pod -n namespace apigee-runtime-pod-name ... Readiness probe failed: Probe hybrid-encryption-key-validation-probe failed due to com.apigee.probe.model.ProbeFailedException{ code = hybrid.encryption.key.InvalidEncryptionKey, message = Invalid encryption key. Please check the length of the encryption key, associated contexts = []} ...
해결 방법
지원되는 암호화 키 길이는 16, 24 또는 32바이트이며 키 값은 base64로 인코딩되어야 합니다. 올바른 형식의 키 만들기에 대한 자세한 내용은 데이터 암호화를 참조하세요.
메시지 프로세서 로그 보기
메시지 프로세서 로그를 보고 해석하는 방법에 대한 자세한 내용은 런타임 로그를 참조하세요.
런타임 pod에서 API 프록시 호출
문제를 격리하기 위해 apigee-runtime
pod 내에서 직접 API 프록시를 호출하여 인그레스 게이트웨이를 우회할 수 있는지 확인하는 것이 좋습니다.
- 다음 명령어를 실행하여 포트 8443으로 전달하세요. 그러면 포드에서 API를 호출할 수 있습니다.
kubectl port-forward -n namespace apigee-runtime-pod-name 8443:8443
- 배포된 API 프록시를 호출합니다. 예를 들어 프록시 기본 경로가
ilove-apis
인 경우 다음 명령어를 실행합니다.curl -k -v https://0:8443//ilove-apis < HTTP/1.1 200 OK < X-Powered-By: Apigee < Access-Control-Allow-Origin: * < X-Frame-Options: ALLOW-FROM RESOURCE-URL < X-XSS-Protection: 1 < X-Content-Type-Options: nosniff < Content-Type: text/html; charset=utf-8 < Content-Length: 18 < ETag: W/"12-Jb9QP1bUxNSmZkxQGt5KLQ" < Date: Fri, 13 Sep 2019 18:33:46 GMT < Via: 1.1 google < X-Apigee.Message-ID: 016f5f7f-c59e-404c-86e8-7b0737833f982 < X-Apigee.dp.color: blue < X-Apigee.proxy: /organizations/my-org/environments/test/apiproxies/i-loveapis/revisions/1 < X-Apigee.proxy.basepath: /ilove-apis < X-Apigee.target-latency: 9 < * Connection #0 to host 0 left intact <H2>I <3 APIs
Management API 확인
아래에 설명된 API를 사용하여 Management API가 제대로 작동하는지 확인할 수 있습니다.
- 클러스터에 있는 포드의 이름을 가져옵니다.
kubectl get pods -n namespace
- 포트 전달을 사용하여
apigee-runtime
pod에 액세스합니다. 포트 전달 구문은 다음과 같습니다.kubectl port-forward -n namespace podname 8843:8843
예를 들면 다음과 같습니다.
kubectl port-forward -n apigee \ apigee-runtime-my-organization-test-blue-57965b7789-6j4bp 8843:8843
- 그런 후 다음 예시와 같이 다른 터미널 창에서
curl
와 같은 유틸리티를 사용하여classification/tree
API에 요청을 보냅니다.curl -k https://0:8843/v1/classification/tree
다음은 '테스트' 환경에 배포된 프록시에 대한 정보를 나열하는 예시 응답입니다.
[ { "condition" : "(always matches)", "virtualHost" : { "env" : "test", "name" : "default", "org" : "my-organization", "tree" : { "elements" : [ { "application" : "myproxy", "basePath" : "/myproxy", "name" : "default", "revision" : "1" } ], "name" : "IdentificationTree" } } } ]
디버그 모드 사용
문제 해결에 도움이 되도록 디버그 모드를 사용 설정하면 apigee-runtime
pod 로그에 더 자세한 정보가 포함됩니다.
- 네임스페이스의 포드를 나열합니다.
kubectl get pods -n namespace
- 나열된
apigee-runtime
pod 중 하나를 선택하여 디버깅합니다. - 해당 pod에 대해 포트 전달 명령어를 실행합니다. 예를 들면 다음과 같습니다.
kubectl port-forward -n hybrid apigee-runtime-hybrid-prod-blue-fcpdd 8843
- 다른 터미널을 열고 다음 API를 호출하여 디버깅을 사용 설정합니다.
curl "https://0:8843/v1/logsessions?sessions=debug" -X POST -v -k
kubectl logs
명령어를 실행하여 디버그 모드에 있는 로그를 확인합니다. 예를 들면 다음과 같습니다.kubectl logs -f -n hybrid apigee-runtime-hybrid-prod-blue-fcpdd
- 디버그 로그 검토를 마쳤으면 로그 수준을 INFO(기본값)로 재설정합니다. 예를 들면 다음과 같습니다.
curl "https://0:8843/v1/logsessions?sessions=info" -X POST -v -k
kubectl logs
명령어를 실행하여 로그가 INFO 모드로 돌아가는지 확인합니다.