Deploying Kubernetes Operators using Operator Life Cycle Manager
Tags: kubernetes, redhat, olm, operator
Published: 2021-03-20 09:11:43

# TL;DR

Welcome to the world of Kubernetes Operators!!

With the introduction of Custom Resource Definitions (CRDs) in version 1.7 Kubernetes is more extensible and developers are bringing more light toward the Operator world.Nowadays most of the applications are deployed as operators and they will have deep knowledge of how the system ought to behave, how to deploy it, and how to react if there are problems.

So in order to make the development and maintenance of operator easier **RedHat** introduced an Operator framework, it has SDK, olm(operator lifecycle manager), and operator registry.

In this article, let's explore how we can deploy an operator to the Kubernetes cluster with the help of the Operator lifecycle manager.

# Creating Kubernetes Cluster using [KIND](https://kind.sigs.k8s.io/)


> *"kind is a tool for running local Kubernetes clusters using Docker container nodes"*

KIND is spawned from a Kubernetes Special Interest Group and I can say confidently, it’s going to be a very useful tool.

OK, for now just download the binaries of KIND and then run the below command in your machine. This will bring up a new Kubernetes cluster with name testcluster.

Since this article is not about KIND I am not going to explain all pre-requisites to be installed to run KIND, you can refer to the KIND documentation.

```
Kind create cluster –name testcluster –config=kindconfig.yaml
```

Here I used a [kindconfig.yaml](https://github.com/sunishsurendrank/K8_infra/blob/main/kind/kindconfig.yaml) because I wanted to map few extra ports to my base machine.(Optional)


![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/s8s2rbfco9ss335wy9dl.png)
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/feilv6hd7emziluznn02.png)

Within minutes Kubernetes cluster is created and it is up and running.
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/t32s6jj5n2vjnjgnrgd2.png)

# Deploying OLM into the newly created Cluster

I have already mentioned about Operator framework by RedHat, now let's see it in detail.

> *"The Operator Framework is an open-source toolkit to manage Kubernetes native applications, called Operators, in an effective, automated, and scalable way."*

Operator Framework consists of three major tools 
- **Operator-sdk** – For the development of the operators.
- **Operator-Lifecycle-Manger(OLM)** – For managing the lifecycle of the operator.
- **Operator-registry** – For storing the operator metadata. 

OLM won’t get deployed by default as part of the Kubernetes installation, we should install it separately.
 
As of now, the latest version released is 0.17.0, by running the below command in the machine which is pointing to the newly created KIND cluster, OLM will get deployed to the cluster.
```
curl -sL https://github.com/operator-framework/operator-lifecycle-manager/releases/download/v0.17.0/install.sh | bash -s v0.17.0
```

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/tv2ik58hk4svq4vqb1l4.png)

If we do "kubectl get namespace" we can see new two namespaces introduced in the cluster - olm and operators.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vzctffi9chj91kabg9uv.png)
By listing the pods in the olm namespace we can see two major pods running in the namespace **olm operator** and **catalog operator**. 

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/17g6xpxg44bkbs60mnfz.png)

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/thx36daz9x29v8piqdq1.png)

I know it is getting a little messy now. To install Operator we are installing olm and olm major components are Operators. Crazy right!

So this means to install an operator olm is not mandatory, but for managing the lifecycle of operator OLM can help. OLM has components that will help to upgrade the operator automatically when a new version is available. So no human interruption needed.

#### OLM Operator

The OLM Operator is responsible for deploying applications defined by CSV(Cluster Service Version).

#### Catalog Operator

The Catalog Operator is responsible for watching CatalogSources for updates of packages in channels and upgrading them to the latest available versions.

So now the question is what this CSV and CatalogSource.As I mentioned above olm components are operators so it will have custom resource definitions exposed. So CSV, CatalogSources are part of CRD's exposed by OLM operators.

The below diagram shows the list of  CRD’s owned by the olm operator and catalog operator.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/489d6lo2n5wqqoxgoe6a.png)
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mey3rw74afmsoomu4o98.png)

# Deploying Operators using OLM

OK! Now we are ready with the cluster which has olm deployed, so the next thing is we need an operator to deploy in our cluster.So let's visit [**OpertorHub**](https://operatorhub.io/).

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2ehwi6demqeidsyex0f4.jpg)

> *"OperatorHub.io is a new home for the Kubernetes community to share Operators. Find an existing Operator or list your own today. "*

In a simple way, I can say Operator hub is like docker hub and it has operator catalogs in it.


For this article, I am going to download and install the ArgoCD operator from the OpertorHub.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zygi3vgmycntdtwwql6a.png)

Click on the install button and it will show the kubectl command which will install the operator in Kubernetes cluster.

```
kubectl create -f https://operatorhub.io/install/argocd-operator-helm.yaml
```

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/earlx11atuelwfmlg9ak.png)


After running the kubectl command, a new namespace created **my-argocd-operator-helm** and in the namespace, there is an ArgoCD operator pod running.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qrjke3rywafsnpil9h2v.png)

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/naaovt8rs3iogunncln2.png)

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4lra14jdk3kp60tch2j2.JPG)

### What happened in Backend, how the ArgoCD Operator got deployed?


Let’s open and see the yaml file we applied to the cluster.
https://operatorhub.io/install/argocd-operator-helm.yaml

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xvt759uggag5lxo5kll4.png)

1.	First it will create a namespace called **my-argocd-operator-helm**
2.	Then it will create a OperatorGroup in the namespace **my-argocd-operator-helm**, The OperatorGroup kind is a CRD exposed by the olm 
3.	It will also create a **Subscription** (CRD exposed by the olm). In Subscription there is a filed to mention the channel. The channel (such as alpha, beta, or stable) helps determine which stream of the operator should be deployed from the CatalogSource.
4.	**Subscription** also defines from where the catalogs need be downloaded, in our case it is mentioned as operatorhub

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/nyt7mcqmz0koc9uhog8o.png)


5.	When a **Subscription** is created **Catalog Operator** will create an **Install Plan**. By default, OLM will automatically approve updates to an operator as new versions become available via a CatalogSource. 
6.	So as mentioned in the subscription catalog operator contact the OperatorHub for the  operator argocd 
7.	From OperatorHub the latest version from the channel mentioned in the subscription yaml is downloaded and it will have Cluster Service Version.
8.	The **olm Operator** will install the operator by reading the Cluster Service Version.

This is how the operator got deployed in the namespace my-argocd-operator-helm