Operator Framework Moves to CNCF for Incubation

We are thrilled to announce that Red Hat will be donating the Operator Framework project to the Cloud Native Computing Foundation (CNCF) to be hosted as a CNCF Incubated project. 

As a CNCF hosted project – alongside technologies like Kubernetes, Prometheus, Helm and many more – the Operator Framework is now part of a neutral foundation aligned with its technical interests. It is also a part of the larger Linux Foundation, which provides the project with governance, marketing support and community outreach.

Over the last several months, Operator Framework maintainers have been working closely with the community to improve everything from processes to codebase. These changes have put the Operator Framework closer to existing CNCF efforts in this space, for example Kubebuilder or cluster-addons. Since being put forward to the CNCF as a candidate for Incubation in October 2019, the Operator Framework project has seen a marked increase in overall community participation, downloads, contributors, commits, and forks. 

What is an Operator? 

Operators are a design pattern made public in a 2016 CoreOS blog post. The goal of an Operator is to put operational knowledge into software. Previously this knowledge only resided in the minds of administrators, various combinations of shell scripts or external automation software. It was outside of your Kubernetes cluster and hard to integrate. With Operators, this logic would be running inside the cluster in the same goal-seeking, consensus driven way that Kubernetes operates.

Operators implement and automate common Day-1 (installation, configuration, etc) and Day-2 (re-configuration, update, backup, failover, restore, etc.) activities in a piece of software communicating and integrating with Kubernetes concepts and APIs (see Operator maturity model). We call this a Kubernetes-native application. With Operators you can stop treating an application as a collection of primitives like Pods, Deployments, Services or ConfigMaps, but instead as a single object that only exposes the knobs that make sense for the application.

Operators make use of Kubernetes’ extension mechanisms (Custom Resources Definitions) to allow for interaction via standard kubectl tooling and integration in GitOps workflows.

What is the Operator Framework?

The Operator Framework is an open source toolkit to manage Kubernetes native applications, aka Operators, in an effective, automated, and scalable way. The Operator Framework has two main components: Operator Lifecycle Management (OLM) and the Operator SDK. 

Operator SDK: Enables developers to build Operators based on their expertise about the managed application without requiring a lot of the boilerplate code that usually comes with working against the Kubernetes API. The Operator SDK enables 3 types of Operators today:

• Golang Operator: Operator is written in Go using controller-runtime for abstraction and Kubebuilder for scaffolding. Existing Kubebuilder projects are compatible and the Operator SDK binary supports Kubebuilder commands. Full flexibility with the Kubernetes API.
• Ansible Operator: Operator logic is expressed in Ansible Playbooks and roles. Kubernetes API integration is abstracted away but full control over the execution flow on the cluster remains.
• Helm Operator: Any helm chart can be converted to behave like an Operator. The resulting Operator creates and updates releases of the chart(s) on demand. No coding required.

The SDK also ships with a test harness for Operators and the ability to define custom unit, end-to-end and functional tests to create high quality Operators.

Operator Lifecycle Manager: Central point on cluster for installation, configuration, and updating of Operators (and their associated services). Provides a metadata format and packaging model for Operators into larger collections (catalogs) for continuous updates and dependency resolution. Main features include:

• Over-the-air updates of Operators (automatic or manual)
• Dependencies between Operators during installation and updates
• Discoverability of Operators available to install for cluster admins (Operator catalogs)
• Discoverability of Operators available to use in a namespace for cluster users
• Safeguards when installing Operators against conflicting APIs ownership and format to prevent data loss and corruption
• Declarative UI controls for dynamically generated forms in graphical frontends

OLM uniquely addresses the challenges of CRD lifecycle management, a novel problem in the days of Kubernetes being a universally extensible platform of platforms.

Get Involved

Discuss on:

• Kubernetes Slack in #kubernetes-operators (Get invite)
• Operator Framework on Google Groups
• Operator Lifecycle Manager Development on Google Groups
• Operator Framework Commons SIG

Learn more about the Operator Framework here: https://operatorframework.io/