The Core Components of Knative: Build, Serving, and Eventing

By Li Peng, nicknamed Yuanyi at Alibaba.

Knative consists of three core components: Build, Serving, and Eventing. These three core components drive the evolution of serverless Knative. Let’s introduce these core components.


Knative Build provides a set of standardized, portable, and reusable container image building methods based on the existing Kubernetes capabilities. Complex building tasks are run on Kubernetes. You no longer need to separately develop and repeat these image building processes. As such, this systematic engineering method reduces the time and costs of image building.

Build is implemented through custom resource definition (CRD) in Kubernetes. Build allows you to customize a building process from running to the end. For example, you can use Knative Build to obtain, build, and package code. Build provides the following features:

A typical Build diagram is as follows:

Currently, Knative Build does not provide a complete and independent continuous integration and continuous delivery (CI/CD) solution. However, Knative Build provides an underlying building template, which allows users to independently integrate and use this building template in large systems.


As a serverless framework, Knative is ultimately used to provide services. Therefore, Knative Serving came into being. Knative Serving builds on Kubernetes and Istio to support deploying and serving of serverless applications. It provides the following features:

Knative Serving defines a set of objects as CRDs:

Diagram of the relationship between the resources:


Knative Eventing is a system that is designed to address a common need for cloud-native development and provides composable primitives to enable late-binding event sources and event consumers. Knative Eventing is designed around the following goals:

Event handling diagram:

As shown in the preceding figure, the Eventing system includes three components: an event source, a flow, and an event consumer.

Event Source

Currently, Knative Eventing defines the following types of event sources:

Event Receiving and Forwarding — Flow

Currently, Knative supports the following event flows:

Event Consumer

To enable delivery to multiple types of Services, Knative Eventing defines two generic interfaces that can be implemented by multiple Kubernetes resources.

Currently, Knative supports event consumption through Knative Service or Kubernetes Service. But, how can event consumers know in advance which events can be consumed? Well, as of version 0.6, Knative Eventing defines Registry, an event registration mechanism, to make it easier for consumers to discover the types of events they can consume from the different Brokers.


In Knative, Build provides cloud-native capabilities for building images from source code to containers. Serving deploys containers and provides generic service models. Eventing provides global event subscription, delivery, and management capabilities, to allow you to implement event-driven services. This is the standard serverless orchestration framework presented by Knative.

Original Source:

Follow me to keep abreast with the latest technology news, industry insights, and developer trends.