Kanister Operator

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.

Design Goals

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.

 

Why Use Kanister?

Experts in the driver seat

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.

Community knowledge bank

• Leverage a robust collection of blueprints for common persistent state applications maintained by the community.
• Customize blueprints to fit specific needs of your environment and workload without starting from scratch.

Minimal application changes

• Keep application images unchanged by including required tools as a sidecar container or as a separate pod.
• Avoid changes to the application specification in most cases. When needed, use simple annotations.

Kanister Workflow

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.

Custom Resources

Users interact with Kanister through Kubernetes resources known as CustomResources (CRs). When the controller starts, it creates the CR definitions called CustomResourceDefinitions (CRDs).

Blueprints

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.

ActionSets

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.

Execution Walkthrough

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.

The post Kanister Operator appeared first on kubedex.com.