Kanister-Enabled Applications

K10 defaults to volume snapshot operations when capturing data, but there are situations where customization is required. For example, the best way to protect your application's data may be to take a logical dump of the database. This requires using tools specific to that database.

Kanister uses Blueprints to define these database-specific workflows and open-source Blueprints are available for several popular applications. It's also simple to customize existing Blueprints or add new ones.

When configured correctly, K10 will automatically use Kanister Blueprints and manage the resulting application-level Kanister artifacts.

Configuring a Kanister Profile

The Kanister Blueprints provided use object storage to manage data artifacts. To make this storage accessible to Kanister Blueprints, you need to first configure a Kanister Profile from the Settings section of the dashboard or via the CRD-based Profiles API.

../_images/kanister_profile_none.png

Kanister Profile creation is very similar to creating an Export Profile and you can follow the same instructions. The only significant difference is that K10 currently only supports a single Kanister profile. Once the profile is configured, the information stored in it will be made available to the Blueprints for all Kanister-enabled applications so that they can manage data artifacts.

Note

You will need to make sure that the credentials specified in the Kanister Profile have sufficient permissions to perform LIST, PUT, GET, and DELETE for the object storage location.

Installing Applications and Blueprints

Blueprints typically require no modifications to the application and most Blueprints are written to work with stable helm charts. The Kanister GitHub repository contains several Blueprints that work with helm charts from the stable helm repository.

As a prerequisite for installing charts from the stable helm repository, please run the following commands:

$ helm repo update
$ helm repo add stable https://kubernetes-charts.storage.googleapis.com/
$ helm repo update

The following application-specific instructions are available:

Specifying a Kanister Blueprint for Your Application

To request K10 to use a Kanister Blueprint to manage a workload (e.g., Deployment or StatefulSet), please (a) create the Blueprint in the K10 namespace (default kasten-io) and (b) annotate the workload with the name of the created blueprint as follows:

$ kubectl --namespace=<app-namespace> annotate <workload>/<workload-name> \
    kanister.kasten.io/blueprint=<blueprint-name>

Finally, note that the Blueprint used must have a backup and restore action defined and ideally a delete action for retirement too.

Use Case Testing

Once you have installed your application, you will be able to use the K10 Dashboard to bring the application in compliance and protect it by creating one or more policies. You can also subsequently restore the application and its data to a previous version. You can find more detailed instructions in the Protecting Applications and Restoring Applications sections of this documentation.

If you are testing on a cluster that in not running on AWS or GKE you should consider the following limitations:

  • If the namespace of your application contains additional workloads that use persistent volumes but do not have a Kanister Blueprint, you will not be able to use namespace based protection policies. You will still be able to use workload-based policies for the Kanister enabled workloads.