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

"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 because I wanted to map few extra ports to my base machine.(Optional)

Within minutes Kubernetes cluster is created and it is up and running.

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

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

By listing the pods in the olm namespace we can see two major pods running in the namespace olm operator and catalog operator.

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.

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.

"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.

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

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

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

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

1. 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.
2. So as mentioned in the subscription catalog operator contact the OperatorHub for the operator argocd
3. From OperatorHub the latest version from the channel mentioned in the subscription yaml is downloaded and it will have Cluster Service Version.
4. 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