The mongot process stores MongoDB Search and Vector Search indexes on a dedicated Persistent Volume. The Kubernetes Operator doesn't expand that storage automatically. In Kubernetes Operator 1.9 or later, you can expand the mongot Persistent Volume Claims, then update the MongoDBSearch resource to reflect the expanded volume size. To increase storage for other resources, see Increase Storage for Persistent Volumes.
Prerequisites
mongotPersistent Volume Claims provisioned using a Container Storage Interface (CSI) driver that supports volume expansion while the volume remains attached, and a StorageClass that represents that driver and setsallowVolumeExpansiontotrue. Confirm that the file system supports expansion. This procedure doesn't cover storage backends that require detaching the volume before the controller can expand it.A healthy source database and MongoDB Search and Vector Search deployment, and a backup or recovery plan. To configure backups for the source database, see Configure MongoDB Database Backups. To learn what to back up for Search, see
mongotDeployment Frequently Asked Questions.A maintenance window without concurrent scaling or upgrades of the Kubernetes Operator or the MongoDBSearch resource. Pause automation that can restore Kubernetes Operator replicas or revert the Search storage setting, for example a GitOps sync. If you manage the MongoDBSearch resource in Git, commit the new size before you resume the sync. If you stop an operator, it pauses reconciliation for all resources it manages.
Permission to patch Persistent Volume Claims, edit MongoDBSearch resources, scale Kubernetes Operator deployments, and delete statefulSets and Pods.
Multi-Cluster Deployments
During this procedure, you run commands against the MongoDBSearch resource, the mongot statefulSets and their Persistent Volume Claims, and the Kubernetes Operator Deployment. In a multi-cluster deployment, these targets can reside in different clusters. Use the following table to determine the context for each command and the operator to stop and resume:
Deployment | MongoDBSearch resource context | StatefulSet and Persistent Volume Claim context | Operator to stop and resume |
|---|---|---|---|
Single cluster | Workload cluster | Same cluster | Local operator |
Central multi-cluster Kubernetes Operator | Central cluster | Each affected member cluster | Central operator |
Kubernetes Operator per member cluster | Each member cluster's local Search resource | Same member cluster | Each affected member's Search operator |
Expand Storage
The following procedure expands replica set Search storage from 1Gi to 2Gi. Match each StatefulSet to its cluster entry's name and explicit index, not the entry's position in the clusters array.
A matching shardOverrides[].persistence setting replaces the cluster's persistence setting. If you set it, change the size there. If you override volumeClaimTemplates in spec.clusters[].statefulSet, change the size there. That override takes precedence over persistence.
Warning
Increase only the storage, while keeping the existing MongoDBSearch resource and its Persistent Volume Claims, and don't scale down mongot. Delete only the StatefulSet definitions, and make sure to use the --cascade=orphan option so that the mongot Pods and their claims remain intact while the Kubernetes Operator is stopped.
Identify the mongot StatefulSets and data claims.
List the mongot statefulSets for the MongoDBSearch resource:
kubectl --context <member-context> -n <namespace> \ get sts -l mongodb.com/search-name=<search-name>
With the default data claim template, each replica uses a claim named data-<statefulset-name>-<ordinal>. For a sharded cluster source, each cluster has one StatefulSet for each shard. If you customized the claim templates or volume mounts, check the claim that each Pod mounts instead.
Expand each data claim.
Run the following command for each claim that you identified in the previous step:
kubectl --context <member-context> -n <namespace> \ patch pvc <pvc-name> --type=merge \ -p '{"spec":{"resources":{"requests":{"storage":"2Gi"}}}}'
Wait until each claim reports at least the requested size (in this example, 2Gi) in status.capacity.storage or the FileSystemResizePending condition:
kubectl --context <member-context> -n <namespace> \ get pvc <pvc-name> -o yaml
If the expansion takes longer than your storage backend's documented timeout, investigate the CSI events before you continue:
kubectl --context <member-context> -n <namespace> \ describe pvc <pvc-name>
Stop the responsible Kubernetes Operator deployments.
Record each operator's original replica count:
kubectl --context <operator-context> -n <operator-namespace> \ get deployment <operator-name> \ -o jsonpath='{.spec.replicas}{"\n"}'
Scale the operator to zero, and wait for its Pods to be deleted:
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>
Scale the operator, not mongot. The Helm chart names the operator Deployment mongodb-kubernetes-operator and sets app.kubernetes.io/name: mongodb-kubernetes-operator on its Pods. If your installation is customized, use the Deployment's actual pod selector instead of the chart label shown in this example. Stop all responsible operator Pods, including terminating Pods, before you continue. Stopping a separate source database operator doesn't pause the member Search operators.
Remove only the StatefulSet definitions.
Run the following command for each StatefulSet that you identified in step 1:
kubectl --context <member-context> -n <namespace> \ delete sts <statefulset-name> --cascade=orphan \ --timeout=300s
Confirm that each StatefulSet is absent while its existing mongot Pods and Persistent Volume Claims remain intact and without deletion timestamps. Don't delete the MongoDBSearch resource or scale mongot down.
Update the existing Search resources.
kubectl --context <search-resource-context> -n <namespace> \ edit mongodbsearch <search-name>
Change the affected cluster entry's persistence.single.storage value:
persistence: single: storage: 2Gi
In a Kubernetes Operator per member cluster deployment, update the corresponding setting in every local Search resource.
Keep the existing storage class, cluster entries, indexes, replicas, and other settings. Removing a cluster entry can delete that cluster's Search resources and claims.
Read the Search resources back to confirm that the new effective sizes persisted. The targeted statefulSets must remain absent until you resume the operators.
Resume the operators.
Restore each operator's own recorded replica count:
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
Wait for each StatefulSet to reappear with the expanded data claim template. The new StatefulSet adopts the existing Pods and claims.
Restart the mongot pods if the file system requires it.
If the FileSystemResizePending condition persists, delete the affected mongot Pods one at a time:
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
Wait for the replacement Pod to exist before you run the readiness command. Restart the next Pod only after the replacement is ready and the condition clears. Skip this step if the expansion completes online.
Note
Deleting a Pod directly bypasses PodDisruptionBudgets. A single mongot replica can't serve requests while it restarts. This procedure doesn't guarantee zero downtime.
Verify storage and Search readiness.
Confirm that each Persistent Volume Claim reports at least the requested capacity, that all expected mongot Pods are ready, and that each Search resource reaches the Running phase after reconciliation.
Troubleshoot Expansion
If a step fails while the operators are stopped, keep the Search resources, its Pods, and claims intact. Correct the effective storage settings, then restore every paused operator to its original replica count. If you resume before you correct the configuration, complete the procedure later rather than shrinking or deleting a claim.
If a Pod or claim starts deleting, stop further deletions and contact your Kubernetes or storage administrator. Don't remove finalizers or edit PV.spec.capacity as a workaround.
Learn More
To increase storage for other Kubernetes Operator resources, see Increase Storage for Persistent Volumes.
To review the
mongotstorage settings, see the spec.clusters[].persistence setting.To learn about the MongoDBSearch resource settings, see MongoDB Search and Vector Search Settings.