Almost every enterprise in the next few years expects to introduce and adopt Kubernetes in their production environment. These same enterprises also recognize moving Kubernetes into production requires it meet the same standards as their other production platforms.
Among these requirements, they must have a means to backup and recover the containerized applications they host in Kubernetes. This presents five specific backup challenges organizations should prepare to address as they host applications and data on Kubernetes.
Challenge #1: Ephemeral Storage
Deploying containerized applications in Kubernetes differs in a significant way from deploying applications on virtual machines (VMs). If an application or its hosting VM shuts down, the application’s data and VM’s storage persist. In this way, the next time the application within the VM or the VM starts up, it can access its allocated data or storage.
Kubernetes handles the data and storage resources associated with containerized applications and their pods differently. Once an application or a pod shuts down, Kubernetes automatically recoups its allocated resources, to include its storage. Once reclaimed, the data associated with that application or pod effectively becomes “lost.â€
Challenge #2: Unpredictability
The flexibility that Kubernetes offers to start containers anywhere at any time on almost any cloud heightens its appeal to enterprises. However, this same flexibility also introduces levels of unpredictability and complexity that may far exceed environments with VMs.
A backup solution must address the challenges associated with containerized applications and their ephemeral storage. It must also determine if it needs to back up each containerized application since not all containers require backups. If it does to back up the containerized application, it must use the appropriate policy to back it up.
Challenge #3: Backup Solution Scalability
Kubernetes facilitates the startup and shutdown of thousands, millions, and perhaps billions of containerized applications weekly or monthly. The backup solution must have sufficient resources to detect all the containerized applications, schedule the backup jobs, and manage them. The solution must also possess sufficient resources to do back end backup data management and perform recoveries.
Deployed in cloud infrastructures, Kubernetes further exacerbates the backup challenges. The number of active containerized applications may scale up or down dramatically and with little or no advance warning. To respond to and manage this environment, the backup solution must automatically and cost-effectively adapt to it.
Challenge #4. Breadth of Kubernetes Backup Capabilities
An enterprise’s choice of a backup solution will depend, in part, upon the maturity of its Kubernetes deployment. In a stable, more mature Kubernetes environment, an enterprise often writes scripts that automate deployment of core Kubernetes components. In these environments, an enterprise may only back up its containerized applications hosted in its Kubernetes environment.
In contrast, an enterprise that has more recently adopted Kubernetes may have different backup challenges. It may have not yet finished constructing its Kubernetes environment. Alternatively, if it has, the enterprise may question if its current Kubernetes infrastructure represents the one it wants going forward.
Challenge #5: Recovery
While backing up containerized applications presents challenges, recoveries of containerized applications present even greater challenges. To perform a recovery, the backup software must initially associate each backup with a specific application, user, or other environmental constant.
Should an enterprise need to perform a recovery, it must have some means to identify which backup to recover. The temporal nature of containerized applications in Kubernetes environments requires reliable procedures to initiate the recovery.
As part of the recovery, an enterprise also needs to determine the breadth of the recovery in the Kubernetes environment. The software may only need to recover a single containerized application. However, interdependencies may and often do exist between multiple containers. This may necessitate the concurrent recovery of multiple containers.
Navigating Kubernetes Backup Challenges
Kubernetes creates a new standard by which enterprises need to measure backup solutions. To meet them, enterprises need to manage backups differently. This change in backup management begins with selecting a backup solution designed to protect Kubernetes environments. In Kubernetes environments, the backup software must perform the following tasks dynamically:
- Detect the creation of containerized applications
- Apply the right backup policy to each one
- Identify the dependencies that may exist between various containerized applications
- Scale up or down to potentially handle millions of different backup-related activities
HYCU represents such a solution. It grants enterprises the ability to address their backup and recovery needs in a Kubernetes environment. Built upon a cloud-native architecture, HYCU automatically and dynamically scales up and down to meet changing Kubernetes backup workloads.
Delivered as a service, HYCU provides enterprises with a single solution to protect both their containerized and virtual applications. Its management console administers both Kubernetes and virtual environments. This equips enterprises to centrally schedule and perform backups; archive and copy backup copies; assign backup policies; and, perform recoveries.
Keep Up to Date with DCIG
To be notified of new DCIG articles, reports, and webinars, sign up for DCIG’s free weekly Newsletter.
Technology providers interested in licensing DCIG content or having DCIG produce custom reports, please contact DCIG for more information.
This blog entry was excerpted from a recent DCIG Technology Report, Quantifying and Responding to the Specific Challenges of Kubernetes Backup. Follow this link to a trusted third party site to access and download the entire Technology Report.