OpenShift operators

About operators

Operators are pieces of software that ease the operational complexity of running another piece of software. They act like an extension of the software vendor’s engineering team, watching over a Kubernetes environment (such as OpenShift Container Platform) and using its current state to make decisions in real time. Advanced Operators are designed to handle upgrades seamlessly, react to failures automatically, and not take shortcuts, like skipping a software backup process to save time.

More technically, Operators are a method of packaging, deploying, and managing a Kubernetes application.

Why use Operators?

Operators provide:

• Repeatability of installation and upgrade.

• Constant health checks of every system component.

• Over-the-air (OTA) updates for OpenShift components and ISV content.

• A place to encapsulate knowledge from field engineers and spread it to all users, not just one or two.

For more information about using, check out the operator section in OpenShift documentation.

Operator maturity model

The level of sophistication of the management logic encapsulated within an Operator can vary. This logic is also in general highly dependent on the type of the service represented by the Operator. To this end, the following Operator Maturity model defines five phases of maturity for generic day two operations of an Operator.

Product details

Infrastructure Features

In addition to the base OpenShift Operator certification, Red Hat offers advanced certifications that cover additional criteria for specific use cases or deployment models. These certifications ensure that a partner's infrastructure product integrates with OpenShift according to best practices and use the right Kubernetes APIs for the respective use case or deployment type.

If a certified product has met the criteria of certification, its product listing page will include a certified icon along with the name of the infrastructure features. The following are currently available :

Name	Description
Container Storage Interface (CSI)	storage products providing and supporting block/file persistent backend for OpenShift trough a CSI (Container Storage Interface) driver
Container Network Interface (CNI)	products delivering networking services for OpenShift through a CNI (Container Networking Interface) plugin
Cloud-native Network Functions (CNF)	provides a Cloud-native Network Functions (CNF) Kubernetes plug-in
Disconnected	supports being mirrored into disconnected catalogs, including all dependencies, and does not require internet access
FIPS	accepts the FIPS mode of the underlying platform and works on nodes that are booted into FIPS mode
Proxy-Aware	supports running on a cluster behind a proxy. Operator accepts the standard proxy environment variables HTTP_PROXY and HTTPS_PROXY, which Operator Lifecycle Manager (OLM) provides to the Operator automatically when the cluster is configured to use a proxy. Required environment variables are passed down to Operands for managed workloads.