OpenShift operators
Last updated
Last updated
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.
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.
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.
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 |
