As part of my virtual VMUG tour, I submitted a session to the VMUG call for papers covering the subject of Data Protection for Tanzu Kubernetes workloads. (Most of this will apply for any Kubernetes environments).
This was picked up by Erik at the Belgium VMUG for their UserCon in June 2021. After the session the videos remain available on demand for a short time, but there were no plans to upload this for everyone. So thank you to Michael Cade, whom offered to host this session for all on the Cloud Native Data Management – YouTube Channel.
In the below session I cover the following areas;
What kind of data protection do you need?
Velero
The open source data protection project from VMware
Tanzu Mission Control
The Kubernetes fleet management platform that utilizes Velero from VMware.
3rd Party Options
A nod to the 3rd party ecosystem that offer enterprise Data Protection and Management software such as;
Kasten
PortWorx
There is even a quick technical demo in there, with a little technical hiccup I had to style out!
This blog posts covers using Kasten by Veeam to create backup policies for data protection, and how to restore your data. This blog post follows on from the two installation guides;
Deploying a PacMan browser game as test application
To provide a demo mission critical application for this blog post, I’ve deployed PacMan into my OpenShift cluster, which is accessible via a web browser to play. You can find the files from this GitHub repo to deploy into your own environment.
This application uses MongoDB to store the scores from the games to give me persistent data stored on a PVC.
You can see all of the PacMan resources below by running:
kubectl get all -n pacman
Creating a Policy to protect your deployment and data
This blog post will take you through the full steps on installing and configuring Kasten, the container based enterprise backup software now owned by Veeam Software
This deployment will be for VMware Tanzu Kubernetes Grid which is running on top of VMware vSphere.
You can read how to create backup policies and restore your data in this blog post.
For the data protection demo, I’ll be using my trusty Pac-Man application that has data persistence using MongoDB.
This sets the storage class to be used for the PV/PVCs to be created for the Kasten install. (In a TKG guest cluster there may not be a default storage class.)
You will be presented an output similar to the below.
NAME: k10
LAST DEPLOYED: Fri Feb 26 01:17:55 2021
NAMESPACE: kasten-io
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Thank you for installing Kasten’s K10 Data Management Platform!
Documentation can be found at https://docs.kasten.io/.
How to access the K10 Dashboard:
The K10 dashboard is not exposed externally. To establish a connection to it use the following
`kubectl --namespace kasten-io port-forward service/gateway 8080:8000`
The Kasten dashboard will be available at: `http://127.0.0.1:8080/k10/#/`
The K10 Dashboard is accessible via a LoadBalancer. Find the service's EXTERNAL IP using:
`kubectl get svc gateway-ext --namespace kasten-io -o wide`
And use it in following URL
`http://SERVICE_EXTERNAL_IP/k10/#/`
It will take a few minutes for your pods to be running, you can review with the following command;
kubectl get pods -n kasten-io
Next we need to get our LoadBalancer IP address for the External Web Front End, so that we can connect to the Kasten K10 Dashboard.
This creates the correct Security Contexts against the users created by the install. This is needed in OpenShift as the security context stance is higher OOTB than that of a vanilla Kubernetes install.
–set route.enabled=true
This creates a route in OpenShift using the default ingress, so that the Kasten dashboard is accessible externally. This will use the default cluster ID domain name.
–set route.path=”/k10″
This sets the route path for the redirection of the dashboard. Without this, your users will need to go to http://{FQDN}/ and append the path to the end (k10).
In this blog post we will cover the following topics
- Data Protection Overview
- Create a AWS Data Protection Credential
- Enable Data Protection on a Cluster
- Running a backup manually or via an automatic schedule
- Restoring your data
Tanzu Mission Control implements data protection through the inclusion of the Project Velero, this tool is not enabled by default. This blog post will take you through the setup.
Data is stored externally to a AWS location, with volume backups remaining as part of the cluster where you’ve connected TMC.
Currently there is no ability to backup and restore data between Kubernetes clusters managed by TMC.
Create a AWS Data Protection Credential
First we need to create a AWS data protection credential, so that TMC can configure Velero within your cluster to save the data externally to AWS.
If you are looking for supported options for protecting data to other locations, I recommend you either look at deploying Project Velero manually outside of TMC (losing access to the data protection features in the UI) or look at another enterprise service such as Kasten.io.
On the Administration screen, click Accounts, and Create Account Credential.
Select > AWS data protection credential
Set your account name for easy identification and click to generate template and save this file to your machine.
The next steps will require configuration in the AWS console to create resources using CloudFormation so that Project Velero can export data to AWS. Here is the official VMware documentation on this configuration.
In the AWS Console, go to the CloudFormation service
Click to create a new stack
Click “Template is ready” as we will provide our template file from earlier.
Click to upload a template file
Select the file from your machine
Click next
Provide a stack name and click next
Ignore all the items on this page and click next
Review your configuration and click finish.
Once you’ve reviewed and clicked create/finish. You will be taken into the Stack itself.
You can click the Events tab and the refresh button to see the progress.
