Developing with the Operator SDK
The first pillar of the Operator Framework is the Operator SDK. As with any other software development toolkit, the Operator SDK provides packaged functionality and design patterns as code. These include predefined APIs, abstracted common functions, code generators, and project scaffolding tools to easily start an Operator project from scratch.
The Operator SDK is primarily written in Go, but its tooling allows Operators to be written using Go code, Ansible, or Helm. This gives developers the ability to write their Operators from the ground up by coding the CRDs and reconciliation logic themselves, or by taking advantage of automated deployment tools provided by Ansible and Helm to generate their APIs and reconciliation logic depending on their needs.
Developers interact with the Operator SDK through its operator-sdk command-line binary. The binary is available on Homebrew for Mac and is also available directly from the Operator Framework GitHub repository (https://github.com/operator-framework/operator-sdk) as a release, where it can also be compiled from source.
Whether you are planning to develop an Operator with Go, Ansible, or Helm, the Operator SDK binary provides commands to initialize the boilerplate project source tree. These commands include operator-sdk init and operator-sdk create api. The first command initializes a project's source directory with boilerplate Go code, dependencies, hack scripts, and even a Dockerfile and Makefile for compiling the project.
Creating an API for your Operator is necessary to define the CRD required to interact with the Operator once it is deployed in a Kubernetes cluster. This is because CRDs are backed by API type definitions written in Go code. The CRD is generated from these code definitions, and the Operator has logic built in to translate between CRD and Go representations of the object. Essentially, CRDs are how users interact with Operators, and Go code is how the Operator understands the settings. CRDs also add benefits such as structural validation schemas to automatically validate inputs.
The Operator SDK binary has flags to specify the name and version of the API. It then generates the API types as Go code and corresponding YAML Ain't Markup Language (YAML) files based on best-practice standard definitions. However, you are free to modify the definitions of your API in whichever way you choose.
If we were to initialize a basic Operator for an application such as the one first demonstrated at the start of this chapter, the steps would be relatively simple. They would look like this:
$ mkdir sample-app $ cd sample-app/ $ operator-sdk init --domain mysite.com --repo github.com/sample/simple-app $ operator-sdk create api --group myapp --version v1alpha1 --kind WebApp --resource –controller $ ls total 112K drwxr-xr-x 15 mdame staff 480 Nov 15 17:00 . drwxr-xr-x+ 270 mdame staff 8.5K Nov 15 16:48 .. drwx------ 3 mdame staff 96 Nov 15 17:00 api drwxr-xr-x 3 mdame staff 96 Nov 15 17:00 bin drwx------ 10 mdame staff 320 Nov 15 17:00 config drwx------ 4 mdame staff 128 Nov 15 17:00 controllers drwx------ 3 mdame staff 96 Nov 15 16:50 hack -rw------- 1 mdame staff 129 Nov 15 16:50 .dockerignore -rw------- 1 mdame staff 367 Nov 15 16:50 .gitignore -rw------- 1 mdame staff 776 Nov 15 16:50 Dockerfile -rw------- 1 mdame staff 8.7K Nov 15 16:51 Makefile -rw------- 1 mdame staff 422 Nov 15 17:00 PROJECT -rw------- 1 mdame staff 218 Nov 15 17:00 go.mod -rw-r--r-- 1 mdame staff 76K Nov 15 16:51 go.sum -rw------- 1 mdame staff 3.1K Nov 15 17:00 main.go
After this, you would go on to develop the logic of the Operator based on the method you choose. If that's to write Go code directly, it would start by modifying the *.go files in the project tree. For Ansible and Helm deployments, you would begin working on the Ansible roles or Helm chart for your project.
Finally, the Operator SDK binary provides a set of commands to interact with OLM. These include the ability to install OLM in a running cluster, but also install and manage specific Operators within OLM.