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.
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.
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.
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 can be enabled if the data service needs to be quiesced before a volume snapshot is initiated.
To obtain an application-consistent backup, a
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
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
restore action defined and ideally a
delete action for
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.