A Definitive guide to Kubernetes Operator — The crawl! Episode 2

Screenshot (60).png

In the last episode, we learnt around the concepts of Kubernetes operators — what it is? Why does one need it? How it works?

In case you missed reading that, I would highly recommend to first go & read before proceeding any further from here. Rest of this blog needs that as a mandatory prerequisite!

Like I promised in the last episode, no more stories today, instead we will learn today how to crawl? Huh?!!? Well, I meant to equip you with the needed stuffs to help you start crawling towards the path of understanding the Kubernetes operators.

Like I promised in the last episode, no more stories today, instead we will learn today how to crawl? Huh?!!? Well, I meant to equip you with the needed stuffs to help you start crawling towards the path of understanding the Kubernetes operators.

One always learn to speak first before writing — Human minds are designed that way! You observe around your world, see & hear stuffs. All these experiences enriches you enough in preparing you for the next big thing.

I firmly believe on the above and it works wonder for me. I will follow the same paradigm & take you through one very interesting Kubernetes operator project , show you what it does, how it does & many more. As you start experiencing this, your mind automatically will equip you with all the needed arsenals for your next big thing (probably for writing your very own operator!).

So, let’s get started!

Global warming!

Huh?!!? But we were talking about Kubernetes operators! Ain’t we?

Well, yes & just stay with me. This is something I truly started caring about & looking forward all of your support! And yes, we are very much still in the topic of Kubernetes Operators!

The digital transition as it is currently implemented participates to global warming more than it helps preventing it. I have done a video which is available in my YouTube channel as well as written an article in medium where I have covered around this topic specifically.

If this interests you, do check out these links in YouTube & Medium.

As part of my this research, I came across a very interesting project which is working towards lessening the CO2 footprint of Kubernetes clusters & thus potentially helping towards the noble cause of reducing the global warming.

With bells & whistles, ladies and gentlemen, let me introduce this awesome project to you — Kube-green!

Following is an extract from the documentation of Kube-green to give you a fair idea around how they are contributing towards lessening the CO2 footprint -

How many of your dev/preview pods stay on during weekends? Or at night? It’s a waste of resources! And money! But fear not, kube-green is here to the rescue.


kube-green is a simple k8s addon that automatically shuts down (some of) your resources when you don’t need them.


How many CO2 produces yearly a pod? By our assumption, it’s about 11 Kg CO2eq per per year per pod

They have a whole tool dedicated around to help you quantify & calculate the actual CO2 emission with & without Kube-green. Starting from July 21st, this project is listed in the Scheduling & Orchestration subcategory, which is part of the Orchestration & Management category of the official CNCF landscape.

Cool, isn’t it?

Relevance of Kube-green in our context

Well, Kube-green is available & published as an operator in operatorhub. We will use this as an example for our hands-on.

Its a small little gesture from my side for such a great & noble initiative! 🙏

Understanding basic Kube-green constructs

In the first episode, we briefly learnt around what is CRD & CR. But as a quick recap, these are the constructs for extending the existing capabilities of Kubernetes.

Kube-green operator introduces a Custom Resource Definition (CRD) called “sleepinfos.kube-green.com” and a new Custom Resource Kind called as “SleepInfo”. You can find this CRD definition from their GitHub page link.

To understand what new capabilities or extensions Kube-green’s CRD is bringing to existing Kubernetes, lets see a sample CR of this type -

                apiVersion: v1
items:
- apiVersion: kube-green.com/v1alpha1
  kind: SleepInfo
  metadata:
    name: sleep-test
    namespace: sleepme
  spec:
    excludeRef:
    - apiVersion: apps/v1
      kind: Deployment
      name: do-not-sleep
    sleepAt: '*:*/5'
    wakeUpAt: '*:*/7'
    weekdays: '*'
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""
            

In the above example, there are few attributes to understand -

  • excludeRef section — Refers to a Kubernetes Deployment type with name “do-not-sleep”. The excludeRef section of the SleepInfo Kind, is the place where you define the resources which are excluded out by it’s custom resource controller.
  • sleepAt — Cron like or absolute time when the resource sleeps at.
  • wakeUpAt — Cron like or absolute time when the resource wakes up at.
  • weekdays — Cron like indicating the days when the resource sleep or wake rules get enforced.

With this basic understanding, its quite clear that barring “do-not-sleep” pod(s), all other pod(s) will sleep every 5th minute & wake up every 7th minute and this is for all days of the week.

Alternatively, one can as well define an absolute time value at which the pods will go to sleep and then wake up. Take a look at the below example as a reference -

                apiVersion: kube-green.com/v1alpha1
kind: SleepInfo
metadata:
  name: sleep-test
spec:
  weekdays: "*"
  sleepAt: "16:03"
  wakeUpAt: "16:05"
  timeZone: "Europe/Rome"
  excludeRef:
    - apiVersion: "apps/v1"
      kind:       Deployment
      name:       do-not-sleep
            

To learn more around every configurations of this CR, do check the available documentations over here.

All these capabilities are not native to Kubernetes & this is where Operators through their Custom resources and Custom controllers come into picture; thus extending Kubernetes base capabilities!

