Project: Operator Framework (App Definition and Development / Application Definition & Image Build)
File: plugins.md

title: Plugins linkTitle: Plugins weight: 7 SDK uses the project as a library for the CLI and plugins features. For further information see the document. To better understand its motivations, check the design documentation . 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 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: ```sh operator-sdk init --plugins=kustomize ``` Also, see the topic to understand how it works. 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 manifests ) | | PROJECT | Project configuration. Stores the data used to do the scaffolds. For further information see | | bundle.Dockerfile | Docker image which is used to provide the helpers to integrate the project with OLM. (e.g. ) | | config/ | Directory which has all manifest to configure and test the project | You can check the to better understand the files and directories scaffolded by SDK CLI, which may be common for each language-type. By default plugins are used by the Operator SDK to provide the following features: : perform the required scaffolds to provide the helpers to allow the projects to be integrated with OLM. : perform the required scaffolds to provide the feature. Users can also use custom plugins when they execute the SDK CLI sub-commands as a helper which includes the following options: ```sh 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 . (e.g versus ). 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. 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 . 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 to see how you can benefit and apply this approach.