Permalink
Fetching contributors…
Cannot retrieve contributors at this time
40 lines (29 sloc) 3.52 KB

Architecture, design considerations and prior art

Architecture

ReShifter's architecture is as follows:

ReShifter architecture

  • You can make backups and restore of a Kubernetes cluster, either by storing the archive (ZIP file with the content of the underlying etcd) locally or in a remote location (S3-compatible object storage).
  • Both the server (exposing a HTTP API) and the CLI tool rcliare leveraging the ReShifter library github.com/mhausenblas/reshifter/pkg.
  • All you need to supply is access to etcd in the form of a URl such as http://localhost:2379. If etcd is used in a secure more you'll need to supply the certs and key. If you want to back up to and restore from the remote storage, you'll additionally need to provide the credentials (access key ID and secret access key) for the S3-compatible object storage endpoint.

Design considerations

The basic idea of ReShifter is to work against the etcd API. That means, backing up and restoring the state of objects in a Kubernetes cluster on the etcd API level: not below as tools like etcdctl do it, and also not on a higher level, such as using the Kubernetes API Server-level. This brings a couple of advantages and disadvantages into play:

  • We're independent of what the API Server does or how many of them are there.
  • We operate with the logical state of the objects, not a low-level representation of the serialization.
  • We need to re-implement some of the logic already present in the API Server, for example, dealing with the different data models etcd v2 and v3 have.
  • Performance-wise it should be on-par or better than the API Server-level.
  • There will be challenges ahead with all sorts of encrypted content.
  • There is state relevant to a Kubernetes cluster, outside of what is in etcd. One such an example are certificates. It is yet an open question to what extent, if at all ReShifter should take care of this.

Prior art and related solutions

In the course of researching the backup/restore topic in the context of Kubernetes I've come across the following attempts, solutions, and proposals: