CNCF Embraces Operator Framework to Manage Kubernetes Environments

The Technical Oversight Committee (TOC) of the Cloud Native Computing Foundation (CNCF) this week voted to accept the Operator Framework as an incubation level project.

The Operator Framework is an open source toolkit for managing Kubernetes native applications, called Operators, in an automated and scalable way. An Operator is a codified set of best practices for managing software deployed on Kubernetes clusters that was originally pioneered by CoreOS prior to its acquisition by Red Hat.

At the core of the framework are two components. Operator Lifecycle Manager (OLM) provides a declarative way to install, manage and upgrade Operators and their dependencies on a Kubernetes cluster. It enables Kubernetes administrators to discover and safely install Operators from catalogs that automatically keep them current. Operators can take advantage of a packaging format to express dependencies on the platform and between Operators. OLM also prevents conflicting Operators from owning the same application programming interfaces (APIs).

Diane Mueller, director of community development for Red Hat, says that approach makes it possible for IT administrators to manage Kubernetes clusters using graphical Operator tools without requiring organizations to hire, for example, a site reliability engineer (SRE) to programmatically manage every cluster.

The second component of the framework is an Operator software development kit (SDK) high-level APIs, useful abstractions and project scaffolding for building Kubernetes applications. The SDK makes use of a 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.

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 or vice versa.

Mueller says Operators eliminate the need to rely on custom scripts that often break or don’t scale to manage Kubernetes environments.

CNCF projects have Operators today include Envoy, etcd, Jaeger, NATS, Prometheus, Rook and Vitess. In fact, one of the biggest challenges organizations that embrace Operators have is how many of them there are for each potential use case. It’s relatively simple for IT teams to create Operators. That makes it critical for IT teams to curate Operator using catalogs that surface metadata about the capabilities of each Operator depending on how it was created, says Mueller.

Naturally, there’s some confusion as to when to employ an Operator versus a Helm Chart, which provides a means to manage the YAML files relied on to spin up a Kubernetes cluster. In fact, it’s even possible to use the Operator SDK to create an Operator using Helm Charts.

At the same time, some organizations are embracing kubebuilder, a framework for building Kubernetes APIs. Mueller says in the future the Operator SDK will include a unified foundation with kubebuilder.

There will also be integrations with other controller-runtimes, the ability to employ a single command in the SDK to install OLM on a given cluster, and a refactored tool for creating custom tests. Maintainers plan to simplify API surfaces, improve the local developer experience, add the ability to register private catalogs of Operators, create a new bundle format and streamline upgrades using implied server path versus explicit mappings.

It may take a while for IT teams to navigate all the options available for managing Kubernetes clusters. The good news is regardless of skill level there will soon be no shortage of options.

Mike Vizard

Mike Vizard is a seasoned IT journalist with over 25 years of experience. He also contributed to IT Business Edge, Channel Insider, Baseline and a variety of other IT titles. Previously, Vizard was the editorial director for Ziff-Davis Enterprise as well as Editor-in-Chief for CRN and InfoWorld.

Mike Vizard has 1605 posts and counting. See all posts by Mike Vizard