K8up consists of two parts:
High Level Description
k8up operator is deployed as a cluster wide Kubernetes Operator.
It is responsible for processing the
Backup resources and to satisfy the defined
When it’s time to do a backup, the operator scans the namespace for matching PVCs and creates a backup job in the corresponding namespace.
It mounts the matching PVCs under
Restic then backups the data from this location to the configured endpoint.
The following diagram shows a high-level architecture of K8up internals. This is mainly aimed at developers helping to understand the code. But it could be interesting for anyone trying to understand an issue they may face with K8up.
Schedule is defined by the user.
It contains rules, when to archive, backup, check or prune.
Whenever it’s time to do one of these actions, the operator will create a corresponding object in the cluster.
For example, if a backup needs to be performed, a new instance of the
Backup custom resource is created.
There is an
EffectiveSchedule object for each
It is not meant to be edited by users.
It contains the effective times of the scheduled actions.
The reason is that the schedule specification can contain such schedules as
EffectiveSchedule stores the actual time when such schedules actually happen.
Backup, Prune, Archive, Check, Restore
These custom resources are usually created by a
Schedule, but users may create them as well.
The exception is the
Restore custom resource, which is always created manually by a user.
Whenever a new instance of one of these custom resources is detected, a corresponding
Job is created.
Job will contain at least one
Pod will contain a single container with the
The image is invoked as
All the relevant parameters are extracted by the
k8up operator from the specific action objects, from the schedule or from the global configuration of
These parameters are then passed to
k8up restic as command line arguments and as environment variables.
k8up operator also ensures that the relevant
PVC is mounted into the
Job, usually as
Job that runs
k8up restic contains the logic to perform the requested actions using the underlying
It uses the same Docker image as the
k8up operator is usually running for a long time,
k8up restic will do the job it is tasked to do and then exit.
It also does not modify any resources in the Kubernetes cluster or leave permanent traces.
But it will look for
Pod resources that are annotated.
And it will also create one-off containers in the
Pod resources it finds that are annotated with
k8up.io/backupcommand in order to run the respective backup command and collect it’s output.