Your submission was sent successfully! Close

You have successfully unsubscribed! Close

Thank you for signing up for our newsletter!Close

Backing up Kubernetes

As with any other component of IT architecture, it is recommended to have a plan for backing up and restoring key elements of your Kubernetes cluster.

Although many believe that Kubernetes can be considered more or less stateless, that isn't really true beyond the use case of running a few ephemeral services. Unlike legacy systems running on distinct machines though, backing up a Kubernetes cluster requires some additional thought as to what components need to be backed up and how they might be restored.

The etcd distributed key-value store

Kubernetes relies on the distributed key-value store etcd to keep information such as state, configuration and metadata in a central location where it can be accessed by any pods in the cluster. The name is derived from the idea that it is an '/etc' directory for destributed systems ('d'), though it is not used purely for configuration. The etcd store is essential to the operation of Kubernetes and should be considered worthy of a backup strategy. Etcd itself includes the ability to save and restore snapshots of the stored data, which in the case of Charmed Kubernetes is exposed to the cluster operator through a Juju action. The procedure for using the action to create snapshots, store the snapshots and subsequently restore them is covered in this How To guide to backing up etcd.

Persistent storage

Depending on your use case for Kubernetes, a significant amount of important data may reside in persistent storage attached to the cluster. The importance of this data depends on the nature of what it is storing and how difficult it would be to recreate, but starting from the point of view that it is important enough to be persistent, it is likely that it is also important enough to back up. The most effective way to back up storage depends mainly on where the storage is. E.g. a public cloud will have its own snapshot/restore methods, though these may need to be triggered by the operator. Alternatively, many of the third party solutions below handle backups across a variety of cluster environments.

Backup solutions

Understandably, there are a number of third party backup solutions for Kubernetes. It is beyond the scope of our documentation to make recommendations on which may be suitable as this will largely be determined by the purpose of the cluster, its requirements and to a large extent where it is operating. We can offer some links to solutions which are widely used though.

Further reading

We appreciate your feedback on the documentation. You can edit this page or file a bug here.