Prioritizing Backup as Container Use Rises

According to a recent report from Evaluator Group, the Spring 2021 Hybrid Cloud Study, 29% of enterprises are using Kubernetes in a production environment today with another 40% testing Kubernetes with plans to go to production.

With the continued rise of container use, you would think that backup and disaster recovery would be top-of-mind. That’s not always the case. In spite of what some may think, containers do need backup.

Containers can run in an environment where the state of applications may or may not need to be preserved; called stateful or stateless container applications. If the container does not need to have its running state backed up, it is considered to be running as a stateless application. This means there is no data stored by the applications running in the container. It is running an instance of a container image. In the eventuality the new container with the application image needs to be brought up easily, it can be done by Kubernetes.

Kubernetes functions as a container orchestration engine and controls the life cycle of containers. This adds high availability to every part of the container infrastructure. This also means containers can be created and deleted as needed by any workload.  To be clear, though, this high availability should not be confused with the ability to recover from a disaster. With application modernization on the rise, developers realize the microservices architecture simplified by containers can be expanded to stateful applications, as well. This helps organizations accelerate the development cycle and deliver applications faster.

In stateful applications running in a Kubernetes cluster, the following questions/scenarios need to be considered:

  • Is Kubernetes’ built-in high availability enough to recover the data of stateful applications running within containers?
  • Can I recover from human error of deploying an incorrect config file when applications need to be moved from a test/dev environment to production, or from production to staging before an upgrade?
  • Can I bring up an application copy for test/dev to reproduce and analyze problems that cannot be run from production data?

If your answer to any of these questions is ‘I don’t know,’ then now is the time to look at your overall backup and disaster recovery (DR) strategy.

Three Common Backup Use Cases for Containers

It’s not just that containers or stateful applications running in a Kubernetes cluster need to be backed up. A recent research report from ESG Global noted, “85% of organizations believe application-consistent backup across multiple containers is critical or very important.” And, in a recent ESG Global survey of end users, “75% of respondents believe container-based applications can be backed up the same way individual applications are backed up.”

While this may be true, there are more and more challenges that present themselves when organizations try to use existing and legacy backup and recovery software solutions for containers.

Let’s start by taking a look at what data you need to back up on containers.

  • Persistent volumes – These are Kubernetes pods that use persistent storage to save applications and files.
  • Deployment files –These are typically stored as YAML files.
  • etcd – This is the central database of Kubernetes. It’s usually relatively small.
  • Telemetry configuration – Prometheus is often used to monitor K8s pods and containers. Its configuration needs to be backed up.
  • Kubernetes resources/files – As developers create resources in K8s, those resources need to be backed up with their versions.

Now let’s take a look at three common use cases as they apply to Google Kubernetes Engine (GKE).

Rolling Back Apps, Artifacts and Configurations to Original State

It is important to understand namespaces in a Kubernetes environment. Namespaces are a way to divide cluster resources between multiple users. For GKE, one of the more widely deployed containers services, it helps to simplify continuous integration/continuous delivery (CI/CD) of applications. This, in turn, helps organizations to deliver an application to the business faster and with better agility to meet a customer’s needs. GKE clusters can have more than one namespace based on specific use cases such as dev, test, system test and production.

When you take an application and move from dev to test within a GKE cluster, this means the application is moved from the dev namespace to the test namespace. If a developer pushed an application erroneously or deployed incorrect config files, you would need to roll back the app to its original state. This can be cumbersome if you don’t back up the data. When you back up, in this case, the developer can easily recover the application to its original state.

Disaster Recovery of a GKE Cluster

A GKE cluster with a persistent volume running containerized application needs DR to point to an alternate region or zone. The need to restore the entire configuration or applications to a different region or zone can be challenging. Backup, in this instance, can help recover a sub-application from a composite (custom resource) application.

Granular Recovery of GKE Objects

On the occasion when a YAML file is overwritten, corrupted or a GKE secret key needs to be restored, backup can provide the ability to restore YAML files with granularity in GKE object explorer including any of the files, volumes or K8s’ secret key to the same cluster or to an alternate cluster. Backup can also help to restore or download files and folders from volumes or from application and YAML manifests.

As container adoption is accelerating in modern hybrid and multi-cloud application environments, the way in which users need to protect these workloads and applications is changing, as well. There are equally a growing number of misconceptions relative to data protection that can compromise the ability to protect containerized workloads. It is crucial to make data protection, backup and DR as simple and cost-effective as possible, regardless of environment.

To hear more about cloud-native topics, join the Cloud Native Computing Foundation and cloud-native community at KubeCon+CloudNativeCon North America 2021 – October 11-15, 2021

Shreesha Pai Manoor

Shreesha Pai Manoor, Head of Customer Solutions, HYCU Inc. Shreesha is an engineering leader with a proven track record of product quality, customer satisfaction, and building distributed systems for cloud and enterprise. He leads HYCU’s customer success organization. Prior to HYCU, he led senior engineering and customer support positions at Dell EMC, Cisco and Wipro. He has a Master of Technology, MTech, Computer Engineering degree from Mysore University and an MBA from UMass Lowell.

Shreesha Pai Manoor has 1 posts and counting. See all posts by Shreesha Pai Manoor