Supported Kubernetes Operator SDK workflows

This blog post is part of the series How to leverage Kubernetes operators using the Operator SDK framework.

IN A PREVIOUS BLOG POST WE TALKED ABOUT:

 Section 1 – Operators, Operator Framework, and Operators SDK, and in particular:

  • in a general setting about Operators, Operator Framework, and Operators SDK.
  • the Operators SDK emerging popularity on GitHub, and in general about the “Operator SDK workflow” adopted for generating and handling operators.

IN THIS BLOG POST WE WILL TALK ABOUT:

Section 2 – Supported Kubernetes Operator SDK workflows

  • Here we discuss about the three available alternative workflows to generate Operators provided by the last versions of Operator SDK APIs.
  • We also discuss the pros and cons of using the various operators’ workflows.

Section 2 – Supported Operator SDK workflows

As discussed before, on GitHub, the Operator SDK is a very active project, with over 10 releases produced in less than a year. This means that the Operator SDK is a toolkit that is continuing evolving over the time (e.g., its code,  structure, and logic is changing). In particular, as reported in the main Github page of the operator SDK, the libraries and tools are labeled with “Project Status: pre-alpha”, and thus are “expected breaking changes to the API in the upcoming releases”.

The project started in April 2018 and we started monitoring it intensively from September 2018. We found out that the SDK provides three different workflows to develop operators based on GoAnsible, or Helm.

These versions of the Operators SDK emerged between 2018 and 2019. Specifically, the first version of the operator was based on Go, and only from December 2018 it was provided a version based on Ansible.

Finally, in the beginning of 2019 (January), the operator workflow based on Helm was also released.

Thus, the SDK provides a workflow to develop operators based on GoAnsible, or Helm.

The following workflow is for a new Go operator:

      1. Create a new operator project using the SDK Command Line Interface (CLI)
      2. Define new resource APIs by adding Custom Resource Definitions (CRD)
      3. Define Controllers to watch and reconcile resources
      4. Write the reconciling logic for your Controller using the SDK and controller-runtime APIs
      5. Use the SDK CLI to build and generate the operator deployment manifests

The following workflow is for a new Ansible operator:

      1. Create a new operator project using the SDK Command Line Interface (CLI)
      2. Write the reconciling logic for your object using Ansible playbooks and roles
      3. Use the SDK CLI to build and generate the operator deployment manifests
      4. Optionally add additional CRD’s using the SDK CLI and repeat steps 2 and 3

The following workflow is for a new Helm operator:

      1. Create a new operator project using the SDK Command Line Interface (CLI)
      2. Create a new (or add your existing) Helm chart for use by the operator’s reconciling logic
      3. Use the SDK CLI to build and generate the operator deployment manifests
      4. Optionally add additional CRD’s using the SDK CLI and repeat steps 2 and 3

Guidelines:

Command Line Interface: To learn more about the SDK CLI, see the SDK CLI Referenceor run operator-sdk [command] -h.

For a guide on Reconcilers, Clients, and interacting  with resource Events, see the Client API doc.

As it is possible to see from the following figure, there is not much difference among the various operator workflows.

However, the workflow that has reached more maturity and gives more control over the operator behavior is the one based on Go:

Go-Operator-building-simplified-with-SDK_VSHN

Next article

Section 3 – Examples of Supported Operator SDK workflows

 

Back to overview

Back to overview How to leverage Kubernetes operators using the Operator SDK framework.