[bitnami/mongodb-sharded] Deployment very unstable when defining custom root credentials

[tschneider-aneo]

Name and Version

bitnami/mongodb-sharded 8.2.3

What architecture are you using?

amd64

What steps will reproduce the bug?

helm install my-mongodb-sharded oci://registry-1.docker.io/bitnamicharts/mongodb-sharded --version=8.2.3 --set auth.rootUser=abc123

OR

helm install my-mongodb-sharded oci://registry-1.docker.io/bitnamicharts/mongodb-sharded --version=8.2.3 --set auth.rootPassword=S0m3S3curedP4SSW0rD

Are you using any custom parameters or values?

--set auth.rootUser=abc123 OR --set auth.rootPassword=S0m3S3curedP4SSW0rD

What is the expected behavior?

The deployment should be fine and I should be happy with my custom root credentials

What do you see instead?

The custom root credentials indeed allow me to access the database but the deployment is very unstable, as my shard pods crash approximately every 3/5 minutes.

Additional information

My computer has 32Go of RAM, and currently uses 77% of it as I'm publying this issue with a sharded MongoDB running on my Kube cluster.

[carrodher]

Could you check container logs and describe the pods to get more info about the cause of the crashes?

[tschneider-aneo]

https://gist.github.com/tschneider-aneo/8e808bb1da3aebac7b7d190f52788f64

Note that while retrieving logs and pods description, my shard pods crashed again. I am now at 8 pod restarts in 35 minutes

[carrodher]

It seems all the errors appear when trying to connect with MongoDB:

  Warning  Unhealthy  19m (x4 over 27m)     kubelet            Readiness probe failed: MongoNetworkError: connect ECONNREFUSED 127.0.0.1:27017

mongodb 15:26:18.37 INFO  ==> Found MongoDB server listening at my-mongodb-sharded-configsvr-0.my-mongodb-sharded-headless.default.svc.cluster.local:27017 !
MongoNetworkError: connect ECONNREFUSED 10.42.0.32:27017

mongodb 15:46:17.96 INFO  ==> Joining the shard cluster
MongoServerError: Authentication failed.
...
mongodb 15:48:25.06 ERROR ==> Unable to join the sharded cluster

Did you install the Helm chart reusing the name and namespace from a previous installation? Are you able to reproduce the issue by installing the chart from scratch in a brand-new namespace? I'm wondering if the issue could be related to reusing the PV/PVC from a previous installation where the old password is stored and it doesn't match with the one used in this new deployment.

[tschneider-aneo]

When deploying with this command:

helm install new-mongodb-sharded oci://registry-1.docker.io/bitnamicharts/mongodb-sharded --version=8.2.3 --set auth.rootUser=abc123 --create-namespace -n new-namespace

I want to highlight that despite these frequent shard pods crashes, the credentials I define are valid and I'm able to connect to the MongoDB cluster from the shard pods using their environment variable, even though I'm indeed not able to perform write operations on the sharded cluster:

$ kubectl exec -it new-mongodb-sharded-shard0-data-0 -n new-namespace -- bash
I have no name!@my-mongodb-sharded-shard0-data-0:/$ mongosh -u $MONGODB_ROOT_USER -p $MONGODB_ROOT_PASSWORD mongodb://my-mongodb-sharded:27017
Current Mongosh Log ID: 6672a7798043957a47a26a12
Connecting to:          mongodb://<credentials>@my-mongodb-sharded:27017/?directConnection=true&appName=mongosh+2.2.6
Using MongoDB:          7.0.11
Using Mongosh:          2.2.6

For mongosh info see: https://docs.mongodb.com/mongodb-shell/

[direct: mongos] test> use database
switched to db database
[direct: mongos] database> db.mycollection.insertOne({data: 'test'})
MongoServerError[ShardNotFound]: Database database could not be created :: caused by :: No shards found

I verified that no PVC and PV were existent before reproducing the bug. The deployment is still as unstable as described in the issue.

Finally, I hadn't tested but I also cannot perform write operation when the chart is deployed like in the issue (in the default namespace)

[tschneider-aneo]

It seems to be the same issue as the one below :
#13364

[github-actions]

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

[github-actions]

Due to the lack of activity in the last 5 days since it was marked as "stale", we proceed to close this Issue. Do not hesitate to reopen it later if necessary.