El proceso mongot almacena los índices de MongoDB Search y los índices de búsqueda vectorial en un Volumen persistente dedicado. El operador de Kubernetes no expande ese almacenamiento automáticamente. En Kubernetes operador 1.9 o posterior, puede expandir el mongot Reclamaciones de volumen persistente, luego actualizar el recurso MongoDBSearch para reflejar el tamaño de volumen expandido. Para aumentar el almacenamiento de otros recursos, consulte Aumentar el almacenamiento de volúmenes persistentes.
Requisitos previos
mongotReclamaciones de volumen persistentes aprovisionadas mediante un controlador de interfaz de almacenamiento de contenedores (CSI) que admite la expansión de volumen mientras este permanece conectado, y una StorageClass que representa dicho controlador y estableceallowVolumeExpansionentrue. Confirme que el sistema de archivos admite la expansión. Este procedimiento no cubre los sistemas de almacenamiento que requieren desconectar el volumen antes de que el controlador pueda expandirlo.Una base de datos de origen en buen estado y una implementación de MongoDB Search y búsqueda vectorial, y un plan de copia de seguridad o recuperación. Para configurar la copia de seguridad de la base de datos de origen, consulte Configurar la copia de seguridad de la base de datos de MongoDB. Para aprender qué hacer una copia de seguridad para Search, consulte
mongotPreguntas frecuentes sobre la implementación.Un periodo de mantenimiento sin escalado concurrente ni actualizaciones del operador de Kubernetes o del recurso MongoDBSearch. Pausar la automatización que puede realizar la restauración de réplicas del operador de Kubernetes o revertir la configuración de almacenamiento de búsqueda, por ejemplo, sincronizar con GitOps. Si gestiona el recurso MongoDBSearch en Git, confirme el nuevo tamaño antes de reanudar sincronizar. Si detiene un operador, se detiene la conciliación para todos los recursos que gestiona.
Permiso para aplicar parches a Reclamaciones de volumen persistente, editar recursos de MongoDBSearch, escalar implementaciones del operador de Kubernetes y borrar statefulSets y Pods.
Implementaciones multi-clúster
Durante este procedimiento, ejecuta comandos contra el recurso MongoDBSearch, los mongot statefulSets y sus Persistent Volume Claims, y la implementación del operador de Kubernetes. En una implementación multiclúster, estos destinos pueden residir en diferentes clústeres. Utilice la siguiente tabla para determinar el contexto de cada comando y el operador para detener y reanudar:
Implementación | Contexto de recurso de MongoDBSearch | StatefulSet y Persistent Volume Claim contexto | Operador para detener y reanudar |
|---|---|---|---|
Clúster único | Clúster de carga de trabajo | El mismo clúster | Operador local |
Operador de Kubernetes multicúmulo central | Clúster central | Cada clúster de nodos afectado | Operador central |
Operador de Kubernetes por clúster de nodos | El recurso de búsqueda local de cada clúster nodo | El mismo clúster de nodos | Operador de búsqueda de cada nodo afectado |
Expandir el almacenamiento
El siguiente procedimiento amplía el almacenamiento de búsqueda del set de réplicas de 1Gi a 2Gi. Haga coincidir cada StatefulSet con la name y la index explícita de su entrada de clúster, no la posición de la entrada en el arreglo clusters.
Una configuración shardOverrides[].persistence coincidente reemplaza la configuración persistence del clúster. Si lo configura, cambie el tamaño allí. Si sobrescribe volumeClaimTemplates en spec.clusters[].statefulSet, cambie el tamaño allí. Esa anulación tiene prioridad sobre persistence.
Advertencia
Aumente solo el almacenamiento, mientras mantiene el recurso MongoDBSearch existente y sus Persistent Volume Claims, y no escalar mongot. Borre solo las StatefulSet definiciones, y asegúrese de usar la opción --cascade=orphan para que los mongot Pods y sus reclamaciones permanezcan intactos mientras el operador de Kubernetes está detenido.
Identifique los mongot StatefulSets y las reclamaciones de datos.
Enumere los mongot statefulSets para el recurso MongoDBSearch:
kubectl --context <member-context> -n <namespace> \ get sts -l mongodb.com/search-name=<search-name>
Con la plantilla de reclamación data por defecto, cada réplica utiliza una reclamación denominada data-<statefulset-name>-<ordinal>. Para un origen de clúster particionado, cada clúster tiene un StatefulSet para cada partición. Si personalizó las plantillas de reclamación o los montajes de volumen, compruebe la reclamación que cada Pod monta en su lugar.
Expandir cada afirmación de datos.
Ejecuta el siguiente comando para cada declaración que identificaste en el paso anterior:
kubectl --context <member-context> -n <namespace> \ patch pvc <pvc-name> --type=merge \ -p '{"spec":{"resources":{"requests":{"storage":"2Gi"}}}}'
Espere hasta que cada reclamación informe al menos el tamaño solicitado (en este ejemplo, 2Gi) en status.capacity.storage o la condición FileSystemResizePending:
kubectl --context <member-context> -n <namespace> \ get pvc <pvc-name> -o yaml
Si la expansión tarda más del tiempo de espera documentado de su backend de almacenamiento, investigue los eventos de CSI antes de continuar:
kubectl --context <member-context> -n <namespace> \ describe pvc <pvc-name>
Detener las implementaciones responsables del operador de Kubernetes.
Registre el recuento original de réplicas de cada operador:
kubectl --context <operator-context> -n <operator-namespace> \ get deployment <operator-name> \ -o jsonpath='{.spec.replicas}{"\n"}'
Escalar el operador a cero y esperar a que sus Pods sean borrados:
kubectl --context <operator-context> -n <operator-namespace> \ scale deployment <operator-name> --replicas=0 kubectl --context <operator-context> -n <operator-namespace> \ wait --for=delete pod --timeout=300s \ -l app.kubernetes.io/name=<operator-name>
Escalar el operador, no mongot. La gráfica de Helm nombra la implementación del operador mongodb-kubernetes-operator y establece app.kubernetes.io/name: mongodb-kubernetes-operator en sus Pods. Si su instalación está personalizada, utilice el selector de pods real de la implementación en lugar de la etiqueta de la gráfica que se muestra en este ejemplo. Detenga todos los operadores responsables Pods, incluidos los Pods que se están terminando Pods, antes de continuar. Detener un operador de base de datos de origen independiente no pausa los operadores de búsqueda del nodo.
Remover solo las definiciones de StatefulSet.
Ejecute el siguiente comando para cada StatefulSet que identificó en el paso 1:
kubectl --context <member-context> -n <namespace> \ delete sts <statefulset-name> --cascade=orphan \ --timeout=300s
Confirme que cada StatefulSet está ausente mientras que sus mongot Pods y Persistent Volume Claims existentes permanecen intactos y sin marcas de tiempo de eliminación. No borrar el recurso MongoDBSearch ni escalar mongot hacia abajo.
Actualice los recursos de Search existentes.
kubectl --context <search-resource-context> -n <namespace> \ edit mongodbsearch <search-name>
Cambie el valor persistence.single.storage de la entrada del clúster afectado:
persistence: single: storage: 2Gi
En una implementación de operador de Kubernetes por clúster de nodo, actualice la configuración correspondiente en cada recurso de búsqueda local.
Mantenga la clase de almacenamiento existente, las entradas del clúster, los índices, las réplicas y otras configuraciones. Remover una entrada de clúster puede borrar los recursos de búsqueda y las reclamaciones de ese clúster.
Vuelva a leer los recursos de búsqueda para confirmar que los nuevos tamaños efectivos persistieron. Los statefulSets de destino deben permanecer ausentes hasta que reanude los operadores.
Reanudar los operadores.
Restauración el recuento de réplicas registrado de cada operador:
kubectl --context <operator-context> -n <operator-namespace> \ scale deployment <operator-name> \ --replicas=<original-replicas> kubectl --context <operator-context> -n <operator-namespace> \ rollout status deployment/<operator-name> --timeout=600s
Espere a que cada StatefulSet vuelva a aparecer con la plantilla de reclamación data ampliada. El nuevo StatefulSet adopta los Pods existentes y los reclama.
Reinicie los pods mongot si el sistema de archivos lo requiere.
Si la condición FileSystemResizePending persiste, borre los mongot afectados Pods uno por uno:
kubectl --context <member-context> -n <namespace> \ delete pod <mongot-pod-name> --timeout=300s kubectl --context <member-context> -n <namespace> \ wait --for=condition=Ready pod/<mongot-pod-name> \ --timeout=600s
Espere a que el reemplazo Pod exista antes de ejecutar el comando de preparación. Reinicie el siguiente Pod solo después de que el reemplazo esté listo y la condición se borre. Omita este paso si la expansión se completa en linea.
Nota
Borrar un Pod directamente evita los PodDisruptionBudgets. Una sola réplica mongot no puede servir solicitudes mientras se reinicia. Este procedimiento no garantiza cero tiempo de inactividad.
Verificar el almacenamiento y la disponibilidad de búsqueda.
Confirme que cada Reclamación de volumen persistente informa al menos de la capacidad solicitada, que todos los mongot Pods esperados están listos y que cada recurso de Search alcance la fase Running después de la conciliación.
Solucionar problemas de expansión
Si un paso falla mientras los operadores están detenidos, mantenga intactos los recursos de búsqueda, sus Pods y las reclamaciones. Corrija la configuración de almacenamiento efectiva y, a continuación, restauración cada operador en pausa a su recuento de réplicas original. Si reanuda antes de corregir la configuración, complete el procedimiento más tarde en lugar de reducir o borrar una reclamación.
Si un Pod o una reclamación comienza a borrarse, detenga los borrados posteriores y póngase en contacto con el administrador de Kubernetes o de almacenamiento. No remover finalizadores ni edite PV.spec.capacity como solución alternativa.
Obtén más información
Para aumentar el almacenamiento para otros recursos del operador de Kubernetes, consulte Aumentar el almacenamiento para volúmenes persistentes.
Para la revisión de la configuración de almacenamiento de
mongot, consulte la spec.clusters[].persistence configuración.Para aprender sobre la configuración de recursos de MongoDB Search, consulta Configuración de MongoDB Search y búsqueda vectorial.