Kubernetes has come a long way in the past several years, quickly becoming one of the defacto orchestration platforms for containerized applications. During VMware’s recent first-quarter financial earnings report, Raghu Raghuram, the new CEO of VMware said, “Given the importance of application modernization and digital initiatives at all of our customers, you can imagine why Tanzu is becoming more and more central to what we talk about with a lot of our customers. According to VMware, Tanzu is included in 50% of large VMware deployments/deals.

How Things Have Changed!

Kubernetes, once envisioned to manage primarily stateless containers, has since pivoted towards more stateful containers. Organizations often have initiatives to build new applications within containers and even to move existing applications, where possible, to containers. The objective and the end goal is in doing so is to ensure that applications can be more quickly built and are more portable.

What was once just a bunch of disposable containers which required little to no data protection in the past, now are often critical and require protecting, just like other more traditional non-container workloads such as databases and virtual machines.

VMware Tanzu Kubernetes Grid Tech Preview

Tanzu Kubernetes Grid is an enterprise-ready Kubernetes runtime that streamlines operations across a multi-cloud infrastructure. (We expect a GA release in the near future.)

Engineered to simplify installation and Day 2 operations, VMware Tanzu Kubernetes Grid (figure 1 – VMware Kubernetes Grid Service – Supervisor Cluster – vSphere Namespace) packages together key open source technologies and automation tooling to help you get up and running quickly with a scalable, multicluster Kubernetes environment.

It is tightly integrated with vSphere and can be extended to run with consistency across your public cloud and edge environments. If you are using VMware virtualization today and looking to adopt Containers, VMware Tanzu can be a great option.

Figure 1 VMware Kubernetes Grid Service Supervisor Cluster Vsphere Namespace Figure 1 – VMware Kubernetes Grid Service – Supervisor Cluster – vSphere Namespace

Types of Data

Kubernetes Objects and Persistent Volumes (PVs)

Kubernetes Objects are typically created and managed via the Kubernetes API. One of the benefits of Kubernetes is the ability to quickly and easily manage and update objects, either manually or via automation. The ability to keep backups and restores of these objects are often key in being able to recover in the case of a problematic update or delete. Another prime use of these backups? Being able to quickly and easily duplicate objects from one namespace to another on the same Kubernetes cluster or alternative cluster.

Persistent Volumes which are associated with pods via PVCs are at least as critical as non-PV objects. These Persistent Volumes often contain critical data for an application, such as database data files. In the case of a database or similar application which relies on persistent data, having backups and the ability to restore from a previous point in time is critical.

Combined, a namespace and all its objects and resources, including persistent volumes need to be able to be restored together, either to the original cluster or an alternate cluster.

Enterprise-class Backup and Recovery for your Tanzu Environment

Similar to protecting their mission-critical vSphere environment on Cohesity, organizations can now leverage the same Cohesity platform to protect their VMware Tanzu Grid and VMware Tanzu Grid Service stacks. Benefits include:

  • Ease of registering a Kubernetes Cluster – Even if Kubernetes itself may be somewhat complicated, protecting namespaces should not be. With a few simple steps, one can be protecting a Kubernetes cluster in no time with Cohesity.
  • Auto Discovery – Discovery of Kubernetes objects and services, at and after registration.
  • Auto Protect – Manually selecting namespaces to be protected works but lacks flexibility in a rapidly changing environment such as Kubernetes. By leveraging existing or new namespace metadata labels, a protection group can be dynamic, reducing or eliminating the need for an IT backup admin to update protection groups as changes happen in a Kubernetes cluster.
  • Leveraging CSI snapshots – If the CSI provisioner/driver supports the ability to take snapshots, Cohesity can leverage those in order to have greater consistency of the persistent data to be protected.
  • Compression / Deduplication –  Persistent data within a Kubernetes is not typically very large, but that is changing. Having a platform that can provide great efficiency saves money now and down the road, as more and more persistent data finds its way into Kubernetes applications.
  • Disaster Recovery – The ability to restore back to the original Kubernetes cluster is great, but what about if the primary site is gone? With a replicated copy of the backups, one can recover to a similar Kubernetes cluster in an alternative location in order to get things back up and running quickly.
  • Beyond Recovery – What if there is no disaster and I simply want to copy? Why not leverage existing backups to recover a namespace to a different name or location? This may be useful to test the ability to recover or perhaps test some changes before actually making the changes in production.
  • RBAC – Kubernetes is often used by developers who may want to perform their own on-demand backups and recoveries.  The IT backup team may not want to give full access to a developer but what if a developer could be given access only to what they need? To one specific Kubernetes cluster or perhaps only specific namespaces from which they can do their own backups and restores? What if this could be done by namespace labels even? A developer could then have much greater control over ad-hoc/on-demand backups and restores without having to reach out to the IT backup team.
  • API – Kubernetes is very much API-driven, developers love this and take advantage of it. What if the same applies to the data protection solution as well? With Cohesity, developers could opt to use the Cohesity APIs or if they prefer the Cohesity UI as well.

Easily Register a Tanzu Kubernetes Grid Cluster

To get started, the first step is to register Tanzu Kubernetes clusters. This process is straightforward and deploys the needed components within the Tanzu Kubernetes cluster needed to back up the Kubernetes environment.
Figure 2 VMware Kubernetes Grid Service Tanzu Guest clusters
Figure 2 – VMware Kubernetes Grid Service – Tanzu Guest Clusters

Figure 3 Kubernetes Cluster Source Registration
Figure 3 – Kubernetes Cluster Source Registration

Backing up Your Namespaces and Applications

Cohesity backs up, the namespaces selected. The frequency, retention, replication, and archive settings are determined based on the group policy, which is completely configurable. These backups include all relevant resources and objects within the namespaces, including the persistence volume claims (PVCs) and their backing persistence volumes (PVs). The backups themselves can be replicated or archived in addition to the backups residing within the local to the Cohesity cluster. The same global deduplication applies to Tanzu backups as that of other sources, taking full advantage of the power of the Cohesity platform.
Figure 4 Tanzu Kubernetes Protection Group Run Details
Figure 4 – Tanzu Kubernetes Protection Group Run Details

Restoring Your Namespaces and Applications

For recovery, you can restore from any prior backup. If desired, you can choose to rename the namespace and/or restore it to an alternative Tanzu cluster. All resources and objects within the namespace are restored. In the event the restored namespace still exists, Cohesity will not overwrite existing resources and objects but will restore any that are missing/deleted.
Figure 5 Tanzu Kubernetes Namespace Restore Adding Prefix Suffix and to an Alternative Tanzu Cluster

Figure 5 – Tanzu Kubernetes Namespace Restore, adding prefix/suffix, and to an alternative Tanzu cluster

Tying It All Together

Kubernetes is a dynamic platform and, like it, your data protection solution needs to be just as capable of addressing today’s and tomorrow’s challenges.

With VMware Tanzu guest clusters, which can be created quickly and easily, the key is being able to register and protect these newly created Tanzu clusters efficiently.

The agility that VMware Tanzu gives you in deploying and managing Kubernetes environments is awesome; pairing VMware Tanzu with a powerful and agile data protection platform like Cohesity is a win-win.

Justin Willoughby
Justin Willoughby
Justin Willoughby
Justin Willoughby

Solutions Engineer

Justin architects, builds, tests, and validates business-critical applications, databases, and virtualization solutions with Cohesity’s DataProtect platform.

See All Authors
Solutions Engineer
Justin Willoughby
Justin Willoughby
Solutions Engineer
Justin Willoughby
Justin Willoughby

Solutions Engineer

Justin architects, builds, tests, and validates business-critical applications, databases, and virtualization solutions with Cohesity’s DataProtect platform.
See All Authors

You May Also Like

Blog

Don’t Forget to Back Up Your Newest Kubernetes-based Applications

Learn more
X
Icon ionic ios-globe

You are now leaving the German section of www.cohesity.com/de/ and come to an English section of the site. Please click if you want to continue.

Don't show this warning again