Community

Blog Events Webinars Tutorials Forum
  1. Blog
  2. Events
  3. Webinars
  4. Tutorials
  5. Forum
Create Account
×
Community Blog The Core Components of Knative: Build, Serving, and Eventing

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

This post provides an overview of the three 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

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:

  • 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:

1

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.

Serving

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:

  • 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:

2

Eventing

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:

  • 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:

3

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:

  • 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

Currently, Knative supports the following event flows:

  • 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

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

  • 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.

Summary

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.

Cluster Container Container Service Container Service for Kubernetes Serverless Kubernetes Container Registry Istio cloud native Knative
0 0 0
Share on

Read previous post:

Ranked Best in China and as a Strong Performer Globally

Read next post:

Kubernetes Releases (1.15 and 1.16) in Detail

Alibaba Container Service

120 posts | 26 followers

You may also like

Comments

Alibaba Container Service

120 posts | 26 followers

Related Products

More Posts by Alibaba Container Service

See All