In this tutorial, we will use the Kasten K10 Data Management Platform for two different strategies to backup and restore a MySQL database on a Kubernetes cluster, using Google Kubernetes Engine for the cluster:
- Crash consistent volume snapshots
- Logical backups
This assumes you already have set up your Google cloud platform account and followed the steps to spin up the cluster. You can create the clusters through this guided UI, which will take about three minutes to start the cluster.
The following instructions below are divided into three sections:
- Installing Kasten K10 on your GKE cluster
- Installing MySQL
- Demonstration of two backup strategies
Tools that are used in this tutorial are:
- kubectl - Kubernetes client
- gcloud - Google cloud client
- Helm v3
Step 1: Installing Kasten K10 on your GKE Cluster
There are two ways to use Kasten K10 on a GKE cluster. One is to install from the Google cloud marketplace and other is to use Helm as described below.
For installing K10 using helm, documentation can be found here. Please see the pre-requisite tools that are mentioned above before starting this tutorial. These are the steps for using the K10 Helm chart to install K10 on a Kubernetes cluster using Helm v3.
Add Kasten’s chart repository to be used by helm for the installation:
$ helm repo add kasten https://charts.kasten.io/
$ helm repo update
Next, we create a namespace to deploy the K10 application there:
$ kubectl create namespace kasten-io
Now, we install K10 using the command below with the default service account. Make sure you have required permissions:
$ helm install k10 kasten/k10 -n kasten-io
If you don’t want to use a default service account and find it difficult to set a service account, kindly follow the documentation here.
Helm install will create multiple deployments and services, and you can validate the install by running the following command:
$ kubectl get pods -n kasten-io --watch
Once all of the pods and containers are in running condition, you can port-forward the gateway service to access the K10 dashboard from the browser.
You can access the K10 dashboard at http://127.0.0.1:8080/k10/#/ after running the following command:
$ kubectl --namespace kasten-io port-forward service/gateway 8080:8000
Step 2: Installing MySQL
We will start by creating a namespace named mysql:
$ kubectl create namespace mysql
Then we will add the Helm stable charts by running the following commands:
$ helm repo add bitnami https://charts.bitnami.com/bitnami
"bitnami" has been added to your repositories
$ helm repo update
Now we install MySQL in the mysql namespace:
$ helm install --namespace mysql mysql-release bitnami/mysql
To validate the installation:
$ kubectl get all -n mysql
NAME READY STATUS RESTARTS AGE
pod/mysql-release-0 1/1 Running 0 4m3s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/mysql-release ClusterIP 10.245.157.101 <none> 3306/TCP 4m3s
service/mysql-release-headless ClusterIP None <none> 3306/TCP 4m3s
NAME READY AGE
statefulset.apps/mysql-release 1/1 4m3s
K10 automatically discovers the MySQL database instance, and you will see the data and associated resources for this instance.
Step 3: Backup Strategies Workflow
Now we are ready to discuss the two backup strategies we mentioned before:
- Crash consistent volume snapshots
Crash Consistent Backup
Crash consistent backups are the default way of taking backups. This strategy relies on the crash consistency provided by the data service, in this case, the MySQL database. All backups can be exported to external target storage systems such as object stores. This post demonstrates the various backup/restore workflows. Using crash-consistent volume snapshots requires no additional configuration.
On the MySQL instance, click “snapshot” to manually backup.
Progress can be seen on the dashboard:
Please follow the instructions here for creating a location profile. This profile represents the object store used for backups. This step is required to ensure successful backups and restores in the remaining sections of this tutorial.
We start by creating a namespace called mysql-logical and installing MySQL in it:
$ kubectl create namespace mysql-logical
$ helm install --namespace mysql-logical mysql-release bitnami/mysql
Next, we create a MySQL blueprint by running the following command:
$ kubectl apply -f
https://raw.githubusercontent.com/kanisterio/kanister/master/examples/stable/mysql/mysql-blueprint.yaml -n kasten-io
Add an annotation to the MySQL release deployment:
$ kubectl --namespace mysql-logical annotate statefulset/mysql-release
Now the MySQL database instance is ready for the Logical backup. You can create a backup manually or by creating a policy.
For this post, we will create a manual backup by clicking on the snapshot button on the mysql-logical application card.
The progress of the backup can be seen on the dashboard.
The process of restoring an application using K10 is simple, just click on the restore button on the application card.
Next click on the restore point.
Now click on the restore button:
We can watch the progress in the dashboard:
This quick tutorial demonstrates how easy it is to take backups of a MySQL database with Kasten K10 deployed on a GKE cluster. The default mechanism of backup can be done by clicking on the snapshot button, referred to as Crash Consistent backup. A backup can also be performed by using the Logical dump of the database, which is done by creating a MySQL release blueprint and annotating the MySQL release database deployment. Finally, restoring a Kubernetes application is as simple as clicking on the restore button located on the application card.
Try it out for yourself.
I encourage you to give K10 a try for FREE no sign-up needed, and let us know how we can help. We look forward to hearing from you!
Onkar Bhat is a member of the technical staff at Kasten and has been working on solving problems pertaining to data protection and disaster recovery in cloud native environments. His focus has been in the areas of authentication and authorization for multi-tenant and self-service data protection in Kubernetes. He previously worked as a Technical Lead in the SDN controller team at Big Switch Networks, which was acquired by Arista Networks in 2020. Prior to Big Switch, Onkar worked at NetApp on the SnapMirror team, backup and disaster recovery for on-prem storage, and the Altavault product, a cloud backup appliance. He has also worked on the Catalyst 6K team in the area of deep packet inspection at Cisco Systems. Onkar received his MS from Carnegie Mellon University.