![]() |
VOOZH | about |
The concept is the same whether it is referred to as Serverless, Event-driven computing, or Functions As A Service (FaaS) dynamically assigns resources to run distinct functions, or microservices, that are triggered by events. Application developers can concentrate on the application rather than the underlying infrastructure and all of its maintenance aspects thanks to serverless computing platforms.
Although serverless platforms are offered by most cloud providers, you may create your own with just two materials. One is the container orchestration system Kubernetes, which has established itself as a common foundation for developing resilient, componentized systems. The second is any of several systems that Kubernetes uses to create serverless application patterns.
Table of Content
KEDA is a kubernetes-based event driven autoscaler. It helps in scaling the applications based on the events from various sources such as Messaging Queue, Databases etc.. It works through monitoring the event sources and adjust the number of kubernetes pods accordingly. On using the KEDA in kubernetes users can use various event sources such as Azure Queue, RabbitMQ, Prometheus metrics and many more. KEDA integrates seamlessly with kubernetes and can scale any container not just functions only.
Knative is a kubernetes based platform that comes with components such as Knative Server and Knative Eventing to facilitate in deploy, manage and scaling of serverless applications. Knative Serving helps in deploying and running the serverless workloads and Knative Eventing helps in managing the event-driven architecture. It simplifies in building, deploying and managing of serverless applications on kubernetes.
On top of it is an open-source serverless computing technology called Kubeless. Code can be deployed using Kubeless without requiring infrastructure management. Kubeless performs auto-scaling, routing, monitoring, and troubleshooting using Kubernetes resources. It is necessary to develop and implement routines that can be accessed through three distinct trigger methods.
HTTP triggered, exposed with its services and scheduling function, translates to a task; Pubsub triggered is managed using Kafka cluster, an integrated part of the Kubeless installation package. At the moment, Netcore, Ruby, NodeJS, and Python are supported.
For this to be implemented you'll need the:
kubectl create ns kubeless
kubectl create -f https://release-assets.githubusercontent.com/github-production-release-asset/73902337/7700ca00-59c2-11eb-815a-33c4b772ff09?sp=r&sv=2018-11-09&sr=b&spr=https&se=2025-07-23T12%3A22%3A19Z&rscd=attachment%3B+filename%3Dkubeless-v1.0.8.yaml&rsct=application%2Foctet-stream&skoid=96c2d410-5711-43a1-aedd-ab1947aa7ab0&sktid=398a6654-997b-47e9-b12b-9515b896b4de&skt=2025-07-23T11%3A21%3A40Z&ske=2025-07-23T12%3A22%3A19Z&sks=b&skv=2018-11-09&sig=H7xSFO9pzqfr73N3bokpDggAz4GBN2Q97pX5nWeuOf4%3D&jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmVsZWFzZS1hc3NldHMuZ2l0aHVidXNlcmNvbnRlbnQuY29tIiwia2V5Ijoia2V5MSIsImV4cCI6MTc1MzI3MDA3MSwibmJmIjoxNzUzMjY5NzcxLCJwYXRoIjoicmVsZWFzZWFzc2V0cHJvZHVjdGlvbi5ibG9iLmNvcmUud2luZG93cy5uZXQifQ.gj278ruWRlVS0F6D8MTuKTS3pKzJUgfslZY6-lYuLOk&response-content-disposition=attachment%3B%20filename%3Dkubeless-v1.0.8.yaml&response-content-type=application%2Foctet-stream
kubectl get pod -n kubeless
👁 Listing the pods in Kubeless
The following points guides you in deploying your first kubeless function. Before diving lets understand about kubeless function and Triggers:
Kubeless's primary building block is a function. Kubeless allows functions to be created in a variety of languages, including go, python, ruby, and java. A function always receives two arguments when it is called via an HTTP call, cron trigger, etc. Situation and Background. One may think of an event as an input to the standard functions. On the other hand, context is the attribute that holds the metadata.
Triggers are the piece of code that will automatically respond ( or invoke a function ) to events like an HTTP call, life-cycle events, or on a schedule. The triggers that are currently available in kubeless are
Regardless of the language or event source, all functions in Kubeless have the same structure. Generally speaking, each function
Let's take a closer look at the command:
kubeless function ls
kubeless function call hello --data 'Hey'
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx/
helm repo update
helm install ingress-nginx ingress-nginx/ingress-nginx
kubectl get pods -l app.kubernetes.io/name=ingress-nginx
##Create a HTTP trigger
kubeless trigger http create hello-http-trigger --function-name hello --path env
##Get the IP of the Ingress resource
ip=$(kubectl get ing hello-http-trigger -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
##Get the hostname of the Ingress resource
host=$(kubectl get ing hello-http-trigger -o jsonpath='{.spec.rules[0].host}')
##Invoke the function by triggering a HTTP request
curl --data 'HOSTNAME' --header "Host: $host" --header "Content-Type:application/json" $ip/env;echo
kubeless function delete hello
kubeless function ls
Redesigning of autoscaling infrastructure for the event driven applications helps in focus on the integrating the event driven mechanisms. This event driven mechanism dynamically responds to the workloads changes. On utilizing the tools like KEDA facilitates with efficient scaling based on the specific event triggers. It helps in ensuring the application with scaling up or down in real time as the event loads are fluctuating. The following are the some of the key points regarding the redesign autoscaling infrastructure for the event driven applications:
The integration of KEDA with Knative provides the enhanced scalability for the serverless applications by providing event-driven autoscaling. This integration improves the ability of KEDA to scale the kubernetes deployments based on the external events and Knative's serverless platform. It provides a seamless solution for efficient management of workloads. The following are the some of the key insights on integration of KEDA with Knative:
In Kubernetes, custom metrics supports the users in defining and collecting specific performance data tailored to their applications' needs. Unlike built-in metrics like CPU and memory usage, custom metrics are user-defined and can represent any aspect of application performance, such as request latency, queue length, or database connections. These metrics are typically exposed by applications through APIs or other endpoints and collected by monitoring systems like Prometheus. Kubernetes Horizontal Pod Autoscaler (HPA) can then utilize these custom metrics to dynamically adjust the number of pod replicas based on workload demands, enabling more efficient and fine-grained autoscaling. Custom metrics offer greater flexibility in scaling decisions, enabling Kubernetes to adapt more precisely to diverse application requirements and workload patterns.
The following are the best practices of Kubeless:
The following are the differences between kubernetes, keda and HPA:
Features | Kubernetes | KEDA | HPA (Horizantal Pod Autoscaler) |
|---|---|---|---|
Purpose | Kubernetes is a container orchestration platform | KEDA is an extension of kubernetes with autoscaling supporting with event driven workloads. | HPA is a native kubernetes features used for scaling based on the resource metrics. |
Scaling Mechanism | It scales the applications based on the CPU, memory usage | It scales based on the external event from the sources like queues and databases. | It scales based on the CPU, memory usage or custom metrics. |
Event-Driven | Their is no native support for event-driven autoscaling. | It is specially designed for even-driven autoscaling. | It relies on the resource metrics rather than events for scaling decisions. |
Use Cases | It generally used in orchestrating the containerized applications | KEDA is ideal for event-driven workloads such as processing and stream processing. | It is suitable for applications with predictable scaling patterns based on the resource usage. |
The following are the differences between Kubernetes and Openshift:
Features | Kubernetes | Openshift |
|---|---|---|
Origin | It is a open source project that is managed by CNCF | It is commercial project from the Redhat Company. |
Installation | In installation it requires manual setup and configuration | In Installation it offers a streamlined process with additional tools for management and monitoring. |
Ecosystem | It provides extensive ecosystem of tools and resources. | It offers advanced management of tools and features such as developer pipelines logging and monitoring |
Security | It comes up with providing the basic security features. | It offers advanced security features such as role-based access control (RBAC), image scanning and security compliances. |
Packaging | It comes with package of pure kubernete distribution | It comes with kubernetes bundle with additional features such as operator framework, developer tools and CI/CD pipelines. |
In conclusion, serverless Kubernetes with Kubeless offers a powerful and flexible platform for building event-driven microservices. It simplifies the process of deploying, scaling, and managing serverless functions by leveraging the capabilities of Kubernetes.
This approach enables the creation of scalable, responsive, and efficient microservices that can seamlessly integrate with other Kubernetes services and resources. With the ability to trigger functions based on various events, such as HTTP requests, cron jobs, or custom events, Kubeless empowers developers to build applications that are highly responsive to real-time data streams, webhooks, and IoT device messages.