By Dong Dao, Technical Expert at Alibaba Cloud Intelligence Department
Knative is a serverless framework that is based on Kubernetes and was announced and developed by Google. One important goal of Knative is to establish a cloud-native and cross-platform orchestration standard. Knative implements this serverless standard through integrating the creation of container or function, workload management and auto scaling, and event models. In addition to Google, major contributors to the Knative community include Pivotal, IBM, and Red Hat. PaaS providers such as CloudFoundry and OpenShift are also actively making contributions to the Knative community.
Before Knative was developed, many serverless solutions had already been available in the community. These included Kubeless, Fission, OpenFaaS, and Apache OpenWhisk. In addition to these open-source solutions, major cloud providers also offered equivalent FaaS products, such Amazon Web Services's Lambda, Google Cloud's Functions, Microsoft's Azure Functions, and Alibaba Cloud's Function Compute.
Deploying business code to a serverless platform requires source code compilation, deployment, and event management. However, both open-source solutions and FaaS productions from public cloud providers all involve different implementation methods. The lack of uniform standards has caused some market fragmentation, with each available solution posing the possible risk of being bound to a specific solution provider.
Also, the lack of uniform standards and market fragmentation caused many other additional issues. For cloud providers, it is difficult to allow their users to migrate to the cloud in a serverless manner. And for PaaS providers, they find it hard to build a general-purpose PaaS platform for their users. However, to the aid of these difficulties, Google initiated the Knative project together with companies such as Pivotal, IBM, and Red Hat.
The following diagram shows the collaborative effort that lead to the Knative system:
Source: Knative GitHub repo
According to this diagram, you can see that with Knative:
The overall serverless framework of Knative consists of three core components:
Now, let's discuss these components in more detail.
The Build component is mainly responsible for obtaining source code from the code repository, compiling code into images and then pushing them into the image repository. All these operations are performed in Kubernetes Pods.
The Eventing component has a complete set of design implementations targeting serverless event-driven mode. These features include the connection to external event sources, event registry, event subscription, and event filtering. The event model can effectively make event producers and consumers decoupled and independent. Any producer can generate events before active event consumers start. Any consumer can listen to events before active producers start.
The Serving component is responsible for managing workloads and provide external services. The most important feature of Knative Serving is autoscaling (both up and down to zero). Another important feature of Serving is phased release.
You can say that, even though Knative is implemented on top of Kubernetes, this does not mean that all Kubernetes features can also be used in Knative. The reason for this is because that Knative is specifically designed for serverless scenarios, such as scenarios in which only one Container can be included in a Pod, and only on Port can be included in a Container. More related details will be described in follow-up articles.
Knative builds on Kubernetes to support serverless orchestration, and also is implemented based on Istio to enable features including service connection, route management and phased release. Knative is built on the existing cloud native basis and therefore has a large community base. Knative is positioned to create a large stir in the market once it was published as an open-source project thanks to the following reasons:
In this blog, we have described the background of the birth of Knative, issues expected to be solved by Knative, core concepts, and the advantages of Knative. In a series of follow-up articles, we will continue to describe the use of Knative and analyze its internal implementations.
Alibaba Container Service - May 30, 2019
Alibaba Clouder - July 12, 2019
Alibaba Container Service - July 16, 2019
Apache Flink Community China - August 2, 2019
Alibaba Clouder - April 8, 2019
Alibaba Developer - January 7, 2019
More Posts by Alibaba Developer