Testing Kanister-Enabled Applications

The instructions below are intended to help you test Kanister-enabled applications. You can use this guide if you have a Kasten-provided test drive or if you are testing a self-install in your own environment.

Configuring a Kanister Profile

The Kanister blueprints provided use an S3-compatible object store 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 a Migration 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 profile location. You will also want to make sure that any retention policy configured on the location allow deletions so that artifacts can be reclaimed based on your intended data backup retention.

Installing Test Applications

To facilitate testing, you can install Kanister-enabled applications using Kanister-enabled Helm charts that will install the application instance as well as the appropriate Kanister blueprint to be used with it.

Prior to install you will need to have the Kanister Charts repository added to your local setup:

$ helm repo add kanister https://charts.kanister.io/

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.