Catalogic Software Debuts Open Source Backup Tool for Kubernetes
Catalogic Software has made available the open source KubeDR utility for backing up and recovering Kubernetes cluster configuration, certificates and metadata residing in an etcd repository.
Company COO Sathya Sankaran says Catalogic Software has been working to extend the reach of its backup and recovery software for Kubernetes and that KubeDR represents an effort to give back to the open source community. The company’s backup and recovery software already have been extended to support instances of Red Hat OpenShift, which is based on a distribution of Kubernetes, running in OpenStack environments.
As part of that effort, Catalogic Software, which spun out of Syncsort in 2013, has created Catalogic Labs, committed to developing additional open source data protection technologies.
KubeDR is designed to enable IT organizations to recover Kubernetes configuration, certificates and metadata stored in an S3-compatible object storage system. The idea is to make it easier for IT organizations to recover a Kubernetes cluster in the event of a failure. IT teams still need a separate tool to back and recover any application data that might have been lost as well.
Additional capabilities provided included with KubeDR include the ability to pause and resume backups, restore etcd snapshot and certificates and cleanup of older of snapshots based on retention settings.
Now that IT organizations are deploying Kubernetes clusters that process stateful data in production environments, interest in data protection tools for both Kubernetes clusters and the applications that run on them is on the rise. The challenge many IT organizations will face achieving that goal is not just the sheer number of Kubernetes clusters they might be running, but also the rate at which containerized applications are updated. Also, it’s not clear whether data protection will be addressed within the context of programmatic DevOps processes or handled by storage administrators using some type of tool accessed via a graphical user interface (GUI). Right now, the number of storage administrators who have experience with Kubernetes clusters is rather limited, so in many cases, DevOps teams are likely to forge ahead on their own. How long any of those DevOps teams want to remain responsible for Kubernetes data protection will depend on the relationship they have with the rest of the IT department, assuming one exists.
The good news is Kubernetes clusters are resilient in terms of providing failover capabilities, and the Technical Oversight Committee that drives the development of Kubernetes has made providing high-availability capabilities across multiple Kubernetes clusters a higher priority in 2020. However, the possibility still exists that any number of infrastructure issues could lead to a Kubernetes cluster failure.
Competition among providers of data protection tools capable of supporting Kubernetes clusters is already heating up. The decision to go with one approach versus another will be determined as much by who in the IT organization is making the decision as the capabilities of the tool. Regardless of approach, however, tolerance for Kubernetes cluster downtime is going to be minimal.
