Kanister - An extensible framework for application 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.

Join the Kanister Community:


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

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

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