Kanister - An extensible framework for application-level data management on Kubernetes
image/svg+xml

An extensible open-source framework for
application-level data management on Kubernetes

GitHub Fork us on Github!
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.

    $ 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?

image/svg+xml

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.

image/svg+xml

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: '{{ .StatefulSet.Namespace }}'
            pod: '{{ index .StatefulSet.Pods 0 }}'
            container: '{{ index .StatefulSet.Containers 0 0 }}'
            command:
              - bash
              - -c
              - mongodb-consistent-backup ...

      restore:
        type: StatefulSet
        phases:
        - func: KubeExec
          name: restorePhase
          args:
          namespace: '{{ .StatefulSet.Namespace }}'
          pod: '{{ index .StatefulSet.Pods 0 }}'
          container: '{{ index .StatefulSet.Containers 0 0 }}'
          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 accross 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