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.


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:

  • Mount sources, such as Git code repositories and contain images.
  • Creates reusable building templates based on BuildTemplate.
  • Performs identity verification through Kubernetes ServiceAccount.

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.


  • Rapid deployment of serverless containers
  • Automatic scaling up and down to zero
  • Routing and network programming for Istio components
  • Deployment snapshots

Knative Serving defines a set of objects as CRDs:

  • Service: It automatically manages the whole lifecycle of your workload and controls the creation of routes, configurations, and revisions. Service can be defined to always route traffic to the latest revision or to a pinned revision.
  • Route: It maps a network endpoint to one or more revision resources. You can manage the traffic in several ways, including fractional traffic and named routes.
  • Configuration: It maintains the desired state for your deployment. It provides a clean separation between code and configuration and follows the Twelve-Factor App methodology. Modifying a configuration creates a new revision.
  • Revision: It is a point-in-time snapshot of the code and configuration for each modification made to the workload. Revisions are immutable objects and can be retained for as long as useful.

Diagram of the relationship between the resources:


  • Knative Eventing services are loosely coupled. These services can be developed and deployed independently on, and across a variety of platforms, for example, Kubernetes, virtual machines (VMs), software as a service (SaaS) or function as a service (FaaS) platforms.
  • Event producers and event consumers are independent. Any producer or source can generate events before there are active event consumers that are listening. Any event consumer can listen on events before there are producers that are creating those events.
  • Third-party services can be connected to the Eventing system.
  • Cross-service interoperability is ensured.

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

  • ApiserverSource: It fires a new event each time a Kubernetes resource is created or updated.
  • GitHubSource: It fires a new event each time an operation is performed on GitHub.
  • GcpPubSubSource: It fires a new event each time an event is published on a Google Cloud Platform (GCP) Pub/Sub service topic.
  • AwsSqsSource: It fires a new event each time an event is published on an Amazon Web Services (AWS) simple queue service (SQS) topic.
  • ContainerSource: It instantiates a container image which can generate events.
  • CronJobSource: It fires events based on Cron jobs.
  • KafkaSource: It receives an event from an Apache Kafka cluster and fires a new event.
  • CamelSource: It receives a camel-related component event and fires a new event.

Event Receiving and Forwarding — Flow

  • Directly receives an event. An event is directly forwarded by its event source to a single event consumer. You can directly call Knative Service or Kubernetes Service to consume the event. In this case, if the called service is unavailable, the event source initiates the retry mechanism for the event.
  • Forwards an event through an event channel and an event subscription. The channel persists the event and buffers the event for processing. The subscription allows users to subscribe to the event, so that the event can be processed by multiple consumers.
  • Consumes and filters an event by using Brokers and Triggers. As of version 0.5, Knative Eventing defines Broker and Trigger objects to make it easier to filter events. This is similar to using ingress commands and the ingress controller to filter network traffic. The Broker object is defined to create channels, and the Trigger object is defined to create channel subscriptions and generate event filtering rules.

Event Consumer

  • The addressable interface provides HTTP request addresses for receiving and sending events. This interface can be defined by using the status.address.hostname field. As a special case, the Kubernetes Service object also fulfils the addressable interface.
  • The callable interface receives an event delivered over HTTP and transforms the event. These returned events may be further processed in the same way that events from an external event source are processed.

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.


Original Source:

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