|
7 | 7 |
|
8 | 8 | ## Overview
|
9 | 9 |
|
10 |
| -This project is a component of the [Operator Framework](https://github.com/operator-framework), an open source toolkit to manage Kubernetes native applications, called Operators, in an effective, automated, and scalable way. Read more in the [introduction blog post](https://coreos.com/blog/introducing-operator-framework). |
| 10 | +This project is a component of the [Operator Framework](https://github.com/operator-framework), an open source toolkit to manage Kubernetes native applications, called Operators, in an effective, automated, and scalable way. Read more in the [introduction blog post](https://operatorhub.io/what-is-an-operator). |
11 | 11 |
|
12 |
| -OLM extends Kubernetes to provide a declarative way to install, manage, and upgrade operators and their dependencies in a cluster. |
| 12 | +OLM extends Kubernetes to provide a declarative way to install, manage, and upgrade Operators and their dependencies in a cluster. It provides the following features: |
13 | 13 |
|
14 |
| -It also enforces some constraints on the components it manages in order to ensure a good user experience. |
| 14 | +### Over-the-Air Updates and Catalogs |
| 15 | +Kubernetes clusters are being kept up to date using elaborate update mechanisms today, more often automatically and in the background. Operators, being cluster extensions, should follow that. OLM has a concept of catalogs from which Operators are available to install and being kept up to date. In this model OLM allows maintainers granular authoring of the update path and gives commercial vendors a flexible publishing mechanism using channels. |
15 | 16 |
|
16 |
| -This project enables users to do the following: |
| 17 | +### Dependency Model |
| 18 | +With OLMs packaging format Operators can express dependencies on the platform and on other Operators. They can rely on OLM to respect these requirements as long as the cluster is up. In this way, OLMs dependency model ensures Operators stay working during their long lifecycle across multiple updates of the platform or other Operators. |
17 | 19 |
|
18 |
| -* Define applications as a single Kubernetes resource that encapsulates requirements and metadata |
19 |
| -* Install applications automatically with dependency resolution or manually with nothing but `kubectl` |
20 |
| -* Upgrade applications automatically with different approval policies |
| 20 | +### Discoverability |
| 21 | +OLM advertises installed Operators and their services into the namespaces of tenants. They can discover which managed services are available and which Operator provides them. Administrators can rely on catalog content projected into a cluster, enabling discovery of Operators available to install. |
21 | 22 |
|
22 |
| -This project does not: |
| 23 | +### Cluster Stability |
| 24 | +Operators must claim ownership of their APIs. OLM will prevent conflicting Operators owning the same APIs being installed, ensuring cluster stability. |
| 25 | + |
| 26 | +### Declarative UI controls |
| 27 | +Operators can behave like managed service providers. Their user interface on the command line are APIs. For graphical consoles OLM annotates those APIs with descriptors that drive the creation of rich interfaces and forms for users to interact with the Operator in a natural, cloud-like way. |
23 | 28 |
|
24 |
| -* Replace [Helm](https://github.com/kubernetes/helm) |
25 |
| -* Turn Kubernetes into a [PaaS](https://en.wikipedia.org/wiki/Platform_as_a_service) |
26 | 29 |
|
27 | 30 | ## Prerequisites
|
28 | 31 |
|
|
0 commit comments