Skip to content

Latest commit

 

History

History
45 lines (30 loc) · 3.57 KB

modularization.md

File metadata and controls

45 lines (30 loc) · 3.57 KB

Modularization

Modules are the next generation of components in Kyma that are available for local and cluster installation.

Modules are no longer represented by a single helm-chart, but instead are bundled and released within channels through a ModuleTemplate custom resource (CR), a unique link of a module, and its desired state of resources and configuration, and a channel.

Lifecycle Manager manages clusters using the Kyma CR. The CR defines the desired state of modules in a cluster. With the CR you can add and delete modules with domain-specific functionality with additional configuration.

The modules themselves are built and distributed as OCI artifacts. The internal structure of the artifact conforms to the Open Component Model scheme version 3. Modules contain an immutable layer set of a module operator deployment description and its configuration.

Kyma Module Structure

If you use Kyma CLI, you can create a Kyma module by running kyma alpha create module. This command packages all the contents on the provided path as an OCI artifact and pushes the artifact to the provided OCI registry. Use the kyma alpha create module --help command to learn more about the module structure and how it is created. You can also use the CLI's auto-detection of Kubebuilder projects to easily bundle your module with little effort.

The modules are installed and controlled by Lifecycle Manager. We use Open Component Model to describe all of our modules descriptively. Based on the ModuleTemplate CR, the module is resolved from its layers and version and is used as a template for the Manifest CR. Whenever a module is accepted by Lifecycle Manager the ModuleTemplate CR gets translated into a Manifest CR, which describes the actual desired state of the module operator.

The Lifecycle Manager then updates the Kyma CR of the cluster based on the observed status changes in the module CR (similar to a native Kubernetes deployment tracking availability).

Module operators only have to watch their custom resources and reconcile modules in the target clusters to the desired state.

Example

A sample Kyma CR could look like this:

apiVersion: operator.kyma-project.io/v1beta1
kind: Kyma
metadata:
  name: my-kyma
spec:
  modules:
  - name: my-module

The creation of the Kyma CR triggers a reconciliation that:

  1. Looks for a ModuleTemplate CR based on the search criteria, for example, the OCM Component Name of the module or simply the name of the ModuleTemplate CR.
  2. Creates a Manifest CR for my-module based on a ModuleTemplate CR found in the cluster by resolving all relevant image layers for the installation.
  3. Installs the content of the modules operator by applying it to the cluster, and observing its state.
  4. Reports back all states observed in the Manifest CR which then get propagated to the Kyma CR on the cluster. Lifecycle Manager then uses the observed states to aggregate and combine the readiness condition of the cluster and determine the installation state or trigger more reconciliation loops as needed.

As mentioned above, when each module operator completes their installation, it reports its resource status. However, to accurately report the state, we read out the .status.state field to accumulate status reporting for the entire cluster.