Krish | 06 June 2018
CoreOS recently introduced an open source tool kit called Operator Framework, after the success of their Prometheus Operator.
An Operator is a domain specific controller that extends the Kubernetes API to create, configure and manage custom resource instances. It extends the Kubernetes controller concept, but also includes domain specific knowledge to automate common tasks such as backup, scale, perform automated upgrade etc…
Operator Framework helps us to accelerate the development of a customer operator which includes:
Operator SDK makes it much easier for developers to build Kubernetes native custom operators, with minimal knowledge of Kubernetes API complexities required.
Before you start building an operator:
The Operator Lifecycle Manager must be installed in the cluster and Kubernetes version should be 1.8 or above to support the apps/v1beta2 API group.
Operator SDK must be installed on your development environment which requires ‘go 1.10+’, ‘dep’, ‘docker’ and ‘git’
As soon as the SDK is installed on your local development environment, you can generate applications that are simple, stateless and Kubernetes-native. The command for this is operator-sdk new app-operator --api-version=app.example.com/v1alpha1 --kind=App, which in turn will:
Generate a golang project with ‘busy box’ as its default custom resource instance
Define new resource APIs by adding Custom Resource Definitions (CRD)
Specify which resources to watch using the SDK API
Define the operator reconciling logic
Once your new custom operator is generated, you can use the SDK to build a docker image with operator-sdk build <docker image name>
Once built, Operators need to be deployed on a Kubernetes cluster. The Operator Lifecycle Manager (OLM) is the control plane that facilitates management of operators on a Kubernetes cluster. OLM defines packaging formats for custom operators such as ClusterServiceVersion, InstallPlan, CatalogSource and Subscription. And these resources are handled by major components - Catalog Operator and OLM Operator.
The Catalog Operator maintains application definitions and CRDs of the cluster, watches for CatalogSources / Subscriptions of a custom operator, and creates InstallPlans based on that. The OLM Operator is responsible for watching custom resource definitions in a namespace and checking that requirements are met. If so, it will run the service install / upgrade strategy for the custom operator, as illustrated in following diagram.
It is great to see that CoreOS has clearly built the Operator SDK with developers in mind, and the Operator Lifecycle Manager with Kubernetes Administrators in mind. Furthermore, there is already a growing list of Awesome Operators from the community, which can be found here. We’re looking forward to seeing where this goes in the future!