mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
Break OLM & Hub content into modules and new assemblies
This commit is contained in:
Alex Dellapenta
@@ -358,6 +358,10 @@ Topics:
|
||||
Topics:
|
||||
- Name: Understanding Operators
|
||||
File: olm-what-operators-are
|
||||
- Name: Understanding the Operator Lifecycle Manager (OLM)
|
||||
File: olm-understanding-olm
|
||||
- Name: Understanding the OperatorHub
|
||||
File: olm-understanding-operatorhub
|
||||
- Name: Adding Operators to a cluster
|
||||
File: olm-adding-operators-to-cluster
|
||||
Distros: openshift-enterprise,openshift-origin
|
||||
|
||||
@@ -5,12 +5,8 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
This guide outlines the architecture of the Operator Lifecycle Manager (OLM) and
|
||||
OperatorHub and walks cluster administrators through an example of installing
|
||||
Operators to a cluster.
|
||||
|
||||
include::modules/olm-operator-lifecycle-manager.adoc[leveloffset=+1]
|
||||
include::modules/olm-operatorhub.adoc[leveloffset=+1]
|
||||
This guide walks cluster administrators through installing Operators to an
|
||||
{product-title} cluster.
|
||||
|
||||
[id="olm-installing-operators-from-operatorhub_{context}"]
|
||||
== Installing Operators from the OperatorHub
|
||||
|
||||
15
applications/operators/olm-understanding-olm.adoc
Normal file
15
applications/operators/olm-understanding-olm.adoc
Normal file
@@ -0,0 +1,15 @@
|
||||
[id="olm-understanding-olm"]
|
||||
= Understanding the Operator Lifecycle Manager
|
||||
include::modules/common-attributes.adoc[]
|
||||
:context: olm-understanding-olm
|
||||
|
||||
toc::[]
|
||||
|
||||
This guide outlines the workflow and architecture of the Operator Lifecycle
|
||||
Manager (OLM) in {product-title}.
|
||||
|
||||
include::modules/olm-overview.adoc[leveloffset=+1]
|
||||
include::modules/olm-csv.adoc[leveloffset=+1]
|
||||
include::modules/olm-architecture.adoc[leveloffset=+1]
|
||||
include::modules/olm-operatorgroups.adoc[leveloffset=+1]
|
||||
include::modules/olm-metrics.adoc[leveloffset=+1]
|
||||
11
applications/operators/olm-understanding-operatorhub.adoc
Normal file
11
applications/operators/olm-understanding-operatorhub.adoc
Normal file
@@ -0,0 +1,11 @@
|
||||
[id="olm-understanding-operatorhub"]
|
||||
= Understanding the OperatorHub
|
||||
include::modules/common-attributes.adoc[]
|
||||
:context: olm-understanding-operatorhub
|
||||
|
||||
toc::[]
|
||||
|
||||
This guide outlines the architecture of the OperatorHub.
|
||||
|
||||
include::modules/olm-operatorhub-overview.adoc[leveloffset=+1]
|
||||
include::modules/olm-operatorhub-architecture.adoc[leveloffset=+1]
|
||||
@@ -18,6 +18,6 @@ include::modules/efk-logging-deploy-storage-considerations.adoc[leveloffset=+1]
|
||||
|
||||
== Additional resources
|
||||
|
||||
For more information on installing operators,see xref:../applications/operators/olm-adding-operators-to-cluster.adoc#olm-installing-operators-from-operatorhub-olm-adding-operators-to-a-cluster[Installing Operators from the OperatorHub].
|
||||
For more information on installing operators,see xref:../applications/operators/olm-adding-operators-to-cluster.adoc#olm-installing-operators-from-operatorhub_olm-adding-operators-to-a-cluster[Installing Operators from the OperatorHub].
|
||||
|
||||
For information on scaling your Elasticsearch cluster, see xref:../logging/config/efk-logging-elasticsearch.adoc#efk-logging-elasticsearch-add-remove_efk-logging-elasticsearch[Scaling your Elasticsearch cluster].
|
||||
|
||||
@@ -29,4 +29,4 @@ include::modules/efk-logging-deploy-subscription.adoc[leveloffset=+1]
|
||||
|
||||
== Additional resources
|
||||
|
||||
For more information on installing operators,see xref:../applications/operators/olm-adding-operators-to-cluster.adoc#olm-installing-operators-from-operatorhub-olm-adding-operators-to-a-cluster[Installing Operators from the OperatorHub].
|
||||
For more information on installing operators,see xref:../applications/operators/olm-adding-operators-to-cluster.adoc#olm-installing-operators-from-operatorhub_olm-adding-operators-to-a-cluster[Installing Operators from the OperatorHub].
|
||||
|
||||
133
modules/olm-architecture.adoc
Normal file
133
modules/olm-architecture.adoc
Normal file
@@ -0,0 +1,133 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * applications/operators/olm-understanding-olm.adoc
|
||||
|
||||
[id="olm-architecture_{context}"]
|
||||
= Operator Lifecycle Manager architecture
|
||||
|
||||
The Operator Lifecycle Manager is composed of two Operators: the OLM Operator
|
||||
and the Catalog Operator.
|
||||
|
||||
Each of these Operators are responsible for managing the CRDs that are the basis
|
||||
for the OLM framework:
|
||||
|
||||
.CRDs managed by OLM and Catalog Operators
|
||||
[cols="2a,1a,1a,8a",options="header"]
|
||||
|===
|
||||
|Resource |Short name |Owner |Description
|
||||
|
||||
|ClusterServiceVersion
|
||||
|`csv`
|
||||
|OLM
|
||||
|Application metadata: name, version, icon, required resources, installation,
|
||||
etc.
|
||||
|
||||
|InstallPlan
|
||||
|`ip`
|
||||
|Catalog
|
||||
|Calculated list of resources to be created in order to automatically install or
|
||||
upgrade a CSV.
|
||||
|
||||
|CatalogSource
|
||||
|`catsrc`
|
||||
|Catalog
|
||||
|A repository of CSVs, CRDs, and packages that define an application.
|
||||
|
||||
|Subscription
|
||||
|`sub`
|
||||
|Catalog
|
||||
|Used to keep CSVs up to date by tracking a channel in a package.
|
||||
|
||||
|OperatorGroup
|
||||
|`og`
|
||||
|OLM
|
||||
|Used to group multiple namespaces and prepare them for use by an Operator.
|
||||
|===
|
||||
|
||||
Each of these Operators are also responsible for creating resources:
|
||||
|
||||
.Resources created by OLM and Catalog Operators
|
||||
[options="header"]
|
||||
|===
|
||||
|Resource |Owner
|
||||
|
||||
|Deployments
|
||||
.4+.^|OLM
|
||||
|
||||
|ServiceAccounts
|
||||
|(Cluster)Roles
|
||||
|(Cluster)RoleBindings
|
||||
|
||||
|Custom Resource Definitions (CRDs)
|
||||
.2+.^|Catalog
|
||||
|ClusterServiceVersions (CSVs)
|
||||
|===
|
||||
|
||||
[id="olm-architecture-olm-operator_{context}"]
|
||||
== OLM Operator
|
||||
|
||||
The OLM Operator is responsible for deploying applications defined by CSV
|
||||
resources after the required resources specified in the CSV are present in the
|
||||
cluster.
|
||||
|
||||
The OLM Operator is not concerned with the creation of the required resources;
|
||||
users can choose to manually create these resources using the CLI, or users can
|
||||
choose to create these resources using the Catalog Operator. This separation of
|
||||
concern enables users incremental buy-in in terms of how much of the OLM
|
||||
framework they choose to leverage for their application.
|
||||
|
||||
While the OLM Operator is often configured to watch all namespaces, it can also
|
||||
be operated alongside other OLM Operators so long as they all manage separate
|
||||
namespaces.
|
||||
|
||||
.OLM Operator workflow
|
||||
* Watches for ClusterServiceVersion (CSVs) in a namespace and checks that
|
||||
requirements are met. If so, runs the install strategy for the CSV.
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
A CSV must be an active member of an OperatorGroup in order for the install
|
||||
strategy to be run.
|
||||
====
|
||||
|
||||
[id="olm-architecture-catalog-operator_{context}"]
|
||||
== Catalog Operator
|
||||
|
||||
The Catalog Operator is responsible for resolving and installing CSVs and the
|
||||
required resources they specify. It is also responsible for watching
|
||||
CatalogSources for updates to packages in channels and upgrading them
|
||||
(optionally automatically) to the latest available versions.
|
||||
|
||||
A user that wishes to track a package in a channel creates a Subscription
|
||||
resource configuring the desired package, channel, and the CatalogSource from
|
||||
which to pull updates. When updates are found, an appropriate InstallPlan is
|
||||
written into the namespace on behalf of the user.
|
||||
|
||||
Users can also create an InstallPlan resource directly, containing the names of
|
||||
the desired CSV and an approval strategy, and the Catalog Operator creates an
|
||||
execution plan for the creation of all of the required resources. After it is
|
||||
approved, the Catalog Operator creates all of the resources in an InstallPlan;
|
||||
this then independently satisfies the OLM Operator, which proceeds to install
|
||||
the CSVs.
|
||||
|
||||
.Catalog Operator workflow
|
||||
* Has a cache of CRDs and CSVs, indexed by name.
|
||||
* Watches for unresolved InstallPlans created by a user:
|
||||
** Finds the CSV matching the name requested and adds it as a resolved resource.
|
||||
** For each managed or required CRD, adds it as a resolved resource.
|
||||
** For each required CRD, finds the CSV that manages it.
|
||||
* Watches for resolved InstallPlans and creates all of the discovered resources for it (if approved by a user or automatically).
|
||||
* Watches for CatalogSources and Subscriptions and creates InstallPlans based on them.
|
||||
|
||||
[id="olm-architecture-catalog-registry_{context}"]
|
||||
== Catalog Registry
|
||||
|
||||
The Catalog Registry stores CSVs and CRDs for creation in a cluster and stores
|
||||
metadata about packages and channels.
|
||||
|
||||
A _package manifest_ is an entry in the Catalog Registry that associates a
|
||||
package identity with sets of CSVs. Within a package, channels point to a
|
||||
particular CSV. Because CSVs explicitly reference the CSV that they replace, a
|
||||
package manifest provides the Catalog Operator all of the information that is
|
||||
required to update a CSV to the latest version in a channel (stepping through
|
||||
each intermediate version).
|
||||
31
modules/olm-csv.adoc
Normal file
31
modules/olm-csv.adoc
Normal file
@@ -0,0 +1,31 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * applications/operators/olm-understanding-olm.adoc
|
||||
|
||||
[id="olm-csv_{context}"]
|
||||
= ClusterServiceVersions (CSVs)
|
||||
|
||||
A _ClusterServiceVersion_ (CSV) is a YAML manifest created from Operator
|
||||
metadata that assists the OLM in running the Operator in a cluster. It is the
|
||||
metadata that accompanies an Operator container image, used to populate user
|
||||
interfaces with information like its logo, description, and version. It is also
|
||||
a source of technical information needed to run the Operator, like the RBAC
|
||||
rules it requires and which Custom Resources (CRs) it manages or depends on.
|
||||
|
||||
A CSV is composed of:
|
||||
|
||||
Metadata::
|
||||
* Application metadata:
|
||||
** Name, description, version, links, labels, icon, etc.
|
||||
|
||||
Install strategy::
|
||||
* Type: Deployment
|
||||
** Set of service accounts and required permissions
|
||||
** Set of Deployments.
|
||||
|
||||
CRDs::
|
||||
* Type
|
||||
* Owned: Managed by this service
|
||||
* Required: Must exist in the cluster for this service to run
|
||||
* Resources: A list of resources that the Operator interacts with
|
||||
* Descriptors: Annotate CRD spec and status fields to provide semantic information
|
||||
27
modules/olm-metrics.adoc
Normal file
27
modules/olm-metrics.adoc
Normal file
@@ -0,0 +1,27 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * applications/operators/olm-understanding-olm.adoc
|
||||
|
||||
[id="olm-metrics_{context}"]
|
||||
= Metrics
|
||||
|
||||
The OLM exposes certain OLM-specific resources for use by the Prometheus-based
|
||||
{product-title} cluster monitoring stack.
|
||||
|
||||
.Metrics exposed by OLM
|
||||
[cols="2a,8a",options="header"]
|
||||
|===
|
||||
|Name |Description
|
||||
|
||||
|`csv_count`
|
||||
|Number of CSVs successfully registered.
|
||||
|
||||
|`install_plan_count`
|
||||
|Number of InstallPlans.
|
||||
|
||||
|`subscription_count`
|
||||
|Number of Subscriptions.
|
||||
|
||||
|`csv_upgrade_count`
|
||||
|Monotonic count of CatalogSources.
|
||||
|===
|
||||
@@ -1,188 +1,9 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * applications/operators/olm-adding-operators-to-cluster.adoc
|
||||
// * applications/operators/olm-understanding-olm.adoc
|
||||
|
||||
[id="olm-operator-lifecycle-manager_{context}"]
|
||||
= Understanding the Operator Lifecycle Manager
|
||||
|
||||
In {product-title} {product-version}, the _Operator Lifecycle Manager_ (OLM) helps users
|
||||
install, update, and manage the lifecycle of all Operators and their associated
|
||||
services running across their clusters. It is part of the
|
||||
link:https://github.com/operator-framework[Operator Framework],
|
||||
an open source toolkit designed to manage Kubernetes native applications
|
||||
(Operators) in an effective, automated, and scalable way.
|
||||
|
||||
.Operator Lifecycle Manager workflow
|
||||
image::olm-workflow.png[]
|
||||
|
||||
The OLM runs by default in {product-title} {product-version}, which aids cluster
|
||||
administrators in installing, upgrading, and granting access to Operators
|
||||
running on their cluster. The {product-title} web console provides management
|
||||
screens for cluster administrators to install Operators, as well as grant
|
||||
specific projects access to use the catalog of Operators available on the
|
||||
cluster.
|
||||
|
||||
For developers, a self-service experience allows provisioning and configuring
|
||||
instances of databases, monitoring, and big data services without having to be
|
||||
subject matter experts, because the Operator has that knowledge baked into it.
|
||||
|
||||
[id="olm-csv_{context}"]
|
||||
== ClusterServiceVersions (CSVs)
|
||||
|
||||
A _ClusterServiceVersion_ (CSV) is a YAML manifest created from Operator
|
||||
metadata that assists the OLM in running the Operator in a cluster. It is the
|
||||
metadata that accompanies an Operator container image, used to populate user
|
||||
interfaces with information like its logo, description, and version. It is also
|
||||
a source of technical information needed to run the Operator, like the RBAC
|
||||
rules it requires and which Custom Resources (CRs) it manages or depends on.
|
||||
|
||||
A CSV is composed of:
|
||||
|
||||
Metadata::
|
||||
* Application metadata:
|
||||
** Name, description, version, links, labels, icon, etc.
|
||||
|
||||
Install strategy::
|
||||
* Type: Deployment
|
||||
** Set of service accounts and required permissions
|
||||
** Set of Deployments.
|
||||
|
||||
CRDs::
|
||||
* Type
|
||||
* Owned: Managed by this service
|
||||
* Required: Must exist in the cluster for this service to run
|
||||
* Resources: A list of resources that the Operator interacts with
|
||||
* Descriptors: Annotate CRD spec and status fields to provide semantic information
|
||||
|
||||
[id="olm-architecture_{context}"]
|
||||
== Operator Lifecycle Manager Architecture
|
||||
|
||||
The Operator Lifecycle Manager is composed of two Operators: the OLM Operator
|
||||
and the Catalog Operator.
|
||||
|
||||
Each of these Operators are responsible for managing the CRDs that are the basis
|
||||
for the OLM framework:
|
||||
|
||||
.CRDs managed by OLM and Catalog Operators
|
||||
[cols="2a,1a,1a,8a",options="header"]
|
||||
|===
|
||||
|Resource |Short name |Owner |Description
|
||||
|
||||
|ClusterServiceVersion
|
||||
|`csv`
|
||||
|OLM
|
||||
|Application metadata: name, version, icon, required resources, installation,
|
||||
etc.
|
||||
|
||||
|InstallPlan
|
||||
|`ip`
|
||||
|Catalog
|
||||
|Calculated list of resources to be created in order to automatically install or
|
||||
upgrade a CSV.
|
||||
|
||||
|CatalogSource
|
||||
|`catsrc`
|
||||
|Catalog
|
||||
|A repository of CSVs, CRDs, and packages that define an application.
|
||||
|
||||
|Subscription
|
||||
|`sub`
|
||||
|Catalog
|
||||
|Used to keep CSVs up to date by tracking a channel in a package.
|
||||
|
||||
|OperatorGroup
|
||||
|`og`
|
||||
|OLM
|
||||
|Used to group multiple namespaces and prepare them for use by an Operator.
|
||||
|===
|
||||
|
||||
Each of these Operators are also responsible for creating resources:
|
||||
|
||||
.Resources created by OLM and Catalog Operators
|
||||
[options="header"]
|
||||
|===
|
||||
|Resource |Owner
|
||||
|
||||
|Deployments
|
||||
.4+.^|OLM
|
||||
|
||||
|ServiceAccounts
|
||||
|(Cluster)Roles
|
||||
|(Cluster)RoleBindings
|
||||
|
||||
|Custom Resource Definitions (CRDs)
|
||||
.2+.^|Catalog
|
||||
|ClusterServiceVersions (CSVs)
|
||||
|===
|
||||
|
||||
[id="olm-architecture-olm-operator_{context}"]
|
||||
== OLM Operator
|
||||
|
||||
The OLM Operator is responsible for deploying applications defined by CSV
|
||||
resources after the required resources specified in the CSV are present in the
|
||||
cluster.
|
||||
|
||||
The OLM Operator is not concerned with the creation of the required resources;
|
||||
users can choose to manually create these resources using the CLI, or users can
|
||||
choose to create these resources using the Catalog Operator. This separation of
|
||||
concern enables users incremental buy-in in terms of how much of the OLM
|
||||
framework they choose to leverage for their application.
|
||||
|
||||
While the OLM Operator is often configured to watch all namespaces, it can also
|
||||
be operated alongside other OLM Operators so long as they all manage separate
|
||||
namespaces.
|
||||
|
||||
.OLM Operator workflow
|
||||
* Watches for ClusterServiceVersion (CSVs) in a namespace and checks that
|
||||
requirements are met. If so, runs the install strategy for the CSV.
|
||||
+
|
||||
NOTE: A CSV must be an active member of an OperatorGroup in order for the
|
||||
install strategy to be run.
|
||||
|
||||
[id="olm-architecture-catalog-operator_{context}"]
|
||||
== Catalog Operator
|
||||
|
||||
The Catalog Operator is responsible for resolving and installing CSVs and the
|
||||
required resources they specify. It is also responsible for watching
|
||||
CatalogSources for updates to packages in channels and upgrading them
|
||||
(optionally automatically) to the latest available versions.
|
||||
|
||||
A user that wishes to track a package in a channel creates a Subscription
|
||||
resource configuring the desired package, channel, and the CatalogSource from
|
||||
which to pull updates. When updates are found, an appropriate InstallPlan is
|
||||
written into the namespace on behalf of the user.
|
||||
|
||||
Users can also create an InstallPlan resource directly, containing the names of
|
||||
the desired CSV and an approval strategy, and the Catalog Operator creates an
|
||||
execution plan for the creation of all of the required resources. After it is
|
||||
approved, the Catalog Operator creates all of the resources in an InstallPlan;
|
||||
this then independently satisfies the OLM Operator, which proceeds to install
|
||||
the CSVs.
|
||||
|
||||
.Catalog Operator workflow
|
||||
* Has a cache of CRDs and CSVs, indexed by name.
|
||||
* Watches for unresolved InstallPlans created by a user:
|
||||
** Finds the CSV matching the name requested and adds it as a resolved resource.
|
||||
** For each managed or required CRD, adds it as a resolved resource.
|
||||
** For each required CRD, finds the CSV that manages it.
|
||||
* Watches for resolved InstallPlans and creates all of the discovered resources for it (if approved by a user or automatically).
|
||||
* Watches for CatalogSources and Subscriptions and creates InstallPlans based on them.
|
||||
|
||||
[id="olm-architecture-catalog-registry_{context}"]
|
||||
== Catalog Registry
|
||||
|
||||
The Catalog Registry stores CSVs and CRDs for creation in a cluster and stores
|
||||
metadata about packages and channels.
|
||||
|
||||
A _package manifest_ is an entry in the Catalog Registry that associates a
|
||||
package identity with sets of CSVs. Within a package, channels point to a
|
||||
particular CSV. Because CSVs explicitly reference the CSV that they replace, a
|
||||
package manifest provides the Catalog Operator all of the information that is
|
||||
required to update a CSV to the latest version in a channel (stepping through
|
||||
each intermediate version).
|
||||
|
||||
[id="olm-architecture-operatorgroups_{context}"]
|
||||
== OperatorGroups
|
||||
[id="olm-operatorgroups_{context}"]
|
||||
= OperatorGroups
|
||||
|
||||
An _OperatorGroup_ is an OLM resource that provides multitenant configuration to
|
||||
OLM-installed Operators. An OperatorGroup selects a set of target namespaces in
|
||||
@@ -191,8 +12,8 @@ target namespaces is provided by a comma-delimited string stored in the CSV's
|
||||
`olm.targetNamespaces` annotation. This annotation is applied to member
|
||||
Operator's CSV instances and is projected into their deployments.
|
||||
|
||||
[discrete]
|
||||
=== OperatorGroup membership
|
||||
[id="olm-operatorgroups-membership_{context}"]
|
||||
== OperatorGroup membership
|
||||
|
||||
An Operator is considered a _member_ of an OperatorGroup if the following
|
||||
conditions are true:
|
||||
@@ -226,12 +47,15 @@ namespace.
|
||||
(target namespace set is the empty string `""`).
|
||||
|===
|
||||
|
||||
NOTE: If a CSV's spec omits an entry of `InstallModeType`, then that type is
|
||||
[NOTE]
|
||||
====
|
||||
If a CSV's spec omits an entry of `InstallModeType`, then that type is
|
||||
considered unsupported unless support can be inferred by an existing entry that
|
||||
implicitly supports it.
|
||||
====
|
||||
|
||||
[discrete]
|
||||
==== Troubleshooting OperatorGroup membership
|
||||
[id="olm-operatorgroups-membership-troubleshooting_{context}"]
|
||||
=== Troubleshooting OperatorGroup membership
|
||||
|
||||
* If more than one OperatorGroup exists in a single namespace, any CSV created
|
||||
in that namespace will transition to a failure state with the reason
|
||||
@@ -246,8 +70,8 @@ namespace selection changes to a supported configuration, or the CSV's
|
||||
InstallModes are modified to support the OperatorGroup's target namespace
|
||||
selection.
|
||||
|
||||
[discrete]
|
||||
=== Target namespace selection
|
||||
[id="olm-operatorgroups-target-namespace_{context}"]
|
||||
== Target namespace selection
|
||||
|
||||
Specify the set of namespaces for the OperatorGroup using a label
|
||||
selector with the `spec.selector` field:
|
||||
@@ -282,8 +106,11 @@ spec:
|
||||
- my-other-other-namespace
|
||||
----
|
||||
|
||||
NOTE: If both `spec.targetNamespaces` and `spec.selector` are defined,
|
||||
`spec.selector` is ignored.
|
||||
[NOTE]
|
||||
====
|
||||
If both `spec.targetNamespaces` and `spec.selector` are defined, `spec.selector`
|
||||
is ignored.
|
||||
====
|
||||
|
||||
Alternatively, you can omit both `spec.selector` and `spec.targetNamespaces` to
|
||||
specify a _global_ OperatorGroup, which selects all namespaces:
|
||||
@@ -302,8 +129,8 @@ The resolved set of selected namespaces is shown in an OperatorGroup's
|
||||
the empty string (`""`), which signals to a consuming Operator that it should
|
||||
watch all namespaces.
|
||||
|
||||
[discrete]
|
||||
=== OperatorGroup CSV annotations
|
||||
[id="olm-operatorgroups-csv-annotations_{context}"]
|
||||
== OperatorGroup CSV annotations
|
||||
|
||||
Member CSVs of an OperatorGroup have the following annotations:
|
||||
|
||||
@@ -322,12 +149,15 @@ Member CSVs of an OperatorGroup have the following annotations:
|
||||
namespace selection.
|
||||
|===
|
||||
|
||||
NOTE: All annotations except `olm.targetNamespaces` are included with copied
|
||||
CSVs. Omitting the `olm.targetNamespaces` annotation on copied CSVs prevents
|
||||
the duplication of target namespaces between tenants.
|
||||
[NOTE]
|
||||
====
|
||||
All annotations except `olm.targetNamespaces` are included with copied CSVs.
|
||||
Omitting the `olm.targetNamespaces` annotation on copied CSVs prevents the
|
||||
duplication of target namespaces between tenants.
|
||||
====
|
||||
|
||||
[discrete]
|
||||
=== Provided APIs annotation
|
||||
[id="olm-operatorgroups-provided-apis-annotation_{context}"]
|
||||
== Provided APIs annotation
|
||||
|
||||
Information about what `GroupVersionKinds` (GVKs) are provided by an
|
||||
OperatorGroup are shown in an `olm.providedAPIs` annotation. The annotation's
|
||||
@@ -361,8 +191,8 @@ status:
|
||||
- local
|
||||
----
|
||||
|
||||
[discrete]
|
||||
=== Role-based access control
|
||||
[id="olm-operatorgroups-rbac_{context}"]
|
||||
== Role-based access control
|
||||
|
||||
When an OperatorGroup is created, three ClusterRoles are generated. Each
|
||||
contains a single AggregationRule with a ClusterRoleSelector set to match a
|
||||
@@ -484,8 +314,6 @@ Aggregation labels:
|
||||
|
||||
|===
|
||||
|
||||
|
||||
|
||||
[id="olm-resources-additional-roles-rolebindings_{context}"]
|
||||
.Additional Roles and RoleBindings
|
||||
* If the CSV defines exactly one target namespace that contains `*`, then a
|
||||
@@ -498,8 +326,8 @@ then all Roles and RoleBindings in the Operator namespace with the
|
||||
`olm.owner: <csv_name>` and `olm.owner.namespace: <csv_namespace>` labels are
|
||||
copied into the target namespace.
|
||||
|
||||
[discrete]
|
||||
=== Copied CSVs
|
||||
[id="olm-operatorgroups-copied-csvs_{context}"]
|
||||
== Copied CSVs
|
||||
|
||||
OLM creates copies of all active member CSVs of an OperatorGroup in each of that
|
||||
OperatorGroup's target namespaces. The purpose of a copied CSV is to tell users
|
||||
@@ -512,8 +340,8 @@ tenants. Copied CSVs are deleted when their source CSV no longer exists or the
|
||||
OperatorGroup that their source CSV belongs to no longer targets the copied
|
||||
CSV's namespace.
|
||||
|
||||
[discrete]
|
||||
=== Static OperatorGroups
|
||||
[id="olm-operatorgroups-static_{context}"]
|
||||
== Static OperatorGroups
|
||||
|
||||
An OperatorGroup is _static_ if its `spec.staticProvidedAPIs` field is set to
|
||||
`true`. As a result, OLM does not modify the OperatorGroup's `olm.providedAPIs`
|
||||
@@ -542,8 +370,8 @@ spec:
|
||||
something.cool.io/cluster-monitoring: "true"
|
||||
----
|
||||
|
||||
[discrete]
|
||||
=== OperatorGroup intersection
|
||||
[id="olm-operatorgroups-intersection_{context}"]
|
||||
== OperatorGroup intersection
|
||||
|
||||
Two OperatorGroups are said to have _intersecting provided APIs_ if the
|
||||
intersection of their target namespace sets is not an empty set and the
|
||||
@@ -556,8 +384,8 @@ compete for the same resources in the set of intersecting namespaces.
|
||||
NOTE: When checking intersection rules, an OperatorGroup's namespace is always
|
||||
included as part of its selected target namespaces.
|
||||
|
||||
[discrete]
|
||||
==== Rules for intersection
|
||||
[id="olm-operatorgroups-intersection-rules_{context}"]
|
||||
=== Rules for intersection
|
||||
|
||||
Each time an active member CSV synchronizes, OLM queries the cluster for the set
|
||||
of intersecting provided APIs between the CSV's OperatorGroup and all others.
|
||||
@@ -588,7 +416,10 @@ OperatorGroup's:
|
||||
*** Replace the OperatorGroup's `olm.providedAPIs` annotation with the
|
||||
difference between itself and the CSV's provided APIs.
|
||||
|
||||
NOTE: Failure states caused by OperatorGroups are non-terminal.
|
||||
[NOTE]
|
||||
====
|
||||
Failure states caused by OperatorGroups are non-terminal.
|
||||
====
|
||||
|
||||
The following actions are performed each time an OperatorGroup synchronizes:
|
||||
|
||||
@@ -600,27 +431,3 @@ contains any extra APIs, then those APIs are pruned.
|
||||
notifies conflicting CSVs in intersecting groups that their conflict has
|
||||
possibly been resolved, either through resizing or through deletion of the
|
||||
conflicting CSV.
|
||||
|
||||
[id="olm-metrics_{context}"]
|
||||
== Metrics
|
||||
|
||||
The OLM exposes certain OLM-specific resources for use by the Prometheus-based
|
||||
{product-title} cluster monitoring stack.
|
||||
|
||||
.Metrics exposed by OLM
|
||||
[cols="2a,8a",options="header"]
|
||||
|===
|
||||
|Name |Description
|
||||
|
||||
|`csv_count`
|
||||
|Number of CSVs successfully registered.
|
||||
|
||||
|`install_plan_count`
|
||||
|Number of InstallPlans.
|
||||
|
||||
|`subscription_count`
|
||||
|Number of Subscriptions.
|
||||
|
||||
|`csv_upgrade_count`
|
||||
|Monotonic count of CatalogSources.
|
||||
|===
|
||||
@@ -1,47 +1,9 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * applications/operators/olm-adding-operators-to-cluster.adoc
|
||||
|
||||
[id="olm-operatorhub_{context}"]
|
||||
= Understanding the OperatorHub
|
||||
|
||||
The _OperatorHub_ is available via the {product-title} web console and is the
|
||||
interface that cluster administrators use to discover and install Operators.
|
||||
With one click, an Operator can be pulled from their off-cluster source,
|
||||
installed and subscribed on the cluster, and made ready for engineering teams to
|
||||
self-service manage the product across deployment environments using the
|
||||
Operator Lifecycle Manager (OLM).
|
||||
|
||||
Cluster administrators can choose from OperatorSources grouped into
|
||||
the following categories:
|
||||
|
||||
[cols="2a,8a",options="header"]
|
||||
|===
|
||||
|Category |Description
|
||||
|
||||
|Red Hat Operators
|
||||
|Red Hat products packaged and shipped by Red Hat. Supported by Red Hat.
|
||||
|
||||
|Certified Operators
|
||||
|Products from leading independent software vendors (ISVs). Red Hat partners with
|
||||
ISVs to package and ship. Supported by the ISV.
|
||||
|
||||
|Community Operators
|
||||
|Optionally-visible software maintained by relevant representatives in the
|
||||
link:https://github.com/operator-framework/community-operators[operator-framework/community-operators]
|
||||
GitHub repository. No official support.
|
||||
|
||||
|Custom Operators
|
||||
|Operators you add to the cluster yourself.
|
||||
If you have not added any Custom Operators, the Custom category does not appear in
|
||||
the Web console on your OperatorHub.
|
||||
|===
|
||||
|
||||
The OperatorHub component is installed and run as an Operator by default on
|
||||
{product-title} in the `openshift-marketplace` namespace.
|
||||
// * applications/operators/olm-understanding-operatorhub.adoc
|
||||
|
||||
[id="olm-operatorhub-arch_{context}"]
|
||||
== OperatorHub Architecture
|
||||
= OperatorHub architecture
|
||||
|
||||
The OperatorHub component's Operator manages two Custom Resource Definitions
|
||||
(CRDs): an
|
||||
41
modules/olm-operatorhub-overview.adoc
Normal file
41
modules/olm-operatorhub-overview.adoc
Normal file
@@ -0,0 +1,41 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * applications/operators/olm-understanding-operatorhub.adoc
|
||||
|
||||
[id="olm-operatorhub-overview_{context}"]
|
||||
= Overview of the OperatorHub
|
||||
|
||||
The _OperatorHub_ is available via the {product-title} web console and is the
|
||||
interface that cluster administrators use to discover and install Operators.
|
||||
With one click, an Operator can be pulled from their off-cluster source,
|
||||
installed and subscribed on the cluster, and made ready for engineering teams to
|
||||
self-service manage the product across deployment environments using the
|
||||
Operator Lifecycle Manager (OLM).
|
||||
|
||||
Cluster administrators can choose from OperatorSources grouped into
|
||||
the following categories:
|
||||
|
||||
[cols="2a,8a",options="header"]
|
||||
|===
|
||||
|Category |Description
|
||||
|
||||
|Red Hat Operators
|
||||
|Red Hat products packaged and shipped by Red Hat. Supported by Red Hat.
|
||||
|
||||
|Certified Operators
|
||||
|Products from leading independent software vendors (ISVs). Red Hat partners with
|
||||
ISVs to package and ship. Supported by the ISV.
|
||||
|
||||
|Community Operators
|
||||
|Optionally-visible software maintained by relevant representatives in the
|
||||
link:https://github.com/operator-framework/community-operators[operator-framework/community-operators]
|
||||
GitHub repository. No official support.
|
||||
|
||||
|Custom Operators
|
||||
|Operators you add to the cluster yourself.
|
||||
If you have not added any Custom Operators, the Custom category does not appear in
|
||||
the Web console on your OperatorHub.
|
||||
|===
|
||||
|
||||
The OperatorHub component is installed and run as an Operator by default on
|
||||
{product-title} in the `openshift-marketplace` namespace.
|
||||
27
modules/olm-overview.adoc
Normal file
27
modules/olm-overview.adoc
Normal file
@@ -0,0 +1,27 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * applications/operators/olm-understanding-olm.adoc
|
||||
|
||||
[id="olm-overview_{context}"]
|
||||
= Overview of the Operator Lifecycle Manager
|
||||
|
||||
In {product-title} {product-version}, the _Operator Lifecycle Manager_ (OLM) helps users
|
||||
install, update, and manage the lifecycle of all Operators and their associated
|
||||
services running across their clusters. It is part of the
|
||||
link:https://github.com/operator-framework[Operator Framework],
|
||||
an open source toolkit designed to manage Kubernetes native applications
|
||||
(Operators) in an effective, automated, and scalable way.
|
||||
|
||||
.Operator Lifecycle Manager workflow
|
||||
image::olm-workflow.png[]
|
||||
|
||||
The OLM runs by default in {product-title} {product-version}, which aids cluster
|
||||
administrators in installing, upgrading, and granting access to Operators
|
||||
running on their cluster. The {product-title} web console provides management
|
||||
screens for cluster administrators to install Operators, as well as grant
|
||||
specific projects access to use the catalog of Operators available on the
|
||||
cluster.
|
||||
|
||||
For developers, a self-service experience allows provisioning and configuring
|
||||
instances of databases, monitoring, and big data services without having to be
|
||||
subject matter experts, because the Operator has that knowledge baked into it.
|
||||
@@ -167,8 +167,7 @@ access to Operators running on their cluster:
|
||||
* Supports role-based access control (RBAC) for certain teams to use certain Operators
|
||||
|
||||
See
|
||||
xref:../applications/operators/olm-adding-operators-to-cluster.adoc#olm-adding-operators-to-a-cluster[Adding
|
||||
Operators to a cluster] for more information.
|
||||
xref:../applications/operators/olm-understanding-olm.adoc#olm-understanding-olm[Understanding the Operator Lifecycle Manager (OLM)] for more information.
|
||||
|
||||
[id="ocp-4-1-installation-and-upgrade"]
|
||||
=== Installation and upgrade
|
||||
@@ -203,7 +202,7 @@ from Red Hat products, Red Hat partners, and the community.
|
||||
|
||||
.Features provided with base installation and OperatorHub
|
||||
[cols="3",options="header"]
|
||||
|====
|
||||
|===
|
||||
|Feature |New installer |OperatorHub
|
||||
|
||||
|Console and authentication
|
||||
@@ -242,7 +241,10 @@ from Red Hat products, Red Hat partners, and the community.
|
||||
| -
|
||||
|* [x]
|
||||
|
||||
|====
|
||||
|===
|
||||
|
||||
See
|
||||
xref:../applications/operators/olm-understanding-operatorhub.adoc#olm-understanding-operatorhub[Understanding the OperatorHub] for more information.
|
||||
|
||||
[id="ocp-4-1-storage"]
|
||||
=== Storage
|
||||
|
||||
Reference in New Issue
Block a user