Kanister
An extensible open-source framework forapplication-level data management on Kubernetes
KANISTER allows domain experts to capture application specific data management tasks in blueprints which can be easily shared and extended. The framework takes care of the tedious details around execution on Kubernetes and presents a homogeneous operational experience across applications at scale.
Kanister is available as an open-source project today!
$ git clone git@github.com:kanisterio/kanister.git
# install Kanister operator controller
$ kubectl apply -f bundle.yaml
# install your application
$ kubectl apply -f examples/mongo-sidecar/mongo-cluster.yaml
# use an existing blueprint, tweak one, or create one yourself
$ kubectl apply -f examples/mongo-sidecar/mongo-blueprint.yaml
# perform operations (requires setting secrets and configmap)
$ kubectl create -f examples/mongo-sidecar/backup-actionset.yaml
Why Use Kanister?
Experts in the driver seat
Allow experts with domain knowledge of a specific application to provide a set of required data management primitives.
Encapsulate key data management tasks in blueprints that allow uniform operations at scale.
Community knowledge bank
Leverage a robust collection of blueprints for common persistent state applications maintained by the community.
Customize blueprints to fit specific needs of your environment and workload without starting from scratch.
Minimal application changes
Keep application images unchanged by including required tools as a sidecar container or as a separate pod.
Avoid changes to the application specification in most cases. When needed, use simple annotations.
Getting started with Kanister in three easy steps:
1. Identify the need for customization
A Kanister custom blueprint may be needed...
...when application-level management is required for data stores, including distributed and eventually consistent ones, or for local-storage only systems.
...for complex distributed applications which use custom mechanism to coordinate data persistence across several different data repositories.
2. Use an existing blueprint or author your own
Determine if a community contributed blueprint exists for your application. You can always customize it for your specific needs or create a custom solution.
Application Definition
apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
name: mongo
spec:
serviceName: "mongo"
replicas: 3
template:
metadata:
labels:
role: mongo
annotations:
kanister.kasten.io/blueprint: mongodb
Kanister Blueprint
actions:
backup:
type: StatefulSet
phases:
- func: KubeExec
name: backupPhase
args:
namespace: ''
pod: ''
container: ''
command:
- bash
- -c
- mongodb-consistent-backup ...
restore:
type: StatefulSet
phases:
- func: KubeExec
name: restorePhase
args:
namespace: ''
pod: ''
container: ''
command:
- bash
- -c
- mongorestore ...
migrate:
...
othercustomaction:
3. Leverage Kanister
Kanister is based on the operator pattern and provides a consistent interface for data management operations across applications.
The framework handles low-level Kubernetes details around execution and monitoring allowing you to focus on operational logic.
$ cat <<EOF | kubectl apply -f -
apiVersion: cr.kanister.io/v1alpha1
kind: ActionSet
metadata:
generateName: mongo-backup-
spec:
actions:
- name: backup
blueprint: mongo-blueprint
object:
kind: StatefulSet
name: mongo-cluster
namespace: default
profile:
apiVersion: v1alpha1
kind: profile
name: default-profile
namespace: default
...
EOF