Wondering How to Run Percona XtraDB Cluster on Kubernetes? Try Our Operator!

Kubernetes has been a big trend for a while now, particularly well-suited for microservices. Running your main databases on Kubernetes is probably NOT what you are looking for. However, there’s a niche market for them. My colleague Stephen Thorn did a great job explaining this in The Criticality of a Kubernetes Operator for Databases. If you are considering running your database on Kubernetes, have a look at it first. And, if after reading it you start wondering how the Operator works, Stephen also wrote an Introduction to Percona Operator for MySQL based on Percona XtraDB Cluster (PXC), which presents the Kubernetes architecture and how the Percona Operator simplifies the deployment of a full HA PXC cluster in this environment, proxies included!

Now, if you are curious about how it actually works in practice but are afraid the entry barrier is too high, I can help you with that. In fact, this technology is widespread now, with most cloud providers offering a dedicated Kubernetes engine. In this blog post, I’ll walk you over the steps on how to deploy a Percona XtraDB Cluster (PXC) using the Percona Operator for MySQL based on Percona XtraDB Cluster on Google Cloud Platform (GCP).

Creating a Virtual Environment to Run Kubernetes on GCP

Google Cloud Platform includes among its products the Google Kubernetes Engine (GKE). We can take advantage of their trial offer to create our test cluster there: https://cloud.google.com.

After you sign up, you can access all the bells and whistles in their web interface. Note the Kubernetes Engine API is not enabled by default, you need to do it by visiting the Kubernetes Engine section in the left menu, under COMPUTE.

For the purpose of deploying our environment, we should install their SDK and work from the command line: see https://cloud.google.com/sdk/docs/install and follow the respective installation instructions for your OS (you will probably want to install the SDK on your personal computer).

With the SDK installed, we can initialize our environment, which requires authenticating to the Google Cloud account:

You will be prompted to choose a cloud project to use: there’s one created by default when the account is activated, named “My First Project”. It will receive a unique id, which you can verify in the Google Cloud interface, but usually, it is displayed as the first option presented in the prompt.

Alternatively, you can use gcloud config set to configure your default project and zone, among other settings.

For this exercise, we will be creating a 3-node cluster named k8-test-cluster with n1-standard-4 instances in the us-central1-b zone:

If the command above was successful, you should see your newly created cluster in the list returned by:

Getting Ready to Work with Kubernetes

Besides the Google Cloud SDK that is used to manage the cloud instances, we also need the Kubernetes command-line tool, kubectl, to manage the Kubernetes cluster. One way to install it is through gcloud itself:

This method won’t work for everyone though, as the Cloud SDK component manager is disabled for certain kinds of installation, such as through apt or yum in Linux. I find myself in this group, using Ubuntu, but the failed attempt to install kubectl through gcloud suggested another approach that worked for me:

Deploying Percona Operator for MySQL based on Percona XtraDB Cluster

The Percona operators are available on Github. The most straightforward way to obtain a copy is by cloning the operator’s repository. The latest version of the PXC operator is 1.6.0 and we can clone it with the following command:

Move inside the created directory:

and run the following sequence of commands:

1. Define the Custom Resource Definitions for PXC:
   
   
   Shell

   kubectl apply -f deploy/crd.yaml

   1	kubectl apply -f deploy/crd.yaml

2. Create a namespace on Kubernetes and associate it to your current context:
   
   
   Shell

   kubectl create namespace pxc kubectl config set-context $(kubectl config current-context) --namespace=pxc

   1 2	kubectl create namespace pxc kubectl config set-context $(kubectl config current-context) --namespace=pxc

3. Define Role-Based Access Control (RBAC) for PXC:
   
   
   Shell

   kubectl apply -f deploy/rbac.yaml

   1	kubectl apply -f deploy/rbac.yaml

4. Start the operator within Kubernetes:
   
   
   Shell

   kubectl apply -f deploy/operator.yaml

   1	kubectl apply -f deploy/operator.yaml

5. Configure PXC users and their credentials:
   
   
   Shell

   kubectl apply -f deploy/secrets.yaml

   1	kubectl apply -f deploy/secrets.yaml

6. Finally, deploy the cluster:
   
   
   Shell

   kubectl apply -f deploy/cr.yaml

   1	kubectl apply -f deploy/cr.yaml

You can find a more detailed explanation of each of these steps, as well as how to customize your installation, in the Percona Operator for MySQL based on Percona XtraDB Cluster online documentation, which includes a quickstart guide for GKE.

Now, it is a matter of waiting for the deployment to complete, which you can monitor with:

A successful deployment will show output for the above command similar to:

As you can see above, the operator will deploy seven pods with the default settings, and those are distributed across the three GKE n1-standard-4 machines we created at first:

Accessing the Cluster

One way to access the cluster is by creating an interactive shell in the Kubernetes cluster:

From there, we can access MySQL through the cluster’s HAproxy writer node:

Note the hostname used above is an alias, the connection being routed to one of the HAproxy servers available in the cluster. It is also possible to connect to a specific node by modifying the host option -h with the node’s name:

This is where all the fun and experimentation starts: you can test and break things without worrying too much as you can easily and quickly start again from scratch.

Destroying the Cluster and Deleting the Test Environment

Once you are done playing with your Kubernetes cluster, you can destroy it with:

It’s important to note the command above will not discard the persistent disk volumes that were created and used by the nodes, which you can check with the command:

A final purging command is required to remove those as well:

If you are feeling overzealous, you can double-check that all has been deleted:

Learn More About Percona Operator for MySQL based on Percona XtraDB Cluster

Interested In Hands-On Learning?

Be sure to get in touch with Percona’s Training Department to schedule your PXC Kubernetes training engagement. Our expert trainers will guide your team firstly through the basics, cover all the configuration noted above (and then some), and then dive deeper into how the operator functions along with High-Availability exercises, disaster recovery scenarios, backups, restore, and much more.