Today, the CNCF Technical Oversight Committee (TOC) voted to accept the Operator Framework, which is made up of two main components Operator SDK and Operator Lifecycle Manager (OLM) as an incubation-level hosted project.
The Operator Framework is an open source toolkit for managing Kubernetes native applications, called Operators, in an automated and scalable way. Operators are a design pattern, made public in 2016 by CoreOS, now part of Red Hat, to add operational knowledge into software. Previously this knowledge only resided in the minds of administrators, various combinations of shell scripts, or automation software.
“The common assumption is that stateful applications should not be run on Kubernetes,” said Diane Mueller, Operator Framework maintainer, and director, Community Development at Red Hat. “These workloads require continuous care and lifecycle management to function well. Providing this care would be outside of the scope of Kubernetes. Operators change that and extend Kubernetes capabilities to all workload types. The Operator Framework supplies the open source tool kit for developers to create Kubernetes native applications, aka Operators, and provides cluster administrators with central control on the cluster without the need to be experts in API management.”
“The Operator Framework builds on other CNCF technologies enabling administrators and end-user developers to run Kubernetes native applications,” said Katie Gamanji, TOC member, and cloud platform engineer at American Express. “Operators provide a suite of structured templates to build custom resources for the cluster, igniting the automation of the most complex workloads. This unlocks a tremendous amount of growth for the CNCF ecosystem.”
Operator Framework’s Main Components:
Operator Lifecycle Manager (OLM) extends Kubernetes to provide a declarative way to install, manage, and upgrade Operators and their dependencies in a cluster. It enables Kubernetes administrators to discover and safely install Operators from catalogs and keep them up-to-date in an automated way.
Main OLM Features:
- Over-the-Air Updates and Catalogs: OLM has a concept of catalogs from which Operators are available to install and are kept up to date.
- Dependency Model: With OLMs packaging format, Operators can express dependencies on the platform and other Operators.
- Discoverability: OLM advertises installed Operators and their services into the namespaces of tenants. They can discover which managed services are available and which Operator provides them.
- Cluster Stability: OLM will prevent conflicting Operators from owning the same APIs being installed, ensuring cluster stability.
- Declarative UI controls: For graphical consoles, OLM annotates APIs with descriptors that drive the creation of rich interfaces and forms for users to interact with the Operator.
Operator SDK provides high-level APIs, useful abstractions, and project scaffolding for building Kubernetes applications and uses the controller-runtime library to make writing operators easier. It enables developers and package maintainers to write, test, and validate Operators in an iterative fashion and distribute updates to the community.
Operator SDK Features:
- High-level APIs and abstractions to write the operational logic more intuitively
- Tools for scaffolding and code generation to bootstrap a new project fast
- Extensions to cover common operator use cases
Many CNCF projects have Operators today, including Envoy, etcd, Jaeger, NATS, Prometheus, Rook, and Vitess. Helm is supported as a way to create Operators using the SDK. Internal Operators exist at organizations, including Amadeus, Kohl’s, SAP Concur, SIX Group, TicketMaster, Uber, Zalando, and more.
Notable Milestones:
-
- Three SDKs: Go, Ansible, and Helm
- 10,000+ clones of the SDKs
- 137 contributors to Operator SDK
- 86 contributors to OLM
- 38 unique organizations contributing
“Operators have been popular among the cloud native community for years with a number of CNCF projects featuring their own,” said Chris Aniszczyk, CTO of Cloud Native Computing Foundation. “We are thrilled that the Operator Framework community is coming into CNCF, empowering even more projects and organizations to create and share operators.”
Future planned feature adds for Operator SDK include a unified foundation with upstream kubebuilder, controller-runtime, and more, a single command in SDK to install OLM on a given cluster, and a refactored testing tool with the ability to include custom tests. For OLM, the maintainers plan to simplify API surfaces, focus on local developer experience and registering private catalogs of Operators, use a new bundle format, and streamline upgrades using implied server path vs. explicit mappings.
“We are so excited that the Operator Framework has been accepted into CNCF at incubation level,” said Erin Boyd, Operator Framework maintainer, and principal software engineer at Red Hat. “Operators make life easier for Kubernetes developers, and we are so excited to work with the CNCF to make this process even more seamless.”
While the components of Operator Framework are designed to work together, there are no hard dependencies. Operator SDK does not depend on OLM for the Operator to run, and OLM does not require the Operator to be created with Operator SDK.
As a CNCF hosted project, joining incubating technologies like OpenTracing, gRPC, CNI, Notary, NATS, Linkerd, Rook, etcd, OPA, CRI-O, TiKV, CloudEvents, Falco, Argo, Dragonfly, and SPIFFE and SPIRE, and Contour, The Operator Framework is now part of a neutral foundation aligned with its technical interests, as well as the larger Linux Foundation, which provides the project with governance, marketing support, and community outreach.
Every CNCF project has an associated maturity level: sandbox, incubating, or graduated. For more information on maturity requirements for each level, please visit the CNCF Graduation Criteria v.1.3.
Learn more about the Operator Framework, visit https://operatorframework.io/
Get Involved