Getting Started with MongoDB in OpenShift Using the Percona Server for MongoDB Kubernetes Operator

MongoDB in OpenShiftKubernetes has become an integral part of many architectures and has continued to rise in popularity.  Kubernetes is an open source platform for managing containerized workloads and services.  One approach to running Kubernetes is Redhat’s OpenShift.  OpenShift is RedHat’s name for its family of containerization products.  The main part of OpenShift and the product we’ll be writing about today is the OpenShift Container Platform, an on-premises platform as a service built around Docker containers orchestrated and managed by Kubernetes on a foundation of Red Hat Enterprise Linux.

The other products provide this platform through different environments: OKD serves as the community-driven upstream (akin to the way that Fedora is upstream of Red Hat Enterprise Linux), OpenShift Online is the platform offered as software as a service, and OpenShift Dedicated is the platform offered as a managed service.

Operators are extensions to Kubernetes that allow for the management of a particular piece of software in a Kubernetes cluster.   In this blog post, we’ll help you get started with the Percona Kubernetes Operator for Percona Server for MongoDB.

Getting Started with OpenShift

The OpenShift Container Platform can be installed in many different ways and on many different platforms, whether on-premises or in a public cloud.  I’ve found the following guides helpful for installing on AWS, Azure, GCP, and Bare Metal.

Advantages of a Kubernetes Operator

You may be aware that you can easily spin up a containerized MongoDB instance on your container of choice.   So what advantages does a Kubernetes Operator provide?  In this case, the Operator can provide a lot of  Operational tasks that aren’t always as straightforward to do in a Kubernetes cluster context.  This includes, but is not limited to, creating users needed for the Operator, performing upgrades, initializing and configuring replica sets, scaling replica sets in and out, performing backups and restores, and, as of version 1.6.0 of the Percona Kubernetes Operator for Percona Server for MongoDB, setting up a 1 shard sharded cluster with all the networking needed.

Installing the Operator

First, we need to download the Operator from Github and change it to the directory that the operator was downloaded to.  Note that you can change the branch that you pull down by changing the value after the -b flag if you need a different version of the Operator.   At the time of writing, version 1.6.0 is the latest version of the Operator.

After we’ve downloaded the Operator, we need to set up the Custom Resource Definitions (CRD) that the operator uses.  This CRD file tells Kubernetes about the resources which the Operator will be using.  To install these, run the following against your OpenShift cluster as a cluster admin user:

There are times when you will not want your database cluster to be managed by a cluster admin user.   To have your Percona Server for MongoDB cluster Custom Resource (CR) managed with a non-privileged Kubernetes user, you would need to run the following:

Additionally, if you have a cert-manager installed, there will be two more commands needed to be able to manage certificates with a non-privileged user.

Creating a Project for your MongoDB Database

Next, we’ll need to create an OpenShift Project for your MongoDB Deployment.  In OpenShift, projects/namespaces are used to allow a community of users to organize and manage their content in isolation from other communities.   These projects may map to individual applications, pieces of software, or whole application stacks.

Configuring the Operator

The first part of configuring the Operator involves setting up Role-Based Access Control (RBAC) to define what actions can be performed by the Operator.  For example, a Role used by cert-manager should only have permissions on resources that are related to certificates and shouldn’t be granted access to say, stop and start a MongoDB deployment.

Next, we’ll start the Operator container.  This YAML file contains the definitions for the Operator itself.

Defining Users and Secrets

Now we need to define the users and secrets that will be created in our MongoDB deployment.   These are administrative users that will perform different tasks as part of the Operator.  These users are User Admins for creating additional users, clusterAdmin for adding or removing replica set members, cluster monitor for monitoring specific parts of the replica set/sharded cluster by Percona Monitoring and Management (PMM), and a backup user for performing backups and restores.   Make sure you update these to match the required security policies for your organization. Don’t forget to rotate passwords according to security policies during the life of your cluster.

Configuring Cluster Custom Resource for OpenShift and Deploying

First, we need to update deploy/cr.yaml to have our platform be openshift. It is needed because OpenShift (compared to vanilla Kubernetes) has important security settings that are applied by default:

Optionally, if you’re using MiniShift, which runs on an older version of OpenShift, an older version of Kubernetes and is not suitable for production usage, you need to change all instances of the following in your deploy/cr.yaml:

This CR file also defines how much CPU and Memory we’re granting to each container, and lets us define how many replica set members, config server replica set members, mongos’ we have and lets us add configuration options to our MongoDB-related processes.  Finally, we can apply the CR file using the following command:

As of version 1.6 of the Operator, if you stick with all the defaults and your OpenShift cluster has sufficient memory and CPU, this will deploy a 1 shard sharded MongoDB cluster to your OpenShift cluster.

To verify your cluster is up and running, run the following command:

Depending on the resources for your OpenShift cluster, after some time, your results should look similar to this: