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 to do so, 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, 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 actions or defining policies for applications protected with Kanister.

Note

Make sure that the credentials specified in the Location 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

Backups can be performed on Managed Services like Amazon RDS 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:

Amazon RDS

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.

Kafka Backup and restore

K8ssandra Backup and Restore

K8ssandra is a cloud native distribution of Apache Cassandra® (Cassandra) designed to run on Kubernetes. K8ssandra follows the K8s operator pattern to automate operational tasks. This includes metric, data anti-entropy services, and backup/restore tooling. More details can be found here.

K8ssandra operator uses Medusa to backup and restore Cassandra data. K10 platform integrates with Medusa operator to perform backup and restore of Cassandra data.

K8ssandra Logical Backup

Crunchy Data Postgres Operator Backup and Restore

The Postgres Operator (PGO) developed by Crunchy Data automates and simplifies deploying and managing open source PostgreSQL clusters on Kubernetes.

PGO provides some out of the box features like high availability, disaster recovery, and monitoring, all over secure TLS communications. More details can be found here.

PGO uses open source pgBackRest to backup and restore Postgres data. K10 platform integrates with PGO to perform backup and restore Postgres data using the operator APIs.

Crunchy Data Postgres Operator Logical Backup and Restore

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.

To take advantage of automated blueprint assignment by K10 without the need of manual annotating, please refer to Blueprint Bindings.

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.