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 Kubernetes Operator for 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 Kubernetes 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:
gcloud init
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:
gcloud container clusters create --machine-type n1-standard-4 --num-nodes 3 --zone us-central1-b --cluster-version latest k8-test-cluster
If the command above was successful, you should see your newly created cluster in the list returned by:
gcloud container clusters list
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:
gcloud components install kubectl
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:
sudo apt install kubectl
Deploying a PXC Cluster Using the Percona Kubernetes Operator
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:
git clone -b v1.6.0 https://github.com/percona/percona-xtradb-cluster-operator
Move inside the created directory:
cd percona-xtradb-cluster-operator
and run the following sequence of commands:
- Define the Custom Resource Definitions for PXC:
kubectl apply -f deploy/crd.yaml
- Create a namespace on Kubernetes and associate it to your current context:
kubectl create namespace pxc kubectl config set-context $(kubectl config current-context) --namespace=pxc
- Define Role-Based Access Control (RBAC) for PXC:
kubectl apply -f deploy/rbac.yaml
- Start the operator within Kubernetes:
kubectl apply -f deploy/operator.yaml
- Configure PXC users and their credentials:
kubectl apply -f deploy/secrets.yaml
- Finally, deploy the cluster:
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 Kubernetes Operator for 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:
kubectl get pods
A successful deployment will show output for the above command similar to:
NAME READY STATUS RESTARTS AGE cluster1-haproxy-0 2/2 Running 0 4m21s cluster1-haproxy-1 2/2 Running 0 2m47s cluster1-haproxy-2 2/2 Running 0 2m21s cluster1-pxc-0 1/1 Running 0 4m22s cluster1-pxc-1 1/1 Running 0 2m52s cluster1-pxc-2 1/1 Running 0 111s percona-xtradb-cluster-operator-79d786dcfb-9lthw 1/1 Running 0 4m37s
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:
kubectl get nodes NAME STATUS ROLES AGE VERSION gke-k8-test-cluster-default-pool-02c370e1-gvfg Ready <none> 152m v1.17.13-gke.1400 gke-k8-test-cluster-default-pool-02c370e1-lvh7 Ready <none> 152m v1.17.13-gke.1400 gke-k8-test-cluster-default-pool-02c370e1-qn3p Ready <none> 152m v1.17.13-gke.1400
Accessing the Cluster
One way to access the cluster is by creating an interactive shell in the Kubernetes cluster:
kubectl run -i --rm --tty percona-client --image=percona:8.0 --restart=Never -- bash -il
From there, we can access MySQL through the cluster’s HAproxy writer node:
mysql -h cluster1-haproxy -uroot -proot_password
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:
mysql -h cluster1-pxc-0 -uroot -proot_password
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:
gcloud container clusters delete --zone=us-central1-b k8-test-cluster
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:
gcloud compute disks list
A final purging command is required to remove those as well:
gcloud compute disks delete <disk_name_1> <disk_name_2> <disk_name_3> --zone=us-central1-b
If you are feeling overzealous, you can double-check that all has been deleted:
gcloud container clusters list
gcloud compute disks list
Learn More About Percona Kubernetes Operator for 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.
