mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
21 lines
1.6 KiB
Plaintext
21 lines
1.6 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * operators/understanding/olm/olm-understanding-operatorgroups.adoc
|
|
|
|
:_mod-docs-content-type: CONCEPT
|
|
[id="olm-operatorgroups-limitations"]
|
|
= Limitations for multitenant Operator management
|
|
|
|
{product-title} provides limited support for simultaneously installing different versions of an Operator on the same cluster. Operator Lifecycle Manager (OLM) installs Operators multiple times in different namespaces. One constraint of this is that the Operator's API versions must be the same.
|
|
|
|
Operators are control plane extensions due to their usage of `CustomResourceDefinition` objects (CRDs), which are global resources in Kubernetes. Different major versions of an Operator often have incompatible CRDs. This makes them incompatible to install simultaneously in different namespaces on a cluster.
|
|
|
|
All tenants, or namespaces, share the same control plane of a cluster. Therefore, tenants in a multitenant cluster also share global CRDs, which limits the scenarios in which different instances of the same Operator can be used in parallel on the same cluster.
|
|
|
|
The supported scenarios include the following:
|
|
|
|
* Operators of different versions that ship the exact same CRD definition (in case of versioned CRDs, the exact same set of versions)
|
|
* Operators of different versions that do not ship a CRD, and instead have their CRD available in a separate bundle in the software catalog
|
|
|
|
All other scenarios are not supported, because the integrity of the cluster data cannot be guaranteed if there are multiple competing or overlapping CRDs from different Operator versions to be reconciled on the same cluster.
|