|
2 | 2 | The operator-controller is the central component of Operator Lifecycle Manager (OLM) v1. |
3 | 3 | It extends Kubernetes with an API through which users can install extensions. |
4 | 4 |
|
5 | | -## Mission |
| 5 | +## Overview |
| 6 | + |
| 7 | +OLM v1 is the follow-up to [OLM v0](https://github.com/operator-framework/operator-lifecycle-manager). Its purpose is to provide APIs, |
| 8 | +controllers, and tooling that support the packaging, distribution, and lifecycling of Kubernetes extensions. It aims to: |
6 | 9 |
|
7 | | -OLM’s purpose is to provide APIs, controllers, and tooling that support the packaging, distribution, and lifecycling of Kubernetes extensions. It aims to: |
8 | 10 | - align with Kubernetes designs and user assumptions |
9 | 11 | - provide secure, high-quality, and predictable user experiences centered around declarative GitOps concepts |
10 | 12 | - give cluster admins the minimal necessary controls to build their desired cluster architectures and to have ultimate control |
11 | 13 |
|
12 | | -## Overview |
13 | | - |
14 | | -OLM v1 is the follow-up to OLM v0, located [here](https://github.com/operator-framework/operator-lifecycle-manager). |
15 | | - |
16 | 14 | OLM v1 consists of two different components: |
| 15 | + |
17 | 16 | * operator-controller (this repository) |
18 | 17 | * [catalogd](https://github.com/operator-framework/catalogd) |
19 | 18 |
|
20 | | -For a more complete overview of OLM v1 and how it differs from OLM v0, see our [overview](docs/olmv1_overview.md). |
21 | | - |
22 | | -### Installation |
23 | | - |
24 | | -The following script will install OLMv1 on a Kubernetes cluster. If you don't have one, you can deploy a Kubernetes cluster with [KIND](https://sigs.k8s.io/kind). |
25 | | - |
26 | | -> [!CAUTION] |
27 | | -> Operator-Controller depends on [cert-manager](https://cert-manager.io/). Running the following command |
28 | | -> may affect an existing installation of cert-manager and cause cluster instability. |
29 | | -
|
30 | | -The latest version of Operator Controller can be installed with the following command: |
31 | | - |
32 | | -```bash |
33 | | -curl -L -s https://github.com/operator-framework/operator-controller/releases/latest/download/install.sh | bash -s |
34 | | -``` |
35 | | - |
36 | | -## Getting Started with OLM v1 |
37 | | - |
38 | | -This quickstart procedure will guide you through the following processes: |
39 | | -* Deploying a catalog |
40 | | -* Installing, upgrading, or downgrading an extension |
41 | | -* Deleting catalogs and extensions |
42 | | - |
43 | | -### Create a Catalog |
44 | | - |
45 | | -OLM v1 is designed to source content from an on-cluster catalog in the file-based catalog ([FBC](https://olm.operatorframework.io/docs/reference/file-based-catalogs/#docs)) format. |
46 | | -These catalogs are deployed and configured through the `ClusterCatalog` resource. More information on adding catalogs |
47 | | -can be found [here](./docs/Tasks/adding-a-catalog). |
48 | | - |
49 | | -The following example uses the official [OperatorHub](https://operatorhub.io) catalog that contains many different |
50 | | -extensions to choose from. Note that this catalog contains packages designed to work with OLM v0, and that not all packages |
51 | | -will work with OLM v1. More information on catalog exploration and content compatibility can be found [here](./docs/refs/catalog-queries.md). |
52 | | - |
53 | | -To create the catalog, run the following command: |
54 | | - |
55 | | -```bash |
56 | | -# Create ClusterCatalog |
57 | | -kubectl apply -f - <<EOF |
58 | | -apiVersion: catalogd.operatorframework.io/v1alpha1 |
59 | | -kind: ClusterCatalog |
60 | | -metadata: |
61 | | - name: operatorhubio |
62 | | -spec: |
63 | | - source: |
64 | | - type: image |
65 | | - image: |
66 | | - ref: quay.io/operatorhubio/catalog:latest |
67 | | - pollInterval: 10m |
68 | | -EOF |
69 | | -``` |
70 | | - |
71 | | -Once the catalog is unpacked successfully, its content will be available for installation. |
72 | | - |
73 | | -```bash |
74 | | -# Wait for the ClusterCatalog to be unpacked |
75 | | -kubectl wait --for=condition=Unpacked=True clustercatalog/operatorhubio --timeout=60s |
76 | | -``` |
77 | | - |
78 | | -### Install a Cluster Extension |
79 | | - |
80 | | -For simplicity, the following example manifest includes all necessary resources to install the ArgoCD operator. |
81 | | -The manifest includes installation namespace, installer service account and associated minimal set of RBAC permissions |
82 | | -needed for installation, and the ClusterExtension resource, which specifies the name and version of the extension to install. |
83 | | -More information on installing extensions can be found [here](docs/Tasks/installing-an-extension). |
84 | | - |
85 | | -```bash |
86 | | -# Apply the sample ClusterExtension. Manifest already includes |
87 | | -# namespace and adequately privileged service account |
88 | | -kubectl apply -f https://raw.githubusercontent.com/operator-framework/operator-controller/main/config/samples/olm_v1alpha1_clusterextension.yaml |
89 | | -``` |
90 | | - |
91 | | -### Upgrade the Cluster Extension |
92 | | - |
93 | | -To upgrade the installed extension, update the version field in the ClusterExtension resource. Note that |
94 | | -there must be CRD compatibility between the versions being upgraded, and the target version must be |
95 | | -compatible with OLM v1. More information on CRD upgrade safety can be found [here](./docs/refs/crd-upgrade-safety.md), |
96 | | -compatible with OLM v1. More information on CRD upgrade safety can be found [here](./docs/refs/crd-upgrade-safety.md), |
97 | | -and on the extension upgrade process [here](./docs/drafts/Tasks/upgrading-an-extension). |
98 | | - |
99 | | -```bash |
100 | | -# Update to v0.11.0 |
101 | | -kubectl patch clusterextension argocd --type='merge' -p '{"spec": {"source": {"catalog": {"version": "0.11.0"}}}}' |
102 | | - |
103 | | -``` |
104 | | - |
105 | | -For information on the downgrade process, see [here](docs/drafts/downgrading-an-extension.md). |
106 | | - |
107 | | -### Uninstall the Cluster Extension |
108 | | - |
109 | | -To uninstall an extension, delete the ClusterExtension resource. This will trigger the uninstallation process, which will |
110 | | -remove all resources created by the extension. More information on uninstalling extensions can be found [here](./docs/Tasks/uninstalling-an-extension). |
111 | | - |
112 | | -```bash |
113 | | -# Delete cluster extension and residing namespace |
114 | | -kubectl delete clusterextension/argocd |
115 | | -``` |
116 | | - |
117 | | -#### Cleanup |
118 | | - |
119 | | -Extension installation requires the creation of a namespace, an installer service account, and its RBAC. Once the |
120 | | -extension is uninstalled, these resources can be cleaned up. |
121 | | - |
122 | | -```bash |
123 | | -# Delete namespace, and by extension, the installer service account, Role, and RoleBinding |
124 | | -kubectl delete namespace argocd |
125 | | -``` |
| 19 | +For a more complete overview of OLM v1 and how it differs from OLM v0, see our [overview](docs/project/olmv1_design_decisions.md). |
126 | 20 |
|
127 | | -```bash |
128 | | -# Delete installer service account cluster roles |
129 | | -kubectl delete clusterrole argocd-installer-clusterrole && kubectl delete clusterrole argocd-rbac-clusterrole |
130 | | -``` |
| 21 | +## Getting Started |
131 | 22 |
|
132 | | -```bash |
133 | | -# Delete installer service account cluster role bindings |
134 | | -kuebctl delete clusterrolebinding argocd-installer-binding && kubectl delete clusterrolebinding argocd-rbac-binding |
135 | | -``` |
| 23 | +To get started with OLM v1, please see our [Getting Started](docs/getting-started/olmv1_getting_started.md) documentation. |
136 | 24 |
|
137 | 25 | ## License |
138 | 26 |
|
|
0 commit comments