mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
49 lines
3.2 KiB
Plaintext
49 lines
3.2 KiB
Plaintext
:_mod-docs-content-type: ASSEMBLY
|
|
[id="extensions-overview"]
|
|
= Extensions overview
|
|
include::_attributes/common-attributes.adoc[]
|
|
:context: olmv1-about
|
|
|
|
toc::[]
|
|
|
|
:FeatureName: {olmv1-first}
|
|
include::snippets/technology-preview.adoc[]
|
|
|
|
Extensions enable cluster administrators to extend capabilities for users on their {product-title} cluster.
|
|
|
|
{olm-first} has been included with {product-title} 4 since its initial release. {product-title} 4.17 includes components for a next-generation iteration of {olm} as a Generally Available (GA) feature, known during this phase as _{olmv1}_. This updated framework evolves many of the concepts that have been part of previous versions of {olm} and adds new capabilities.
|
|
|
|
[id="olmv1-highlights_{context}"]
|
|
== Highlights
|
|
|
|
Administrators can explore the following highlights:
|
|
|
|
Fully declarative model that supports GitOps workflows::
|
|
{olmv1} simplifies extension management through two key APIs:
|
|
+
|
|
--
|
|
* A new `ClusterExtension` API streamlines management of installed extensions, which includes Operators via the `registry+v1` bundle format, by consolidating user-facing APIs into a single object. This API is provided as `clusterextension.olm.operatorframework.io` by the new Operator Controller component. Administrators and SREs can use the API to automate processes and define desired states by using GitOps principles.
|
|
+
|
|
[NOTE]
|
|
====
|
|
Earlier Technology Preview phases of {olmv1} introduced a new `Operator` API; this API is renamed `ClusterExtension` in {product-title} 4.16 to address the following improvements:
|
|
|
|
* More accurately reflects the simplified functionality of extending a cluster's capabilities
|
|
* Better represents a more flexible packaging format
|
|
* `Cluster` prefix clearly indicates that `ClusterExtension` objects are cluster-scoped, a change from {olmv0} where Operators could be either namespace-scoped or cluster-scoped
|
|
====
|
|
* The `Catalog` API, provided by the new catalogd component, serves as the foundation for {olmv1}, unpacking catalogs for on-cluster clients so that users can discover installable content, such as Kubernetes extensions and Operators. This provides increased visibility into all available Operator bundle versions, including their details, channels, and update edges.
|
|
--
|
|
+
|
|
For more information, see xref:../extensions/arch/operator-controller.adoc#operator-controller[Operator Controller] and xref:../extensions/arch/catalogd.adoc#catalogd[Catalogd].
|
|
|
|
Improved control over extension updates::
|
|
With improved insight into catalog content, administrators can specify target versions for installation and updates. This grants administrators more control over the target version of extension updates. For more information, see xref:../extensions/ce/managing-ce.adoc#olmv1-updating-an-operator_managing-ce[Updating an cluster extension].
|
|
|
|
Flexible extension packaging format::
|
|
Administrators can use file-based catalogs to install and manage extensions, such as {olm}-based Operators, similar to the {olmv0} experience.
|
|
+
|
|
In addition, bundle size is no longer constrained by the etcd value size limit. For more information, see xref:../extensions/ce/managing-ce.adoc#managing-ce[Installing extensions].
|
|
|
|
include::modules/olmv1-about-purpose.adoc[leveloffset=+1]
|