Chapter 2
Architecture and Design of Kanister
Beneath Kanister's user-friendly surface lies a sophisticated architectural framework engineered for declarative, scalable, and highly customizable data management in Kubernetes. This chapter pulls back the curtain on Kanister's design-revealing how its core abstractions, controllers, and security mechanisms converge to deliver robust data workflows. Discover the blueprint-driven philosophies, extensibility principles, and advanced observability that position Kanister as a leader in cloud-native data operations.
2.1 Kanister Core Concepts and CRDs
Kanister orchestrates application-level data management operations in Kubernetes environments through a set of specialized Custom Resource Definitions (CRDs). These CRDs-Blueprint, ActionSet, and Profile-encapsulate declarative abstractions that enable the specification, execution, and credential management of complex data workflows. Together, they comprise the conceptual core of Kanister, facilitating modularity, reusability, and clear separation of concerns.
The Blueprint is the primary resource that defines reusable workflows via a collection of actions. Each action corresponds to a discrete data operation, such as backup, restore, or data verification. Formally, a Blueprint manifests as a YAML document specifying an array of actions, where each action references a Kubernetes function implemented as a callable curl, kubectl, or shell command within a container. The parameters to these actions are defined declaratively to allow parametrization at runtime.
The design of Blueprint focuses on decoupling the workflow logic from runtime state. Users author Blueprints to encode "what" operations need to be performed sequentially or conditionally without prescribing "how" credentials or parameters are provided. This separation fosters reusability across multiple applications or environments by using parameter substitution during invocation.
Where the Blueprint describes the workflow, the ActionSet resource captures the instantiation of this workflow against concrete application instances. This allows Kanister to execute the specified actions with application-specific parameters and credential references. The ActionSet links to a Blueprint and provides runtime input for its parameters, including secret references and contextual data such as namespaces or resource identifiers. This resource encapsulation enables multiple isolated runs of the same workflow specification, each customized to different data domains or cluster contexts.
The Profile CRD abstracts credential and configuration management necessary for interacting with external infrastructure and data stores. It contains references to Kubernetes Secrets and environment variables, encapsulating authentication details, endpoint URLs, encryption keys, and other parameters required by Blueprint functions at runtime. By decoupling sensitive configuration from workflow definitions and executions, Profile enhances security and compliance while enabling credential rotation without modifying workflow specifications.
These three CRDs maintain a clear division of responsibilities:
- Blueprint: Encodes reusable, parameterized workflows as a sequence of actions.
- ActionSet: Represents concrete invocations of Blueprints with environment-specific parameter binding and execution state tracking.
- Profile: Supplies credentials and environment configuration to facilitate secure and customizable data access during action execution.
The relationships among these CRDs are fundamental for Kanister's declarative orchestration model. Their interplay is illustrated in the figure below:
The encapsulation of workflow logic, execution context, and credentials into discrete custom resources not only enhances maintainability but also simplifies extension and integration. Users can author complex backup, restore, or migration workflows independently of infrastructure-specific secrets and policies. Furthermore, multiple ActionSets can run concurrently or sequentially from the same Blueprint, tailored via distinct Profiles to support heterogeneous environments.
Below is an illustrative example of a simplified Blueprint defining two actions: backup and restore. Each action specifies a function invoking a containerized tool with parameters provided at runtime.
apiVersion: kanister.io/v1alpha1 kind: Blueprint metadata: name: sample-app-blueprint actions: - name: backup phases: - func: BackupFunction args: - name: appNamespace type: string - name: backupLocation type: string - name: restore phases: - func: RestoreFunction args: ...
