- Big Data
- 4.2K
Kanister Operator
Kanister is a framework that enables application-level data management on Kubernetes. It allows domain experts to…
Kanister is a framework that enables application-level data management on Kubernetes. It allows domain experts to…
Kanister is a framework that enables application-level data management on Kubernetes. It allows domain experts to capture application specific data management tasks via Blueprints, which can be easily shared and extended. The framework takes care of the tedious details surrounding execution on Kubernetes and presents a homogeneous operational experience across applications at scale.
The design of Kanister was driven by the following main goals:
Application-Centric: Given the increasingly complex and distributed nature of cloud-native data services, there is a growing need for data management tasks to be at the application level. Experts who possess domain knowledge of a specific application’s needs should be able to capture these needs when performing data operations on that application.
API Driven: Data management tasks for each specific application may vary widely, and these tasks should be encapsulated by a well-defined API so as to provide a uniform data management experience. Each application expert can provide an application-specific pluggable implementation that satisfies this API, thus enabling a homogeneous data management experience of diverse and evolving data services.
Extensible: Any data management solution capable of managing a diverse set of applications must be flexible enough to capture the needs of custom data services running in a variety of environments. Such flexibility can only be provided if the solution itself can easily be extended.
Allow experts with domain knowledge of a specific application to provide a set of required data management primitives. Encapsulate key data management tasks in blueprints that allow uniform operations at scale.
All Kanister operations are declarative and require an ActionSet to be created by the user. Once the ActionSet is detected by the Kanister controller, it examines the environment for Blueprint referenced in the ActionSet (along with other required configuration). If all requirements are satisfied, it will then use the discovered Blueprint to complete the action (e.g., backup) specified in the ActionSet. Finally, the original ActionSet will be updated by the controller with status and other metadata generated by the action execution.
Users interact with Kanister through Kubernetes resources known as CustomResources (CRs). When the controller starts, it creates the CR definitions called CustomResourceDefinitions (CRDs).
Blueprint CRs are a set of instructions that tell the controller how to perform actions on a specific application.
A Blueprint contains a field called Actions which is a mapping of Action Name to BlueprintAction.
Creating an ActionSet instructs the controller to run an action now. The user specifies the runtime parameters inside the spec of the ActionSet. Based on the parameters, the Controller populates the Status of the object, executes the actions, and updates the ActionSet’s status.
The controller watches for new/updated ActionSets in the same namespace in which it is deployed. When it sees an ActionSet with a nil status field, it immediately initializes the ActionSet’s status to the Pending State. The status is also pre-populated with the pending phases.
Execution begins by resolving all the Template Parameters. If any required object references or artifacts are missing from the ActionSet, the ActionSet status is marked as failed. Otherwise, the template params are used to render the output Artifacts, and then the args in the Blueprint.
For each action, all phases are executed in-order. The rendered args are passed to Template Parameters which correspond to a single phase. When a phase completes, the status of the phase is updated. If any single phase fails, the entire ActionSet is marked as failed. Upon failure, the controller ceases execution of the ActionSet.
Within an ActionSet, individual Actions are run in parallel.
Currently the user is responsible for cleaning up ActionSets once they complete.
During execution, Kanister controller emits events to the respective ActionSets.
Tell us about a new Kubernetes application
Never miss a thing! Sign up for our newsletter to stay updated.
Discover and learn about everything Kubernetes
