Percona DBaaS CLI to Simplify Deployment in Kubernetes

Percona DBaaS CLI KubernetesWe recently released an experimental version of percona-dbaas command-line tool with the goal of significantly simplifying the deployment of database instances in Kubernetes.

We have Kubernetes Operators for Percona XtraDB Cluster and Percona Server for MongoDB, which provide great flexibility, but they also come with the complexity of managing configuration and deployment files, so we wanted to make it even simpler to deploy database instances. We found it hard enough to get a MySQL instance up and running in Kubernetes, and then a whole different process to get MongoDB up, and we thought it should be a unified set of commands. This is how the percona-dbaas CLI tool was born. You can get more information on installation of the percona-dbaas-cli tool and in this blog post, I wanted to review the basic functionality it provides.

1. Kubernetes Setup

First of all, the tool assumes you have your Kubernetes cluster installed and running. For example, I will use Google Kubernetes Engine. For the local system, you will need to have Google Cloud SDK installed, and for the Ubuntu-based system (which I used), the instructions are here.

After the initial setup, let’s make sure we have access to the cluster from kubectl and have enough nodes running:

And the extra permission grant step is needed for our Operators:

2. Basic Operations

As we have the Kubernetes cluster running, now there are basic operations to create database instances:

The cluster was installed, and we can even access it with the mysql command line via kubectl port-forward.

Let’s see what was really deployed:

So we can see we deployed three nodes of Percona XtraDB Cluster with ProxySQL running in front. And now if we access it from mysql command line:

We see that we actually connected to the ProxySQL instances.

To destroy the cluster:

It’s a very similar step to create a MongoDB instance from the command line tool:

3. Extra Configuration

It is possible to customize the deployment with additional options.

Case 1: Deploy without ProxySQL:

You actually will have three pods running:

You can choose which one you want to connect to. And if we connect to the instance:

We connected directly to a Percona XtraDB Cluster node, and there are three nodes are running.

Case 2: Create only a single node cluster without ProxySQL:

To check that we have only one node running:

Case 3: Create a cluster which is accessible outside Kubernetes.

This particular case will work only with Google Kubernetes Engine and other providers that can assign a public IP to a LoadBalancer.

So you can run:

Now there should be a public IP assigned to the cluster, and to find it, we run:

So now we can connect to the cluster from anywhere:

Just make sure you create users with secure passwords!

4. Customize my.cnf

This is not really a documented feature yet (so consider this is a hack), but sometimes we want to make some adjustments to my.cnf, for example, to increase buffer pool size if we know that nodes have enough memory to accommodate a bigger buffer pool.

For this we create our or my.cnf:

Deploy it to a configmap:

And create the cluster after that:

After we connect to to the cluster:

We have nodes with 2GB buffer pool size.

In the command above, “mycluster1” specifies the configuration that will be applied to “mycluster1” cluster and “pxc” specifies you’re supplying MySQL/PXC configuration through my.cnf.


Our percona-dbaas tool is the next step in simplifying the deployment for Percona XtraDB Cluster and Percona Server for MongoDB. It is still in an experimental state, and we are asking for your feedback to see what we can improve before we get to the official release.

Share this post

Leave a Reply