Five key questions about Kubernetes backup answered

The backup gap

Containers exist in a backup blackspot. They are often managed by DevOps teams, and as temporary or cloud-based technologies, they might not be visible to IT teams’ backup and recovery specialists.

Conventional tools that back up virtual machines are not best-suited to containers, which could run in a range of locations, locally and in the cloud. Virtual machine (VM) backup tools, for example, are still designed to back up disks and volumes.

“You might have very, very critical data generated by these applications running in containers,” says ESG analyst Christophe Bertrand. “The fact that this is about to become the production platform of choice emphasises the need for excellent backup and recovery capabilities.”

Here, we break out five of the most important considerations for protecting Kubernetes infrastructure.

1. Do you always need to back up containers and Kubernetes?

The answer today is almost always yes. The earlier, stateless containers were designed to do their task, such as handle a dataset, and then disappear. Those use cases still exist, but an enterprise is likely to want to be able to recreate the container or cluster after an outage and be able to access its data.

According to Bertrand, organisations need a strong backup policy that supports development and production containers. Data protection tools need to recognise the Kubernetes environment and, for example, adjust policy if a container or cluster is promoted from development to production.

2. What should you protect in Kubernetes?

At the top level, container users need to protect their orchestrated clusters. That includes on-premise operations, in Linux or Windows, in the cloud, and through any managed Kubernetes platform-as-a-service (PaaS) instances, including those from Google, Amazon Web Services, or Microsoft Azure. Failing to protect orchestration raises the real risk that the business process or application cannot be rebuilt after a failure.

In a cluster, the stateful components are held in the etcd key value database, so the etcd control plane is the most critical part as it links persistent storage to the containers as well as recording the environment’s state.

The organisation then needs to protect applications, including pods, deployments, statefulsets and workloads.

Persistent volumes need to be protected, as do persistent volume claims. Finally, firms need to back up custom resource definitions, namespace definitions and container image registries that run inside Kubernetes.

Worker nodes are designed to spin up easily, but IT teams should check they can do this in production after an outage, especially if they run containers on local hardware.

3. What are the main methods to back up Kubernetes environments?

The primary methods of Kubernetes backup are specialist tools, or enterprise backup applications that have been updated to support containers and Kubernetes. Conventional backup tools are unlikely to make frequent enough copies, or have the reach across systems to capture all the states in a production Kubernetes environment.

At the lowest level, developers might be able to use Cron jobs to create snapshots of etcd, to capture configurations and data. A Kubernetes deployment could even be recreated from git repos.

The open source tool kube-backup exports configured Kubernetes resources to a git repository, although that is an approach that is unlikely to scale. Nor will it deal with persistent volumes.

Snapshots, however, are the main tool to back up production Kubernetes environments. It is the frequency that sets container backup apart from other tools, however. Commvault’s Metallic, for example, provides full and incremental backups. The supplier describes its approach as “forever incremental backups”, which can be used to build a full backup.

Ensuring critical data is stored outside a node’s local disk will also make recovery more reliable.

4. Which are the key Kubernetes backup tools?

Most of the large storage suppliers now support protection for containers in some form. Backup for entire Kubernetes environments relies more on specialist tools.

Commvault supports Kubernetes through its software-as-a-service (SaaS)-based Metallic VM & Kubernetes Backup. This works with Azure AKS and Amazon EKS, as well as Red Hat OpenShift and VMWare Tanzu.

Kasten is a Kubernetes data management supplier, now owned by Veeam. Its K10 application works in the cloud and on-premise.

Portworx PX-Backup can back up containers, clusters or entire Kubernetes namespaces. The supplier is now owned by Pure Storage.

Trilio’s TrilioVault is a cloud-native data protection application that works with OpenShift and Kubernetes, and is cloud platform-agnostic.

OS tool Velero (previously Heptio ARK) can back up and recover Kubernetes clusters as well as persistent storage, both on-premise and in the cloud.

5. How do you incorporate Kubernetes backup into existing disaster recovery and backup processes?

Building an entirely new backup and recovery infrastructure for Kubernetes can be resource-intensive, and risks leaving gaps in protection.

“If your incumbent backup vendor has a solution, then it’s worth checking it out as it simplifies the process, but making sure it works at scale,” advises ESG’s Bertrand. “It will help with DR [disaster recovery] if native container backup can be integrated with existing DR.”

If not, CIOs should look at native Kubernetes protection as the most robust. But the market is evolving quickly, Bertrand notes, with more suppliers building more capabilities. As Kubernetes becomes more mainstream, protecting it in production should become easier.