mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
63 lines
3.0 KiB
Plaintext
63 lines
3.0 KiB
Plaintext
// Module included in the following assemblies:
|
||
//
|
||
// * architecture/architecture.adoc
|
||
|
||
[id="operators-overview_{context}"]
|
||
= Operators in {product-title}
|
||
|
||
In {product-title}, Operators are the preferred method of packaging, deploying,
|
||
and managing services on the control plane. They also provide advantages to
|
||
applications that users run. Operators integrate with
|
||
Kubernetes APIs and CLI tools such as `kubectl` and `oc` commands. They provide
|
||
the means of watching over an application, performing health checks, managing
|
||
over-the-air updates, and ensuring that the applications remain in your
|
||
specified state.
|
||
|
||
Because CRI-O and the Kubelet run on every node, almost every other cluster
|
||
function can be managed on the control plane by using Operators. Operators are
|
||
among the most important components of {product-title} {product-version}.
|
||
Components that are added to the control plane by using Operators include
|
||
critical networking and credential services.
|
||
|
||
The Operator that manages the other Operators in an {product-title} cluster is
|
||
the Cluster Version Operator.
|
||
|
||
{product-title} {product-version} uses different classes of Operators to perform
|
||
cluster operations and run services on the cluster for your applications to use.
|
||
|
||
ifdef::openshift-enterprise,openshift-origin[]
|
||
[id="platform-operators_{context}"]
|
||
== Platform Operators in {product-title}
|
||
|
||
In {product-title} {product-version}, all cluster functions are divided into a series
|
||
of platform Operators. Platform Operators manage a particular area of
|
||
cluster functionality, such as cluster-wide application logging, management of
|
||
the Kubernetes control plane, or the machine provisioning system.
|
||
|
||
Each Operator provides you with a simple API for determining cluster
|
||
functionality. The Operator hides the details of managing the lifecycle of that
|
||
component. Operators can manage a single component or tens of components, but
|
||
the end goal is always to reduce operational burden by automating common actions.
|
||
Operators also offer a more granular configuration experience. You configure each
|
||
component by modifying the API that the Operator exposes instead of modifying a
|
||
global configuration file.
|
||
|
||
endif::[]
|
||
|
||
[id="OLM-operators_{context}"]
|
||
== Operators managed by OLM
|
||
|
||
The Cluster Operator Lifecycle Management (OLM) component manages Operators
|
||
that are available for use in applications. It does not manage the Operators that
|
||
comprise {product-title}.
|
||
OLM is a framework that manages Kubernetes-native applications as Operators.
|
||
Instead of managing Kubernetes manifests, it manages Kubernetes Operators.
|
||
OLM manages two classes of Operators, Red Hat Operators and certified Operators.
|
||
|
||
Some Red Hat Operators drive the cluster functions, like the scheduler and
|
||
problem detectors. Others are provided for you to manage yourself and use in
|
||
your applications, like etcd. {product-title} also offers certified Operators,
|
||
which the community built and maintains. These certified Operators provide an
|
||
API layer to traditional applications so you can manage the application through
|
||
Kubernetes constructs.
|