Kanister is a data protection workflow management tool. It provides a set of cohesive APIs for defining and curating data operations by abstracting away tedious details around executing data operations on Kubernetes. It's extensible and easy to install, operate and scale.
✅ Kubernetes centric - Kanister's APIs are implemented as Custom Resource Definitions that conforms to Kubernetes' declarative management, security and distribution models.
✅ Storage agnostic - Kanister allows you to efficiently and securely transfer backup data between your services and the object storage service of your choice. Use Kanister to backup, restore, and copy your data using your storage's APIs, and Kanister won't get in the way.
✅ Asynchronous or synchronous task execution - Kanister can schedule your data
operation to run asynchronously in dedicated job pods, or synchronously via
Kubernetes apimachinery ExecStream
framework.
✅ Re-usable workflow artifacts - A Kanister blueprint can be re-used across multiple workflows to protect different environment deployments.
✅ Extensible, atomic data operation functions - Kanister provides a collection of easy-to-use data operation functions that you can add to your blueprint to express detailed backup and restore operation steps, including pre-backup scaling down of replicas, working with all mounted volumes in a pod etc.
✅ Secured via RBAC - Prevent unauthorized access to your workflows via Kubernetes role-based access control model.
✅ Observability - Kanister exposes logs, events and metrics to popular observability tools like Prometheus, Grafana and Loki to provide you with operational insights into your data protection workflows.
Follow the instructions in the installation documentation, to install Kanister on your Kubernetes cluster.
Walk through the tutorial to define, curate and run your first data protection workflow using Kanister blueprints, actionsets and profiles.
The examples
directory contains many sample blueprints that you
can use to define data operations for:
The Kanister architecture is documented here.
If you have any questions or run into issues, feel free to reach out to us on Slack.
GitHub issues or pull requests that have been inactive for more than 60 days
will be labeled as stale. If they remained inactive for another 30 days, they
will be automatically closed. To be exempted from the issue lifecycle, discuss
with a maintainer the reasons behind the exemption, and add the frozen
label
to the issue or pull request.
If you discovered any security issues, refer to our SECURITY.md
documentation for our security policy, including steps on how to report
vulnerabilities.
The Kanister community meetings happen once every two weeks on Thursday, 16:00 UTC, where we discuss ongoing interesting features, issues, and pull requests. Come join us! Everyone is welcome! 🙌 (Zoom link is pinned on Slack)
If you are currently using Kanister, we would love to hear about it! Feel free
to add your organization to the ADOPTERS.md
by submitting a
pull request.
Kanister is for everyone. We ask that our users and contributors take a few minutes to review our Code of Conduct.
We welcome contributions to Kanister! If you're interested in getting involved, please take a look at our guidelines:
BUILD.md: Contains detailed instructions on how to build and test Kanister locally or within a CI/CD pipeline. Please refer to this guide if you want to make changes to Kanister's codebase. Build and Test Instructions
CONTRIBUTING.md: Provides essential information on how to contribute code, documentation, or bug reports, as well as our coding style and commit message conventions. Contribution Guidelines
Apache License 2.0, see LICENSE.