Kubernetes Deployment FAQ

The MongoDB operator deploys and manages your replica set. If the operator is not running, the replica set is not deployed. Common causes are insufficient RBAC permissions and failures pulling the operator image from the registry.

To debug, check the logs and inspect the deployment with these commands:

kubectl logs deployment/mongodb-kubernetes-operator -n rocketchat
kubectl describe deployment mongodb-kubernetes-operator -n rocketchat

To find the cause, run these checks:

1. Check the MongoDB operator logs:

   kubectl logs deployment/mongodb-kubernetes-operator -n rocketchat

2. Check the MongoDB pod logs:

   kubectl logs mongodb-0 -n rocketchat

3. Verify that the persistent volumes have enough space:

   kubectl get pvc -n rocketchat

4. Check whether the MongoDBCommunity resource reports errors:

   kubectl describe mongodbcommunity mongodb -n rocketchat

If the endpoints are empty, the selector on the service doesn't match the labels on the pods. The MongoDB Kubernetes operator manages service selectors and pod labels automatically. If you encounter this issue, verify that you haven't overridden the serviceName, selector, or template labels in the statefulSet spec.

To verify:

kubectl get svc mongodb-svc -n rocketchat -o yaml | grep selector -A 5
kubectl get pod mongodb-0 -n rocketchat -o yaml | grep labels -A 5

The selector values in the service must match the labels on the pod.

If Rocket.Chat can’t connect to MongoDB, run these checks:

1. Verify that MongoDB is running:

   kubectl get pods -n rocketchat | grep mongodb

2. Test the connection string manually. Replace <password> with the password of the rocketchat database user:

   kubectl run -it --rm debug --image=mongo:8.2.3 --restart=Never -n rocketchat -- mongosh "mongodb://rocketchat:<password>@mongodb-0.mongodb-svc.rocketchat.svc.cluster.local:27017/rocketchat?authSource=rocketchat"

3. Check the Rocket.Chat logs for connection errors:

   kubectl logs <rocketchat-pod-name> -n rocketchat

4. Verify that the MongoDB service is accessible:

   kubectl get svc -n rocketchat | grep mongodb

5. Confirm that the MongoDB service endpoints exist:

   kubectl get endpoints mongodb-svc -n rocketchat

The Helm upgrade usually removes it, but legacy persistent volume claims (PVCs) can remain. If the old Bitnami MongoDB pod is still running:

1. Verify that your data is in the new MongoDB instance.

2. Look for orphaned volumes:

   kubectl get pvc -n rocketchat

3. After you confirm the migration succeeded, delete the old PVCs manually.

Deleting a PVC permanently removes the data on it. Confirm that the new MongoDB instance has all your data first.