Hello. In this demo, we will see how to protect Rancher K3S Kubernetes cluster workloads deployed on SUSE Linux Enterprise and Micro Operating System using PowerProtect Data Manager. Before proceeding with data protection, let's briefly explore the Rancher K3S Kubernetes cluster setup in the Rancher Management Server. We see a custom K3S cluster with the name TME Solutions. The provider is K3S, and the Kubernetes version is 1.26. This K3S cluster consists of three nodes: one node has all the roles, and the other two are worker nodes.
In the case of this custom cluster TME Solutions, PowerProtect Data Manager can be integrated directly with the downstream cluster node L1 DPDVCLD 085.hop.lab.emc.com, which has all the roles for the persistent storage of this cluster. We have Vsphere Data Store Services integrated using the Vsphere CSI driver. For this demo, I have deployed a PostgreSQL application on this cluster within the namespace Postgres TME, and this is the respective PVC that is bound to the PostgreSQL application pod.
Let's explore the cluster from the command line interface. We can see three nodes in this cluster, one control plane, and two worker nodes. The operating system image for these nodes is SUSE Linux Enterprise Micro version 5.5. As mentioned earlier, we see the namespace Postgres TME, where the PostgreSQL application pod is running. Let's get the namespace details. We see that the PostgreSQL application pod, postgres-0, is running in the PVC. We see the VMware storage class vsphere-csi-sc. From the vCenter in the container volume section, we see a volume created for the PostgreSQL application.
Let's connect to the pod to access the application. We are now connected with the PostgreSQL database. For this demo, I've created a sample database called employee_details. This is the sample table 'employees' that I've created on this database. Let's now protect the corresponding PostgreSQL database, PVC, and namespace with PowerProtect Data Manager. By logging into the PowerProtect Data Manager UI, we have PowerProtect DD Virtual Edition integrated with PowerProtect Data Manager as primary protection storage. From infrastructure, we select asset sources. We see the asset source with the name K3S cluster, which is my K3S custom downstream workload cluster.
I have already integrated the downstream K3S workload cluster with PowerProtect Data Manager using the cluster service account token. After the integration and asset discovery of the cluster is successful, the namespaces and PVCs are available as assets for protection. To continue our demo, let's protect the namespace, Postgres TME, and its respective PVC, which has our PostgreSQL database running. Let's create a protection policy to protect the respective namespace and PVC.
We select protection, then protection policies, click add, then enter a name for the protection policy. Select the type as Kubernetes, and select the purpose of this policy. Click add and select the asset. Enter the primary backup details. Review the summary and click finish. The protection policy configuration is now in progress. Now that the protection policy configuration is successful, let's perform a manual backup.
To do that, we select protection, and then protection policies. Select the protection policy and click Protect Now. We can now monitor the backup job from the Protection Jobs page. The manual backup is now in progress. Now that the backup has been completed successfully, let's verify the protection copy. Select Restore, then click Assets, select Kubernetes, select the namespace, click View Copies, and then select the storage target icon. The protection copy is now available and ready to restore.
We will now perform a restore for the PostgreSQL PVCs from the backup copy to a new namespace and verify the data. To start, we click Restore, then select Restore to Original Cluster. Next, we select Restore Namespace and select PVCs. Select Restore to a New Namespace. Enter a name for the new namespace, then click Next, select the PVC, review the summary, and click Restore. Now, we see that the restore job is in progress.
Let's navigate to the cluster CLI and check whether the new namespace has been created. We now see that the new namespace, Postgres TME Restore, has been created successfully. Let's go back to the PowerProtect Data Manager UI and monitor the restore. The restore is now successful. Let's verify the same from the cluster CLI. Let's get the new namespace details. We now see that the PostgreSQL database pod is running, and a new PVC has been created for this application.
Let's connect to the Postgres SQL pod and check the database and table in this new namespace. Here, we can see that the same database, employee_details, and the respective table, 'employees', that was created on the original application pod belonging to the old namespace is now available with the restored namespace. This confirms the successful backup and recovery of namespaces and PVCs that are available in the K3S clusters using PowerProtect Data Manager.
For more details about this topic, see our PowerProtect Data Manager for Kubernetes Technical White Paper and refer to the PowerProtect Data Manager Kubernetes User Guide. Thanks for watching this demo.
