Kubernetes Deployment FAQ

The operator is the brain of your database. If it’s down, your ReplicaSet won’t deploy. It’s often related to insufficient RBAC permissions or issues pulling the operator image from the registry.

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

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

MongoDB pod could be failing due to numerous reasons. Here are some debugging steps to identify the possible cause:

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 persistent volumes have adequate space:

   kubectl get pvc -n rocketchat

4. Check if the MongoDBCommunity resource has 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 automatically manages service selectors and pod labels. If you encounter this issue, verify 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

Both the service and pod labels should both be managed by the operator automatically.

If Rocket.Chat can’t connect to MongoDB, here are a few checks to verify:

1. Verify that MongoDB is running:

   kubectl get pods -n rocketchat | grep mongodb

2. Run a check to test the connection string manually:

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

3. Check Rocket.Chat logs for connection errors:

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

4. Verify the MongoDB service is accessible:

   kubectl get svc -n rocketchat | grep mongodb

5. Confirm MongoDB service endpoints exist:

   kubectl get endpoints mongodb-svc -n rocketchat

The Helm upgrade should handle this, but legacy PVCs (Persistent Volume Claims) sometimes linger. If the old Bitnami MongoDB pod is still running:

1. Verify your data is safe in the new MongoDB instance first.

2. Look for orphaned volumes:

   kubectl get pvc -n rocketchat. 

3. You can manually delete the old ones once you are certain the migration was successful.