K8up is a Kubernetes backup operator based on Restic that will handle PVC and application backups on a Kubernetes or OpenShift cluster.
Just create a schedule
and a credentials
object in the namespace you’d like to backup.
It’s that easy. K8up takes care of the rest. It also provides a Prometheus endpoint for monitoring.
The documentation is written in AsciiDoc and published with Antora to k8up.io.
It's source is available in the docs/
directory.
K8up is written using Kubebuilder.
You'll need:
- A running Kubernetes cluster (minishift, minikube, k3s, ... you name it)
- kubectl and kustomize
- Go development environment
- Your favorite IDE (with a Go plugin)
- Docker
- make
To run the end-to-end test (e.g. make e2e-test
), you additionally need:
helm
(version 3)jq
node
andnpm
bash
(installed, doesn't have to be your default shell)shasum
orsha1sum
base64
find
These are the most common make targets: build
, test
, docker-build
, run
, kind-run
.
Run make help
to get an overview over the relevant targets and their intentions.
K8s consists of two main modules:
- The operator module is the part that runs constantly within K8s and contains the various reconciliation loops.
- The restic module is our interface to the
restic
binary and is invoked whenever aBackup
orRestore
(or similar) custom resource is instantiated. If it's job (like doing a backup or a restore) is done, the process ends.
/
- api Go Types for the Custom Resource Definitions (CRDs) [o]
- cmd CLI definition and entrypoints
- common Code that is not specific to either
- config Various configuration files for the Operator SDK [o]
- controllers The reconciliation loops of the operator module [o]
- docs Out ASCIIdoc code as published on https://k8up.io
- e2e The Bats-based End-To-End tests
- envtest Infrastructure code for the integration tests
- operator Code that is otherwise related to the _operator module_,
but not part of the recommended Operator SDK structure.
- restic Code that makes up the _restic module_.
[o]: this is part of the recommended Operator SDK structure
If you make changes to the CRD structs you'll need to run code generation. This can be done with make:
make generate
CRDs can be either installed on the cluster by running make install
or using kubectl apply -k config/crd/apiextensions.k8s.io/v1
.
Currently there's an issue using make install
related to how the CRDs are specified.
Therefore settle to the second approach for now.
You can run the operator in different ways:
- as a container image (see quickstart)
- using
make run-operator
(provide your own kubeconfig) - using
make kind-run
(uses KIND to install a cluster in docker and provides its own kubeconfig intestbin/
) - using a configuration of your favorite IDE
Best is if you have minio installed somewhere to be able to setup the needed env values. It needs to be reachable from within your dev cluster.
You need node
and npm
to run the tests, as it runs with DETIK.
To run e2e tests, execute:
make e2e-test
To test just a specific e2e test, run:
make e2e-test -e BATS_FILES=test-00-deployment.bats
To remove the local KIND cluster and other e2e resources, run:
make e2e-clean
To cleanup all created artifacts, there's always:
make clean
There are a number of example configurations in config/samples
.
Apply them using kubectl apply -f config/samples/somesample.yaml