Red Hat® OpenShift® Operators automate the creation, configuration, and management of instances of Kubernetes-native applications. Operators provide automation at every level of the stack—from managing the parts that make up the platform all the way to applications that are provided as a managed service.
Red Hat OpenShift uses the power of Operators to run the entire platform in an autonomous fashion while exposing configuration natively through Kubernetes objects, allowing for quick installation and frequent, robust updates. In addition to the automation advantages of Operators for managing the platform, Red Hat OpenShift makes it easier to find, install, and manage Operators running on your clusters.
Included in Red Hat OpenShift is the Embedded OperatorHub, a registry of certified Operators from software vendors and open source projects. Within the Embedded OperatorHub you can browse and install a library of Operators that have been verified to work with Red Hat OpenShift and that have been packaged for easy lifecycle management.
See examples of how Operators work and how to build them with the Operator Framework and SDK.
The Operator Framework is an open source project that provides developers and cluster administrators tooling to accelerate development and deployment of an Operator.
The project includes the Operator software development kit (SDK) for building Kubernetes applications, a management framework for extending Kubernetes with Operators, and a catalog of existing Operators from the Kubernetes community.
With access to community Operators, developers and cluster admins can try out Operators at various maturity levels that work with any Kubernetes. Check out the community Operators on OperatorHub.io.
With Red Hat OpenShift Certified Operators found in the Embedded OperatorHub, developers and cluster admins have access to a library of workloads "as-a-service," verified on Red Hat OpenShift and backed by Red Hat and its partners.
The Operator software development kit (SDK) provides the tools to build, test and package Operators. The SDK strips away a lot of the boilerplate code that is normally required to integrate with the Kubernetes API. It also provides a useable scaffolding so developers can focus on adding business logic (for example, how to scale, upgrade, or backup the application it manages). Leading practices and code patterns shared across Operators are included in the SDK to help prevent duplicating efforts. The SDK also encourages short, iterative development and test cycles with tooling that allow for basic validation of the Operator, and automated packaging for deployment using the Operator Lifecycle Manager.
The Operator Lifecycle Manager (OLM) is the backplane that facilitates management of operators on a Kubernetes cluster. Operators that provide popular applications as a service are going to be long-lived workloads with, potentially, lots of permissions on the cluster.
With OLM, administrators can control which Operators are available in what namespaces and who can interact with running Operators. The permissions of an Operator are accurately configured automatically to follow a least-privilege approach. OLM manages the overall lifecycle of Operators and their resources, by doing things like resolving dependencies on other Operators, triggering updates to both an Operator and the application it manages, or granting a team access to an Operator for their slice of the cluster.
Simple, stateless applications can use the Lifecycle Management features of the Operator Framework—without writing any code—by using a generic Operator (for example, the Helm Operator). However, complex and stateful applications are where an Operator can be especially useful. The managed-service capabilities that are encoded into the Operator code can provide an advanced user experience, automating such features as updates, backups and scaling.
With the metering extensions, IT teams can have greater control of their budgets and software vendors can more easily track the usage of their commercial software. Operator Metering is designed to tie into the cluster’s CPU and memory reporting, as well as calculate IaaS cost and customized metrics, like licensing.