El operador de controladores de MongoDB para Kubernetes implementa mongot como un proceso separado en su propio Pod, definido por un MongoDBSearch recurso. Los clientes nunca se conectan mongot directamente a: las consultas de búsqueda de MongoDB y búsqueda vectorial se ejecutan mongod en, que las redirige mongot a. mongot se conecta de nuevo a mongod para transmitir eventos de cambio y crear sus índices en un volumen persistente dedicado.
Esta página describe cómo diagnosticar y resolver problemas comunes de ejecución en una implementación.mongot Para solucionar problemas específicos relacionados con la creación de índices durante la configuración inicial, consulte Uso de MongoDB Search y Vector Search. Para configurar métricas y registros antes de investigar, consulte Supervisar su implementación.
Los procedimientos de esta página presuponen que usted ha configurado las siguientes variables de entorno para que coincidan con su implementación:
export MDB_NS="<your-namespace>" export K8S_CTX="<your-kubectl-context>" export MDB_RESOURCE_NAME="<your-mongodbsearch-resource-name>"
Recopilar información de diagnóstico
Antes de trabajar en un escenario específico, recopile el estado actual del pod mongot, sus registros y los eventos recientes de 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'
Si el pod se reinicia en un bucle, revise los registros de la instancia de contenedor anterior para capturar el error que provocó el reinicio:
kubectl logs statefulset/${MDB_RESOURCE_NAME}-search-0 \ -n ${MDB_NS} --context ${K8S_CTX} --previous
El mongot pod no se inicia.
Síntomas: El mongot pod permanece Pending en, ContainerCreating o Error y nunca llega Running a, o el MongoDBSearch recurso no llega al Running estado.
Diagnóstico: Ejecute los comandos en Recopilar información de diagnóstico y revise los eventos del pod y el MongoDBSearch estado. Los indicadores comunes incluyen fallas de programación, errores de montaje de volumen y errores de descarga de imágenes.
Resolver:
Si no se puede programar el pod, confirme que hay un nodo con suficiente CPU y memoria disponible y que su StorageClass puede vincular la solicitud de volumen persistente solicitada. Para obtener más información sobre el
mongotdimensionamiento, consulte Planificación y dimensionamiento de recursos de búsqueda y búsqueda vectorial.Si falta la contraseña Secret para el usuario
search-sync-source, créela. El recursoMongoDBSearchespera una contraseña Secret llamada${MDB_RESOURCE_NAME}-search-sync-source-password.Si no se puede descargar la imagen del contenedor
mongot, verifique el nombre de la imagen y sus credenciales de registro. Compruebe si hay errores de descarga de imágenes conkubectl get events -n ${MDB_NS} | grep -i pull.Si el conjunto de réplicas de origen
mongodno está en el estadoRunning, resuelva primero ese problema. El operador de controladores de MongoDB para Kubernetes espera el recurso de origen antes de implementarmongot.
Las consultas de búsqueda no llegan a mongot
Síntomas: $searchLas consultas $searchMeta o $vectorSearch fallan con un error que indica que mongod no puede acceder al servicio de búsqueda.
Diagnóstico: Confirme que el mongot pod es Running y que su servicio existe:
kubectl get pods,svc -n ${MDB_NS} --context ${K8S_CTX} \ | grep search
Revise los registros mongot para detectar errores de conexión o autenticación, y revise los registros mongod para detectar errores que hagan referencia al host de búsqueda.
Resolver:
Si el
mongotpod noRunninges, proceda con El pod mongot no se inicia.Si los registros muestran errores de autenticación, verifique las
search-sync-sourcecredenciales y el rol del usuario. Para obtener más información, consulte "Proteger la conexión de Search a MongoDB".Si los registros muestran errores de TLS, confirme que
mongody confíanmongoten la misma CA. Para obtener más información,consulte Proteger la conexión de MongoDB a la búsqueda.
mongot Reinicia repetidamente
Síntomas: El mongot pod muestra un alto número de reinicios o CrashLoopBackOff informa.
Diagnóstico: Consulte los registros de la instancia de contenedor anterior para identificar el error que provocó el reinicio:
kubectl logs statefulset/${MDB_RESOURCE_NAME}-search-0 \ -n ${MDB_NS} --context ${K8S_CTX} --previous
Verifique el último estado del pod y el motivo de salida:
kubectl describe pod ${MDB_RESOURCE_NAME}-search-0-0 \ -n ${MDB_NS} --context ${K8S_CTX}
Resolver:
Si el motivo de salida
OOMKilledes, aumente los recursos de memoriamongotpara.Consulte mongot Runs Out Memory.Si los registros muestran un error de configuración o autenticación, corrija la configuración y deje que el operador de controladores de MongoDB para Kubernetes aplique el cambio.
Si los registros muestran que
mongotno puede leer ni escribir sus datos de índice, confirme que la solicitud de volumen persistente esté vinculada y sea escribible. Consulte El pod de mongot no se inicia.
mongot Se queda sin memoria
Síntomas: El mongot pod se termina con una OOMKilled razón y el contador de reinicios aumenta.
Diagnóstico: Confirme el motivo de la terminación del pod:
kubectl describe pod ${MDB_RESOURCE_NAME}-search-0-0 \ -n ${MDB_NS} --context ${K8S_CTX}
mongot Se trata de una carga de trabajo basada en Lucene y mapeada en memoria. La presión sobre la memoria suele deberse a límites de memoria insuficientes en relación con el tamaño del índice y la carga de consultas.
Resolver:
Aumenta los recursos de memoria asignados a
mongoten el recursoMongoDBSearch.mongotse reinicia para aplicar el cambio.Revise el tamaño de su índice y la carga de consultas comparándolos con las directrices de dimensionamiento en la sección "Planificación y dimensionamiento de recursos de búsqueda y búsqueda vectorial".
La sincronización inicial es lenta o el retraso en la replicación aumenta.
Síntomas: Los índices recién creados permanecen en estado de construcción durante mucho tiempo, o los resultados de las consultas se retrasan con respecto a las escrituras recientes mongod en.
Diagnóstico: Revise los mongot registros para ver el progreso de la replicación y los errores. Utilice las métricas que configuró en Supervisar su implementación para realizar un seguimiento del progreso de la creación del índice y el retraso de la replicación a lo largo del tiempo.
Resolver:
Permita que finalice la sincronización inicial. El tiempo necesario para crear un índice depende del tamaño de los datos de origen.
Si el retraso persiste bajo una carga constante,
mongotes posible que la instancia no disponga de recursos suficientes para el volumen de escritura. Consulte la sección sobre planificación y dimensionamiento de recursos para búsqueda y búsqueda vectorial.Confirme que el rendimiento del almacenamiento cumple con las recomendaciones para una carga de trabajo de Lucene con un uso intensivo de lecturas aleatorias. Un almacenamiento lento es una causa común de retrasos persistentes.
Fallos en el protocolo de enlace TLS entre mongod y mongot
Síntomas: Los mongot registros muestran errores de handshake TLS o de validación de certificados, y mongod no puede establecer una conexión mongot con.
Diagnóstico: Revise los mongot registros en busca de errores de certificado y confirme que MongoDBSearch existen los secretos TLS a los que hace referencia el recurso:
kubectl get secrets -n ${MDB_NS} --context ${K8S_CTX} \ | grep -i tls
Resolver:
Confirma que y confían
mongodmongoten la misma CA.Después de reemplazar o rotar un certificado, reinicie
mongotpara que lea el nuevo certificado.mongotlee los certificados al inicio y no los vuelve a cargar mientras se ejecuta.Para obtener más información, consulte Cómo proteger la conexión de MongoDB a la búsqueda.
Fallo en la incrustación automatizada
Nota
La integración automatizada es una función en vista previa y solo se integra con los modelos de Voyage AI.
Síntomas: Los mongot índices que utilizan la incrustación automatizada no se construyen o las solicitudes de incrustación devuelven errores en los registros.
Diagnóstico: Revise los mongot registros en busca de errores que hagan referencia al proveedor de incrustación, como fallas de autenticación o tiempos de espera de solicitud.
Resolver:
Verifique que su clave API de Voyage AI sea válida y que el secreto que la contiene exista en el espacio de nombres.
Confirma que
mongotpuede alcanzar el punto final del proveedor de incrustación desde tu clúster de Kubernetes.
Diagnósticos de captura para soporte
Si se pone en contacto con el soporte de MongoDB, incluya los mongot registros, la MongoDBSearch descripción del recurso y los eventos recientes del espacio de nombres:
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
También puede incluir archivos FTDC de cada pod de búsqueda afectado. mongot escribe archivos FTDC en /mongot/data/diagnostic.data/ dentro del pod.
La ruta /mongot/data es un PersistentVolumeClaim que el operador de Kubernetes monta en el pod a través de un volumeClaimTemplate en el StatefulSet de búsqueda, por lo que los datos de diagnóstico persisten entre reinicios del pod. Cuando se reemplaza un pod, el StatefulSet vuelve a adjuntar el mismo PersistentVolumeClaim, por lo que se conservan los datos de diagnóstico.
Copie los datos FTDC del pod de búsqueda a su máquina local. Para clústeres fragmentados, copie los datos FTDC de cada pod de búsqueda por fragmento a su máquina local. Repita el proceso para cada fragmento:
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}