Install Percona server for MongoDB on Kubernetes¶

Clone the percona-server-mongodb-operator repository:
```
$ git clone -b v1.19.1 https://github.com/percona/percona-server-mongodb-operator
$ cd percona-server-mongodb-operator
```
Note

It is crucial to specify the right branch with -b option while cloning the code on this step. Please be careful.
The Custom Resource Definition for Percona Server for MongoDB should be created from the deploy/crd.yaml file. The Custom Resource Definition extends the standard set of resources which Kubernetes “knows” about with the new items, in our case these items are the core of the operator. Apply it as follows:
```
$ kubectl apply --server-side -f deploy/crd.yaml
```
This step should be done only once; the step does not need to be repeated with any other Operator deployments.
Create a namespace and set the context for the namespace. The resource names must be unique within the namespace and provide a way to divide cluster resources between users spread across multiple projects.

So, create the namespace and save it in the namespace context for subsequent commands as follows (replace the <namespace name> placeholder with some descriptive name):
```
$ kubectl create namespace <namespace name>
$ kubectl config set-context $(kubectl config current-context) --namespace=<namespace name>
```
At success, you will see the message that namespace/<namespace name> was created, and the context was modified.
The role-based access control (RBAC) for Percona Server for MongoDB is configured with the deploy/rbac.yaml file. Role-based access is based on defined roles and the available actions which correspond to each role. The role and actions are defined for Kubernetes resources in the yaml file. Further details about users and roles can be found in Kubernetes documentation .
```
$ kubectl apply -f deploy/rbac.yaml
```
Note

Setting RBAC requires your user to have cluster-admin role privileges. For example, those using Google Kubernetes Engine can grant user needed privileges with the following command:
```
$ kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user=$(gcloud config get-value core/account)
```

Start the operator within Kubernetes:

$ kubectl apply -f deploy/operator.yaml

Add the MongoDB Users secrets to Kubernetes. These secrets should be placed as plain text in the stringData section of the deploy/secrets.yaml file as login name and passwords for the user accounts (see Kubernetes documentation for details).

After editing the yaml file, MongoDB Users secrets should be created using the following command:
```
$ kubectl create -f deploy/secrets.yaml
```
More details about secrets can be found in Users.
Now certificates should be generated. By default, the Operator generates certificates automatically, and no actions are required at this step. Still, you can generate and apply your own certificates as secrets according to the TLS instructions.
After the operator is started, Percona Server for MongoDB cluster can be created with the following command:
```
$ kubectl apply -f deploy/cr.yaml
```
The creation process may take some time. When the process is over your cluster will obtain the ready status. You can check it with the following command:
```
$ kubectl get psmdb
```
Expected output
```
NAME              ENDPOINT                                           STATUS   AGE
my-cluster-name   my-cluster-name-mongos.default.svc.cluster.local   ready    5m26s
```

Verifying the cluster operation¶

It may take ten minutes to get the cluster started. When kubectl get psmdb command finally shows you the cluster status as ready, you can try to connect to the cluster.

To connect to Percona Server for MongoDB you need to construct the MongoDB connection URI string. It includes the credentials of the admin user, which are stored in the Secrets object.

List the Secrets objects
```
$ kubectl get secrets -n <namespace>
```
The Secrets object you are interested in has the my-cluster-name-secrets name by default.
View the Secret contents to retrive the admin user credentials.
```
$ kubectl get secret my-cluster-name-secrets -o yaml
```
The command returns the YAML file with generated Secrets, including the MONGODB_DATABASE_ADMIN_USER and MONGODB_DATABASE_ADMIN_PASSWORD strings, which should look as follows:
Sample output
```
...
data:
  ...
  MONGODB_DATABASE_ADMIN_PASSWORD: aDAzQ0pCY3NSWEZ2ZUIzS1I=
  MONGODB_DATABASE_ADMIN_USER: ZGF0YWJhc2VBZG1pbg==
```
The actual login name and password on the output are base64-encoded. To bring it back to a human-readable form, run:
```
$ echo 'MONGODB_DATABASE_ADMIN_USER' | base64 --decode
$ echo 'MONGODB_DATABASE_ADMIN_PASSWORD' | base64 --decode
```
Run a container with a MongoDB client and connect its console output to your terminal. The following command does this, naming the new Pod percona-client:
```
$ kubectl run -i --rm --tty percona-client --image=percona/percona-server-mongodb:7.0.14-8 --restart=Never -- bash -il
```
Executing it may require some time to deploy the corresponding Pod.
Now run mongosh tool inside the percona-client command shell using the admin user credentialds you obtained from the Secret, and a proper namespace name instead of the <namespace name> placeholder. The command will look different depending on whether sharding is on (the default behavior) or off:
if sharding is onif sharding is off
$ mongosh "mongodb://databaseAdmin:databaseAdminPassword@my-cluster-name-mongos.<namespace name>.svc.cluster.local/admin?ssl=false"
$ mongosh "mongodb+srv://databaseAdmin:databaseAdminPassword@my-cluster-name-rs0.<namespace name>.svc.cluster.local/admin?replicaSet=rs0&ssl=false"
Note

If you are using MongoDB versions earler than 6.x (such as 5.0.29-25 instead of the default 7.0.14-8 variant), substitute mongosh command with mongo in the above examples.

Last update: 2025-04-16