Tips for installing MongoDB Community Edition into Kubernetes
Do you want to run MongoDB in Kubernetes locally or in a cloud-based Kubernetes Service when developing an application? Do you want to: validate a close-to-production integration scenario, collaborate with colleagues, or just simply ~make development easier~?
MongoDB has provided a community edition Kubernetes Operator and definition files to do this for you. This article is not about how to use the Operator, but instead, tips for all the unknown extras.
💡 I recommend you use an as-a-service database solution for any production needs.
Tip #1: Alternate Namespaces
As part of installing and using MongoDB, you are most likely creating multiple instances of MongoDB in various namespaces.
If this is the case, there is a simple catch: the Operator only installs the Role, ServiceAccount, and RoleBinding in the Operators namespace. Even if you tell it to watch for the installation in other namespaces. This means when you go to install MongoDB you will see an error message on your StatefulSet like
Warning FailedCreate 2m15s (x16 over 4m59s) statefulset-controller create Pod mongodb-0 in StatefulSet mongodb failed error: pods "mongodb-0" is forbidden: error looking up service account userprofiles-dev/mongodb-database: serviceaccount "mongodb-database" not found
This can be done by following the instructions in Step 3 of installing via Kubectl for each of the namespaces you are installing into
Tip #2: Finding your objects
If you are unsure of what objects are being installed by the Operator / CRDs then use the following command
kubectl get all -n <namespace>
kubectl get mdbc -n <namespace>
Tip #3: Stuck Replicaset
If you have replica sets that are stuck, and it’s not reporting a true error other than readiness probe failed for the mongodb-agent, then potentially you need to make sure the following two items.
- Check that you aren’t using the same SCRAM credential secret name for multiple users. It is reported that this cause the operator to keep on generating the credentials and never complete the reconciliation.
- Check if there are existing PVCs from previously deleted database instances. The root cause is unknown; however, when recreating the database, this may cause it not to work.
Tip #4: Connection Strings
When installing MongoDB you are told: “The Operator will create a Secret object, per user…Each
Secret will contain a Connection String that can be mounted into a client application to connect to this MongoDB instance”
If these secrets are not generated, it means that something has gone wrong with the initial installation and the reconciliation between the install and the Operator.
I’d suggest double checking Tip #3 and also making sure that for each user, you have specified
- Separate password secret
- Separate SCRAM secret
More detail on the connection strings can be found here.
Tip #5: Customizations
Starting to need to provide customizations to your installation? Fancy that! Well, there are quite a few different scenarios, from configuring the underlying PVC, custom roles, and readiness probes.
Familiarize yourself with the config samples.
Tip #6: Database Write User
The default installation path will install an admin user for the admin database with admin roles.
However, this won’t actually help you create a database for your development needs or insert records into this database.
For this, you need to add a new user to your Community DB YAML.
- name: user
db: admin #or other authentication database
passwordSecretRef: # a reference to the secret that will be used to generate the user's password
- name: readWrite
You will also need to create the password secret you reference above. More information on this can be found here.