Kubernetes 연산자용 MongoDB 컨트롤러는 mongot 를 별도의 Pod에 별도 프로세스로 배포하며, MongoDBSearch 리소스로 정의됩니다. 클라이언트는 mongot 에 직접 연결하지 않습니다. MongoDB Search 및 벡터 검색 쿼리는 mongod에서 실행되며, 은 쿼리를 mongot로 프록시합니다. mongot 는 mongod 에 다시 연결하여 변경 이벤트를 스트리밍하고 전용 영구 볼륨에 인덱스를 빌드합니다.
이 페이지에서는 mongot 배포에서 발생하는 일반적인 런타임 문제를 진단하고 해결하는 방법을 설명합니다. 초기 설정 동안 인덱스 생성에 관한 트러블슈팅은 MongoDB Search 및 벡터 검색 사용을 참조하십시오. 조사하기 전에 지표와 로깅을 설정하려면 배포서버 모니터를 참조하십시오.
이 페이지의 절차에서는 배포서버에 맞게 다음 환경 변수를 설정했다고 가정합니다.
export MDB_NS="<your-namespace>" export K8S_CTX="<your-kubectl-context>" export MDB_RESOURCE_NAME="<your-mongodbsearch-resource-name>"
진단 정보 수집
특정 시나리오를 실행하기 전에 mongot 팝의 현재 상태, 로그 및 최근 Kubernetes 이벤트를 수집합니다.
Check the status and restart count of the mongot pod kubectl get pods -n ${MDB_NS} --context ${K8S_CTX} | grep search Review the most recent mongot logs kubectl logs statefulset/${MDB_RESOURCE_NAME}-search-0 \ -n ${MDB_NS} --context ${K8S_CTX} --tail=100 Inspect the MongoDBSearch resource status and conditions kubectl describe mongodbsearch ${MDB_RESOURCE_NAME} \ -n ${MDB_NS} --context ${K8S_CTX} List recent events in the namespace kubectl get events -n ${MDB_NS} --context ${K8S_CTX} \ --sort-by='.lastTimestamp'
포드가 루프에서 다시 시작되면 이전 컨테이너 인스턴스의 로그를 보아 재시작의 원인이 된 오류를 확인합니다.
kubectl logs statefulset/${MDB_RESOURCE_NAME}-search-0 \ -n ${MDB_NS} --context ${K8S_CTX} --previous
mongot Pod가 시작되지 않습니다.
증상: mongot 팝이 Pending, ContainerCreating 또는 Error 에 머물러 Running에 도달하지 않거나 MongoDBSearch 리소스가 Running 상태에 도달하지 않습니다.
진단: 진단 정보 수집 에서 명령을 실행하고 팟 이벤트와 MongoDBSearch 상태를 검토합니다. 일반적인 지표에는 스케줄링 실패, 볼륨 마운트 오류 및 이미지 풀 오류가 포함됩니다.
해결:
팝을 스케줄할 수 없는 경우 충분한 CPU 및 메모리가 있는 노드 가 사용 가능하고 StorageClass 가 요청된 영구 볼륨 요청을 바인딩할 수 있는지 확인합니다.
mongot사이징에 대한 자세한 내용은 검색 및 벡터 검색 리소스 계획 및 사이징을 참조하세요.search-sync-source사용자에 대한 비밀번호 시크릿이 없는 경우 생성합니다.MongoDBSearch리소스에서는${MDB_RESOURCE_NAME}-search-sync-source-password라는 이름의 시크릿이 필요합니다.mongot컨테이너 이미지를 가져올 수 없는 경우 이미지 이름과 레지스트리 자격 증명을 확인합니다.kubectl get events -n ${MDB_NS} | grep -i pull의 이미지 가져오기 오류를 확인합니다.소스
mongod복제본 세트가Running상태가 아니면 먼저 해결합니다. Kubernetes 연산자용 MongoDB 컨트롤러는mongot를 배포하기 전에 소스 리소스를 기다립니다.
검색 쿼리가 도달하지 않음 mongot
증상: $search, $searchMeta, 또는 $vectorSearch 쿼리가 mongod 가 검색 서비스에 연결할 수 없음을 나타내는 오류로 실패합니다.
진단: mongot 팟이 Running 인지 확인하고 서비스 가 존재하는지 확인합니다.
kubectl get pods,svc -n ${MDB_NS} --context ${K8S_CTX} \ | grep search
연결 또는 인증 오류에 대해 mongot 로그를 검토하고, 검색 호스트를 참조하는 오류에 대해 mongod 로그를 검토합니다.
해결:
mongot팟이Running아닌 경우 mongot 팟이 시작되지 않음을 통해 작업합니다.로그에 인증 오류가 표시되면
search-sync-source사용자 자격 증명과 역할을 확인합니다. 자세한 내용은 검색에서 MongoDB로의 연결 보안을 참조하세요.로그에 TLS 오류가 표시되면
mongod와mongot이 동일한 CA를 신뢰하는지 확인합니다. 자세한 학습은 MongoDB에서 검색으로의 연결 보안을 참조하세요.
mongot 반복 재시작
증상: mongot 팝에 재시작 횟수가 높거나 CrashLoopBackOff이(가) 보고됩니다.
진단: 이전 컨테이너 인스턴스의 로그를 보아 재시작을 트리거한 오류를 캡처합니다.
kubectl logs statefulset/${MDB_RESOURCE_NAME}-search-0 \ -n ${MDB_NS} --context ${K8S_CTX} --previous
포드의 마지막 상태와 종료 이유를 확인합니다.
kubectl describe pod ${MDB_RESOURCE_NAME}-search-0-0 \ -n ${MDB_NS} --context ${K8S_CTX}
해결:
종료 이유가
OOMKilled인 경우mongot의 메모리 리소스를 늘립니다. mongot 메모리 부족을 참조하세요.로그에 구성 또는 인증 오류가 표시되면 설정을 수정하고 Kubernetes 연산자용 MongoDB 컨트롤러가 변경사항을 조정하도록 합니다.
로그에
mongot이 인덱스 데이터를 읽거나 쓸 수 없다고 표시되면 영구 볼륨 요청 이 바인딩되어 있고 쓰기 가능한지 확인하세요. mongot 팟이 시작되지 않습니다.를 참조하세요.
mongot 메모리 부족
증상: mongot 팟이 OOMKilled 이유로 종료되고 재시작 횟수가 증가합니다.
진단: 팝의 종료 이유를 확인합니다.
kubectl describe pod ${MDB_RESOURCE_NAME}-search-0-0 \ -n ${MDB_NS} --context ${K8S_CTX}
mongot Lucene 기반의 메모리 매핑된 워크로드입니다. 메모리 부하는 인덱스 크기와 쿼리 로드에 비해 메모리 제한이 작을 때 자주 발생합니다.
해결:
MongoDBSearch리소스의mongot에 할당된 메모리 리소스를 늘립니다.mongot가 다시 시작되면 변경사항이 적용됩니다.검색 및 벡터 검색 리소스 계획 및 사이징의 사이징 지침에 대해 인덱스 크기와 쿼리 부하를 검토하세요.
초기 동기화가 느리거나 복제 지연이 증가합니다.
증상: 새로 생성된 인덱스가 오래 동안 빌드 상태에 머물거나 쿼리 결과가 mongod에 대한 최근 쓰기(write)보다 늦어집니다.
진단: 복제 진행 및 오류에 대한 mongot 로그를 검토합니다. 배포서버 모니터 에서 구성한 지표를 사용하여 인덱스 생성 진행 및 복제 지연을 시간에 따라 추적합니다.
해결:
초기 동기화가 완료되도록 허용합니다. 인덱스 빌드 시간은 소스 데이터 크기에 따라 확장됩니다.
일정한 부하에서 지연이 계속되면
mongot인스턴스에 쓰기 (write) 볼륨에 충분한 리소스가 없을 수 있습니다. 검색 및 벡터 검색 리소스 계획 및 사이징을 검토.저장 성능이 무작위 읽기 중심의 Lucene 워크로드에 대한 권장 사항을 충족하는지 확인하세요. 느린 저장은 지속적인 지연의 일반적인 원인입니다.
mongod 과 mongot사이의 TLS 핸드쉐이크 실패
증상: mongot 로그에 TLS 핸드쉐이크 또는 인증서 유효성 검사 오류가 표시되고 mongod 가 mongot에 대한 연결을 수립할 수 없습니다.
진단: mongot 로그에서 인증서 오류를 검토하고 MongoDBSearch 리소스에서 참조하는 TLS 시크릿이 존재하는지 확인합니다.
kubectl get secrets -n ${MDB_NS} --context ${K8S_CTX} \ | grep -i tls
해결:
mongod과mongot이 동일한 CA를 신뢰하는지 확인합니다.인증서를 대체하거나 로테이션한 후에는
mongot을 다시 시작하여 새 인증서를 읽도록 합니다.mongot은 시작 시 인증서를 읽지만 실행 중에는 다시 로드하지 않습니다.자세한 학습은 MongoDB에서 검색으로의 연결 보안을 참조하세요.
자동화된 임베딩 실패
참고
자동 임베딩은 미리 보기 기능이며 Voyage AI 모델에만 통합됩니다.
증상: 자동 임베딩을 사용하는 인덱스가 빌드되지 않거나 mongot 로그에서 임베딩 요청이 오류를 반환합니다.
진단: 인증 실패 또는 요청 타임아웃과 같이 임베딩 제공자를 참조하는 오류가 있는지 mongot 로그를 검토합니다.
해결:
Voyage AI API 키가 유효하고 키를 보관하는 Secret이 네임스페이스에 존재하는지 확인합니다.
Kubernetes 클러스터에서
mongot가 임베딩 제공자 엔드포인트에 액세스할 수 있는지 확인합니다.
지원을 위한 진단 캡처
MongoDB 지원에 문의하는 경우 mongot 로그, MongoDBSearch 리소스 설명 및 최근 네임스페이스 이벤트를 포함하세요.
kubectl logs statefulset/${MDB_RESOURCE_NAME}-search-0 \ -n ${MDB_NS} --context ${K8S_CTX} > mongot.log kubectl describe mongodbsearch ${MDB_RESOURCE_NAME} \ -n ${MDB_NS} --context ${K8S_CTX} > mongodbsearch-describe.txt kubectl get events -n ${MDB_NS} --context ${K8S_CTX} \ --sort-by='.lastTimestamp' > events.txt
영향을 받은 각 검색 팝에서 FTDC 파일을 포함할 수도 있습니다. mongot 는 팝 내부의 /mongot/data/diagnostic.data/ 에 FTDC 파일을 쓰기합니다.
/mongot/data 경로는 Kubernetes Operator가 검색 StatefulSet에 volumeClaimTemplate 를 통해 팝에 마운트하는 PersistentVolumeClaim 이므로 진단 데이터가 팝 재시작에서도 유지됩니다. 팝이 대체되면 StatefulSet은 동일한 PersistentVolumeClaim를 다시 연결하므로 진단 데이터가 유지됩니다.
검색 팝에서 로컬 마신으로 FTDC 데이터를 복사합니다. 샤딩된 클러스터의 경우, 각 샤드별 검색 팝에서 로컬 마신으로 FTDC 데이터를 복사합니다. 모든 샤드에 대해 반복합니다.
kubectl cp -n ${MDB_NS} --context ${K8S_CTX} \ {MDB_SEARCH_RESOURCE_NAME}-search-0-${MDB_EXTERNAL_SHARD_0_NAME}-0:/mongot/data/diagnostic.data \ ./mongot-diagnostic.data-${MDB_EXTERNAL_SHARD_0_NAME}