Deckhouse Kubernetes Platform (DKP) supports both built-in modules and modules that can be fetched from a module source. This section describes how to create and run a custom module in the cluster using the module source.

There are three key stages in the life of a module:

  • Development: creating module code and its structure in the Git repository. The Module structure section describes the required components and the directories where they are located.
  • Building and publishing: creating a module artifact and pushing it to the container registry. The Building and publishing section describes where images are stored in the registry and what images are available.
  • Running in a cluster: installing a module in a DKP cluster, enabling it, configuring it, and making sure it works as expected. The Running in a cluster section describes how to run a configured module in a cluster.

Requirements

You will need the following tools to develop DKP modules:

  • git — version control system;
  • sed — stream editor;
  • yq — CLI tool for processing data in JSON, YAML, and XML formats;
  • jq — CLI tool for processing data in JSON, YAML, and XML formats;
  • werf — (optional) CLI tool for building images. You will need it for building module artifacts locally;
  • crane — (optional) CLI tool for working with the container registry. You may need it when debugging.

The container registry where module artifacts will be stored must support a nested repository structure. A registry such as Docker Registry v2 or Harbor is a good choice.

Before you start

To get an idea of how DKP modules work, check out addon-operator and shell-operator.

  • Review the operator documentation on the concept of hooks, e.g., what a hook configuration is and what functions it provides. The configuration is used to configure the data that will be available from the hook.
  • Check out bindings. Bindings are events that trigger the hook. They are specified in the hook configuration. A hook can be triggered not only by Kubernetes events, but also, e.g., on a schedule or before a module is started.

    The Hook allows you to keep values in memory and use them later when rendering Helm templates. We recommend reading the Hooks and Helm values section to learn more about this feature as well as the module’s operating cycle.

  • Explore the concept of snapshots. With snapshots, you can implement a reconciliation loop approach that is more efficient than event subscription.

    This is how DKP implements support for all existing backend module hooks.

  • Additionally, hooks can be used instead of the Prometheus exporter. Hooks can provide metrics that DKP will export. See metrics.

Got a question?

The Development and debugging section contains information about what tools can be used in module development and approaches to troubleshooting module errors.

Join the community, where you’ll be sure to have your questions answered.