This post analyzes potential value of the Operator Framework to the Kubernetes community. Operator Framework is an open source project which was released last week at KubeCon.

CoreOS introduced the term Kubernetes Operator in Nov 2016. An Operator is an application-specific controller that extends Kubernetes to create, configure, and manage instances of complex applications. ‘Kubernetes Operator’ is not a native Kubernetes term; it primarily represents combination of two native Kubernetes terms: 1) Kubernetes CRD (Custom Resource Definition) and 2) Kubernetes Controller that manages CRD/s. The Operator term has been well accepted by the community and a simple Github search on ‘Kubernetes Operator’ gives 186 repository results. Operators have been written for various platform elements such as etcd, Prometheus, Postgres, Elasticsearch, Kafka, Redis, Spark, etc.

The Operator Framework aims to simplify building and managing Operators. It currently includes two components:

Operator SDK : Enables developers to build Operators

: Enables developers to build Operators Operator Lifecycle Management: Oversees lifecycle of Operators e.g. installation, updates, etc.

The announcement mentions that soon an additional component for Operator Metering will be added to enable usage reporting.

Analysis of the Operator SDK

We see following two benefits of the Operator SDK.

1) Less code is required to get started with when developing an Operator. We did a quick comparison of the number of steps required when using manual method of creating CRD/Operator code and when using the Operator SDK. The common steps between the two approaches are creating CRD type definitions and writing the Operator’s reconciliation logic (the control loop). However, other steps from the manual method, such as creating the required directory structure, defining the registration and doc files, are automated by the SDK.

2) Abstracting details of the client-go library — The relationship between your Operator code, the Operator SDK, and the client-go library is shown in the following figure.

Operator SDK and Your Operator Interactions

The Operator SDK with its abstracted interface — a call-back function with context and event as provided parameters — hides the details which you otherwise have to know such as work queue, Indexer, Informer, Object key.

We think that the main concern with the SDK is whether it will be sufficient for Operator developers to work only with the abstracted interface; or it will be beneficial for them to still have basic understanding of the client-go library and its semantics when developing and debugging their Operator code.

Analysis of the Operator Lifecycle Manager (OLM)

Today, lifecycle management of an Operator can be done using kubectl or Helm. The lifecycle management of the application itself is part of the Operator’s controller logic.

Operator framework introduces two meta-operators (OLM Operator and Catalog Operator) and a custom resource (ClusterServiceVersion) towards lifecycle management of custom Operators. ClusterServiceVersion is essentially a manifest definition which is supposed to be used by Kubernetes administrators to define the composition of an Operator. It includes things such as — how an Operator should be deployed, what Custom Resource types the Operator is managing, what native Kubernetes resources will the Operator be using, etc. For a given Operator, OLM requires that the Custom Resource types managed by that Operator be already registered in the Cluster. Registering these types can be done using the Catalog Operator or by the Kubernetes administrator manually. OLM will instantiate your Operator only after this requirement is satisfied. These steps are shown in the following figure.

Operator Lifecycle Manager

It seems that the main advantage of using the Operator framework is that OLM can perform seamless upgrades of your Operator to newer versions. One of the challenges when it comes to Operator upgrades is, how to handle custom resource instances that were managed by the previous version of the Operator. Potentially, you can write your new Operator such that it is aware of the previous version and takes ownership of those instances. But this won’t be a scalable approach as custom logic would need to be written for every upgrade (v→v+1). As per the documentation, OLM solves this problem. It knows about the two versions and can update the ownership information for each custom resource instance to point to the new version of your Operator.

Overall, the Operator Framework is a welcome contribution as it seems to be solving immediate problems of Operator developers and Kubernetes cluster administrators.

What about end users of Operators?

Operator Framework seems to target two types of personas. SDK is targeting Operator developers and OLM is targeting Kubernetes cluster administrators. But what about the end users though?

We believe that what is really missing in this space is how to improve the consumability of Operators by the end users. They are application developers who are building their application platforms on Kubernetes using Operators/CRDs as their platform elements. A typical application platform these days can consist of more than one Operator, such as Prometheus, Postgres, Nginx, Fluentd, etc. In such situations, there is a genuine need to bring more consistency in the end user experience of the Operators by answering questions like — how can end users know about functions offered by new CRDs, what knobs are offered to them to customize the applications managed by Operators, how can they diagnose any issues in applications managed by Operators.

www.cloudark.io