Knative Brings Event-Driven and Serverless Computing to Kubernetes

Kubernetes is a meta platform to build platforms: During the last couple of years, Kubernetes has gained industry acceptance which made it the foundation of modern infrastructure.

Contemporary applications rely on containers as the unit of deployment. Most of the code is packaged as container images and deployed on Kubernetes as pods.

Kubernetes has excellent support for scaling and managing the lifecycle of deployments. It simplifies many challenges that exist in managing virtual machines at scale.

Along with containers, the other important trend that picked up momentum is serverless computing. AWS Lambda, Azure Functions, Google Cloud Functions, and IBM Cloud Functions are some of the commercially available serverless environments to run code. They are based on the Functions as a Service (FaaS) delivery model of serverless computing where developers deploy code snippets directly to the platform.

Containers as a Service (CaaS) based on Kubernetes and Functions as a Service (FaaS) follow different approaches in deploying and executing code. FaaS is built on the philosophy of on-demand execution, per-second billing, and event-driven invocation while CaaS is designed to deliver scale and reliability of applications. While CaaS can be deployed within an enterprise data center, FaaS is still confined to the public cloud.

Modern applications use multiple patterns and practices to achieve scale, reliability, efficiency, and security. They use a combination of CaaS and FaaS to take advantage of the delivery models offered by cloud providers. Given the gap between these two delivery models, developers will have to deal with extremely different processes and workflows which are error-prone and expensive. Developers can’t standardize container images as the standard unit of deployment irrespective of where the code is executed.

There is also a need to bring serverless computing to on-premises and enterprise data centers. It should be based on proven infrastructure that’s used by the majority of developers.

Enter Knative

Knative, an open source project developed by Google, IBM, Pivotal, Red Hat, and SAP aims to make Kubernetes the best platform for running microservices as well as serverless applications. It also becomes an abstraction layer for Kubernetes hiding the complexity involved in packaging and deploying applications.

Knative is a PaaS built on top of Kubernetes meta platform to make developers productive and efficient. It exposes both the execution models: long-running workloads and event-driven code.

Developers targeting Knative package code as container images irrespective of the execution model. This removes the burden of managing two parallel execution environments — CaaS and FaaS. DevOps can use a unified, consistent CI/CD pipeline to build and deploy code.

Technically, Knative can be deployed in any Kubernetes environment which makes it possible to expose the serverless environment within an enterprise data center.

Behind the scenes, Knative relies on a service mesh like Istio to manage traffic routing, revisions, and metrics.

Developers targeting Knative don’t need to understand the intricacies of Kubernetes such as pods, deployments, services, and ingress. They package a container image as a microservice and deploy it to Knative which will handle the rest.

Google is one of the first cloud providers to offer a commercial implementation of Knative through Cloud Run. For a detailed walkthrough of Cloud Run, refer to my previous tutorial.

To deliver the promise of a PaaS, Knative offers two core building blocks — serving and eventing. Let’s take a closer look at these components.

Knative Serving

The serving component of Knative brings a familiar PaaS-like execution model to Kubernetes. It is responsible for exposing, hosting, scaling, and managing the lifecycle of a microservice packaged as a container image.

When targeting Knative, developers define a service that manages the entire lifecycle of the deployment. They can also define routes to selectively send the traffic to a different version of the same application. The configuration definition provides a clean separation between code and configuration. Modifying the configuration will result in a new revision. Finally, Knative serving manages revisions of an application, which is a point-in-time snapshot of code and configuration of a specific application.

These resources — service, route, configuration, and revision — are implemented as Custom Resource Definition (CRD) in Kubernetes. They are responsible for translating the Knative nomenclature to the standard Kubernetes primitives and objects.

Knative serving supports scale-to-zero feature where a service automatically gets terminated when there are no requests for a period of time. After getting terminated, if the service receives a new request, the serving resource will immediately launch a new pod to handle the request. Parameters such as the timeout, cooling period, and the maximum number of instances can be defined through Knative configuration associated with the service.

Knative Eventing

Knative eventing component provides the necessary infrastructure to connect event publishers and event consumers based on late-binding.

Like in other event-driven environments, event producers and even consumers are independent of each other. A producer may generate events before there are active event consumers that are listening. Any event consumer can express interest in an event or class of events, even before the producer starts publishing those events.

Knative comes with a broker that acts as a conduit between the event producers and consumers. Producers treat the broker like a hub by publishing all the messages to it. A trigger binds a consumer to the publisher through the broker. This loosely-coupled architecture makes it possible to deploy highly scalable eventing infrastructure.

Since multiple kinds of events can be sent to the same broker, a filter configuration option in the Trigger to subscribe to a specific type of event.

It is also possible to connect a consumer to the producer directly without going through the broker.

Knative supports sources such as containers, cron jobs, Kubernetes controller as some of the event sources. Additional sources such as Kafka, Google Cloud Pub/Sub, and NATS can be registered as external event sources that can send deliver messages via the broker.

Developers can write code to respond to events that are packaged as a container image and deployed as a Knative service.

Summary

If Kubernetes is the infrastructure, Knative is the platform component of the stack. It designed to enhance the developer experience, deliver the serverless execution model, and to run event-driven code within Kubernetes.

In the next part of this series, we will take a closer look at Knative serving through an end-to-end tutorial. Stay tuned.

Janakiram MSV’s Webinar series, “Machine Intelligence and Modern Infrastructure (MI2)” offers informative and insightful sessions covering cutting-edge technologies. Sign up for the upcoming MI2 webinar at http://mi2.live.