Plugins
Overview
SDK uses the project Kubebuilder as a library for the CLI and plugins features. For further information see the Plugins document. To better understand its motivations, check the design documentation Integrating Kubebuilder and Operator SDK.
SDK Language-based plugins
All language-based operator projects provided by SDK (Ansible/Helm/Golang) follow the Kubebuilder standard and have a common base. The common base is generated using kustomize which is a project maintained and adopted by Kubernetes community to help work with the Kubernertes manifests (YAML files) that are used to configure the resources on the clusters.
The specific files for each language are scaffolded for the language’s plugins. The Operator SDK CLI tool can provide custom plugins and helpers which are common and useful for all language types. To check the common base, you can also run:
operator-sdk init --plugins=kustomize
Also, see the topic Language-based Plugins to understand how it works.
Common scaffolds
Following the default common scaffolds for the projects which are built with SDK.
| File/Directory | Description |
|---|---|
| Dockerfile | Defines the operator(manager) image |
| Makefile | Provides the helpers and options for the users. (e.g. make bundle which generate/update the OLM bundle manifests ) |
| PROJECT | Project configuration. Stores the data used to do the scaffolds. For further information see Project Config |
| bundle.Dockerfile | Docker image which is used to provide the helpers to integrate the project with OLM. (e.g. operator-sdk run ./bundle) |
| config/ | Directory which has all kustomize’s manifest to configure and test the project |
You can check the Project Layout to better understand the files and directories scaffolded by SDK CLI, which may be common for each language-type.
Custom Plugins
By default plugins are used by the Operator SDK to provide the following features:
- manifests.sdk.operatorframework.io: perform the required scaffolds to provide the helpers to allow the projects to be integrated with OLM.
- scorecard.sdk.operatorframework.io: perform the required scaffolds to provide the Scorecard feature.
Optional/custom plugins
Users can also use custom plugins when they execute the SDK CLI sub-commands as a helper which includes the following options:
operator-sdk create api --plugins="go/v3,declarative"
The above example will scaffold custom code in the controllers after an API is created to allow the users to develop solutions using the kubebuilder declarative pattern. (e.g default scaffold versus example).
Note that custom plugins are called via the init sub-command to work as global plugins, and will be added in the layout field of the PROJECT file. Any sub-command executed will then also be called.
Plugins Vision
Contributors are able to create their own plugin(s) using the same standards and approach described by this document. Following them facilitates in-tree (in other words, built with the operator-sdk binary) addition of such community-driven plugins to the Operator SDK project by making review easier and code maintainable. Currently, the SDK cannot discover and use plugins that are not in-tree. However, out-of-tree plugins have been discussed in kubebuilder/issues/1378.
How to create your own plugins
If you are looking to develop similar solutions to allow users for example to create projects using other languages or that could work as helpers for the projects built with SDK/Kubebuilder projects, then see the Creating your own plugins to see how you can benefit and apply this approach.