Skip to content

Kanister

An extensible open-source framework forapplication-level data management on Kubernetes

image/svg+xml
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?

icon-webinars

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.

icon-books

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.

icon-FAQ

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.

image/svg+xml
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