Hope with this real life example, I helped in visualising & onboarding you with Kubernetes operators!

Installing the kube-green operator

Pre-requisite

Ensure the cert-manager availability in your cluster & if not present then install it -

                $ kubectl apply -f https://github.com/jetstack/cert-manager/releases/latest/download/cert-manager.yaml
            

and confirm if deployment is successful -

                $ kubectl -n cert-manager get pods
            

Step 1

One-time pre-requisite is to have the Operator Lifecycle Manager (OLM) installed in your Kubernetes cluster. This is a tool to help manage the Operators running on the cluster.

We will learn about OLM in depth in future episodes (will leave behind a link here in future once I have it published); for now consider this as a one-time pre-requisite which you need to install.

Lets install it -

                $ curl -sL https://github.com/operator-framework/operator-lifecycle-manager/releases/download/v0.21.2/install.sh | bash -s v0.21.2
            
1_yOZw-u5ysUGeAoasHPqgtg.png

OLM installation

Step 2

Next, of course, installing the Kube-green operator and here is how you could do it -

                $ kubectl create -f https://operatorhub.io/install/kube-green.yaml
            
1_lx7LZHwzpFcsH1vDI_Ydmg.png

Kube-green operator installation

This Operator will be installed in the “operators” namespace and will be usable from all namespaces in the cluster.

Step 3:

Well, lets see the resources the Kube-green operator installation has ended up creating in our cluster —

                $ kubectl get csv -n operators
            
1_AqR6dctOWAXXxloGEtjdQA.png

Kube-green operator installing phase

1_xEMZTPtebG-NSGUf-mZaqQ.png

Kube-green operator successful installation

1_2rqLkf62Msa9Qlv6gWc4qw.png

Resources created by kube-green operator installation

Using the kube-green operator

Lets get into the interesting part i.e. seeing the operator working!

Step 1

Let us deploy a sample application for our demo. This sample applications (pods in Kubernetes cluster) will act as resources for demonstrating the capabilities of kube-green.

                $ kubectl create ns sleepme
$ kubectl -n sleepme create deploy echo-service-replica-1 --image=davidebianchi/echo-service
$ kubectl -n sleepme create deploy do-not-sleep --image=davidebianchi/echo-service
$ kubectl -n sleepme create deploy echo-service-replica-4 --image=davidebianchi/echo-service --replicas 4
            

You should have 6 pods running in the namespace -

1_MS4PTeUZmMQtoXQA5vhu2A.png

Sample application for demonstrating kube-green capabilities

Step 2

Now, lets create a SleepInfo CR. Remember, we have shortly visited it sometime back but now we will take it to use for our test scenario.

Consider the following configuration for our demonstration scenario -

  • echo-service-replica-1 sleeps at every 2 minutes and wakes up at every 3rd minute.
  • all replicas of echo-service-replica-4 will sleeps at every 2 minutes and wakes up at every 3rd minute.
  • do-not-sleep pod will never sleep.

Applying this SleepInfo CR in our cluster -

                $ cat sleepinfoCR.yaml
apiVersion: v1
items:
- apiVersion: kube-green.com/v1alpha1
  kind: SleepInfo
  metadata:
    name: sleep-test
    namespace: sleepme
  spec:
    excludeRef:
    - apiVersion: apps/v1
      kind: Deployment
      name: do-not-sleep
    sleepAt: '*:*/2'
    wakeUpAt: '*:*/3'
    weekdays: '*'
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

$ kubectl apply -f sleepinfoCR.yaml
            
1_dpEfSlEVHNzdQcDDgRW2rQ (1).png

applying the SleepInfo CR

1_hm_8jdGHshVJF3UBWdj5mQ (1).png

Verifying the installation of SleepInfo CR

1_ibFCsFJrEJemoSa0a8gRQw (1).png

Verifying the contents of deployed SleepInfo CR

So, after the sleep, as expected 1 pod is active -

1_DAjcOsBfvkxBCtICecXS2w (2).png

unnecessary pods terminated by kube-green controllers

1_ZsMv0g7Iv_L1wwgYaqBA1g.png

one pod remaining active as per our SleepInfo CR definition

And after sometime the other pods wake up & we see 6 active pods -

1_r41BU9LjIbVC2-TAtEA6cQ.png

after wakeUpAt time, kube-green controller starting slept pods

1_VYifWTnETXg3428RXuS97A.png

all 6 pods active back

What Next?

Well, you learnt how to crawl in this episode by observing an existing real life Kubernetes operator. Whether you realised it or not but if you have gone through all the above, you unintentionally have equipped yourself with the required fundamentals to sail through the next level!

Next you will learn the skills that enables you to walk towards the path of understanding the Kubernetes operators. I assure you its going to be -

  • More fun,
  • More interesting and
  • More engaging than before!

Until then, take care & be safe! CU!


Only registered users can post comments. Please, login or signup.

Start blogging about your favorite technologies and get more readers

Join other developers and claim your FAUN account now!

Avatar

Sanjit Mohanty

Staff Engineer, VMware

@sanjimoh
Stats
16

Influence

289

Total Hits

1

Posts