ServerLess and Kubernetes!

Image for post
Image for post

A cloud computing service in which the customer pays for each function executed rather than a full server or part of a server (a virtual machine) that may be idle periodically. For example, the time required to execute the code that updates a record in a database would be charged to the serverless computing customer.

What is it ?

It is an execution model or framework where applications can be deployed without worrying about underlying infrastructure plumbing . Like for example if we want to setup a web server in a normal virtualized env , we would have to setup and maintain web backend , frontend, data storage , etc . The objective of a serverless approach is an attempt to reduce these to cloud/infrastructure functions .

With the popularization of this concept, companies have launched their serverless products such as AWS Lambda, Azure Function, Google Cloud Functions, and Alibaba Cloud Function Compute.

Enter Kubernetes …

With kubernetes stepping in to be a really loved platform (for devs mostly) the push for serverless on kubernetes has also seen an increase. As a result various open source initiatives have emerged as part of the serverless product group.

Image for post
Image for post
Image for post
Image for post
Knative + Fission

CNCF has summarized this the process of implementation of a function on Kubernetes as follows

  1. Write Code (Function)
  2. Build Docker Image/Artifact
  3. Kubernetes Deployment

To put it simply all the open source products aim to implement functions in this fashion as they are guidelines

As per CNCF mature serverless product must possess flexible triggering capabilities to cope with diversified characteristics of event sources, and be able to conveniently integrate new event sources. In some literature they are also termed as eventing sources . (in OS terms) they are like interrupts which invokes a the same task.

Serverless in Action —> Kubeless

In order to understand how this all fits together on Kubernetes with Kubeless as an example.

kubeless is a Kubernetes-native serverless framework that lets you deploy small bits of code without having to worry about the underlying infrastructure plumbing. It leverages Kubernetes resources to provide auto-scaling, API routing, monitoring, troubleshooting and more.

kubeless has three primary concepts:-

  1. Functions — This is the actual code to be executed along with metadata and dependancies
  2. Triggers — An event source that executes the specific function it is associated with
  3. Runtime — The language/environment (The interpreters which executed the user input Functions)

Lets go ahead and install kubeless on an existing K8s cluster

  1. Cli install

2. Deploy the CRDS

3. This will deploy the kubeless operator in default namespace. Lets take a look at the runtimes supported by kubeless out of the box

This shows us the various language support from kubeless .

We can also use custom runtimes as well.

Each runtime in essence is a docker artifact with a kubeless starter code listening to the triggers

4. For the purpose of demonstration we will implement a function to calculate whether a number is prime or not (A pretty trivial example)

4. Next we deploy a function using the same to check how it operates

5. Alright, now that we we have our function in READY state , lets try to see if it actually works . We will do this by using a Trigger .

6. Ok great!. So we just witnessed serverless in action. All we had to do was write a Python script!!. The implementation on K8s takes care of executing our code and managing the interpreter and all other dependancies as well!!

7. If you are still with me here, am sure you are wondering the “how” ?

Control Flow For Kubeless

A kubeless function is very similar to a K8s operator which has the following

  • A CRD, that basically is a way to extend K8s and define new resources
  • An event handler to handle events like ADD/UPDATE/DELETE . In this case the handler is defined in our script prime.py
  • A user runs a command to add, update, and delete custom resources.
  • The controller calls the corresponding handler based on the detected event

Kubeless Function Anatomy

A kubeless function translates to the following objects on Kubernetes

  1. A deployment — This is how the runtime is managed
  2. A configmap — This contains the user data (the actual Function!!)
  3. A service — For the function to be accessible

Lets take look at each one of them

The ConfigMap — You can see that our code gets embedded here

The Service — Manages the external access to the function deployed

The Deployment — The deployment comprises of a single pod (to start with) comes up with 2 containers

  • Init container — copies src code from config map mounted as volume and installs dependancies like packages,etc
  • Function container — where actual execution of prime.py takes place
  • User can set resource limits on the Functions as well!!
  • By default a security context is also present. This prevents malicious code exec by default . User can customize this also.
  • Configmap is mounted as a volume here so that Function has access to the code /kubeless/<functionname>

Triggers

Now that we have seen how kubeless is implemented on kubernetes, lets try to understand what makes it click => triggers . Below are the triggers supported by kubeless

HTTP trigger operation

a. The HTTP request is first processed by NGINX (gateway)of the nginx-ingress-controller.

b. NGINX transfers the request to the corresponding service of the function based on the routing rule of nginx.conf. (this is from the ingress that kubeless creates)

c. Finally , the request is transferred to a function mounted to the service for processing.

To understand how triggers works lets take a new and simpler example

  1. Create a function with below code

2. Make sure the K8s cluster has an ingress controller running . This is a pre-requisite for using HTTP triggers. Also make sure you have LB support on the cluster (like metalLB)

3. Our function is already deployed, now we deploy the trigger

4. A trigger directly translated to a kubernetes ingress onbject

5. Now to access this function we will use a new method (we have used two types of triggers in earlier section while demonstrating prime number function)

Conclusion

This concludes our deep dive into kubeless and serverless. Hope that was helpful.

Written by

The devil is in the details !!

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store