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 Profile

The Kanister Blueprints provided use object storage or NFS file storage to manage data artifacts. To make this storage accessible to Kanister Blueprints, you need to first configure a Location Profile from the Settings section of the dashboard or via the CRD-based Profiles API. Specifying a Location profile is required when executing any actions or defining any policies for the application.

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.

Note

To learn more about configuring an NFS file storage location profile, refer to this section.

Installing Applications and Blueprints

Blueprints typically require no modifications to the application and most Blueprints are written to work with respective standard Helm charts. The Kanister GitHub repository contains several Blueprints that work with respective Helm Charts.

Logical Backups

If backups are required where data is captured completely at the data service layer without requiring volume snapshots, the following examples are available today:

Managed Services Backups

If backups need to be performed on Managed Services like Amazon RDS or Google Cloud Databases, to achieve this by using the snapshot APIs of the service provider or by extracting data directly from the service through logical dumps. Following examples are available today:

Application-Consistent Backups

Application-consistent backups can be enabled if the data service needs to be quiesced before a volume snapshot is initiated.

To obtain an application-consistent backup, a quiescing function, as defined in the application blueprint, is first invoked and is followed by a volume snapshot. To shorten the time spent while the application is quiesced, it is unquiesced based on the blueprint definition as soon as the storage system has indicated that a point-in-time copy of the underlying volume has been started. The backup will complete asynchronously in the background when the volume snapshot is complete, or in other words after unquiescing the application, K10 waits for the snapshot to complete. An advantage of this approach is that the database is not locked for the entire duration of the volume snapshot process.

The following examples for application-consistent backups are available today:

etcd Backup and Restore

If a backup of all cluster state stored in etcd is required, the etcd cluster can be backed up and restored in case of catastrophic failure.

Kafka Backup and Restore

For some types of data services, the best approach to data protection may be for the service to stream data directly to object storage. Kanister Blueprints are still used to initiate the stream and to recover data, even though Kanister may not be in the data path.

Kafka, a data streaming platform, is an example of a data server where using a Blueprint to initiate a backup stream may be the preferred data protection strategy.

Logical Backups to NFS File Storage Location

Kanister Blueprints that use kando to write and read data can use NFS file storage locations. The following are some examples:

Specifying a Kanister Blueprint for Your Application

To request K10 to use a custom 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.