Ask and Knative

Introduction

With the development of cloud computing technology, cloud resource delivery has become more and more simple, and on-demand use has become possible. In the mode of using resources on demand, users focus more on the business itself and reduce their attention to infrastructure. Therefore, the concept of Serverless came into being. We know that Kubernetes has become the standard of today's cloud native industry, with good ecology and cross-cloud vendor capabilities. Kubernetes well abstracts the standard of IaaS resource delivery, but if you want to manage applications in Severless mode on Kubernetes, you still need to do a lot of work. Knative has further simplified the K8s, greatly reducing the complexity of application life cycle control, and providing automatic flexibility and grayscale publishing capabilities. At the same time, based on the extreme containerized serverless provided by Alibaba Cloud Severless Kubernetes (ASK), it brings you a complete set of cloud native serverless applications. This article will start with the following four parts:

• Why we need Knative

• Introduction to Knative

• Convergence of Knative and ASK

• Demonstration examples

Why we need Knative

We know that the current K8s has become the cloud native operating system in fact. Kubernetes basically exposes infrastructure capabilities through data abstraction, such as Service, Ingress, Pod, and Deployment. These capabilities are exposed to users through Kubernetes native API. On the other hand, Kubernetes provides standard interfaces for infrastructure capacity access, such as CNI and CRD, so that cloud resources can be accessed into Kubernetes' system in a standardized way. Today we look at Kubernetes' position, which is actually a link between the preceding and the following. Cloud native users use Kubernetes for the purpose of delivering and managing applications, including grayscale publishing, expansion and scaling, and taking into account resource costs.

But in the process of using Kubernetes, we will gradually find the following problems:

• It is more complex to realize service lifecycle management through k8s API

• Cloud IaaS resource specifications are complex, and each specification is applicable to different scenarios. It is difficult for users to combine all specifications by themselves

• Saving the cost of using resources, elasticity is becoming more and more important

So how can we simply use container (K8s) technology? How to use as needed and reduce costs? The answer is: Knative

Introduction to Knative

Knative is a Kubernetes-based serverless orchestration engine released at Google Cloud Next 2018. A very important goal of Knative is to develop cloud native, cross-platform serverless orchestration standards. Knative is a serverless standard implemented by integrating container building (or function), workload management (elasticity) and event model. The current main contributors of the Knative community are Google, Pivotal, IBM and Red Hat. In addition, PAAS providers such as CloudFoundry and OpenShift are actively participating in the construction of Knative.

Knative core module

The Knative core module mainly includes the event-driven framework, Eventing, and the deployment workload, Serving.

Serverless service engine - Serving

The core competence of Knative Serving is its simple and efficient application hosting service, which is also the foundation of its ability to support Serverless. Of course, as the Severless Framework cannot do without the ability to allocate resources on demand. Knative can automatically expand the number of instances at peak times according to the number of requests for your application. When the number of requests decreases, it can automatically reduce the number of instances, which can help you save costs very automatically. Serving also provides traffic management capabilities and flexible grayscale publishing capabilities. The traffic management capability can segment traffic according to the percentage, and the grayscale publishing capability can be grayscale according to the percentage of traffic.

A simple scenario: publish based on traffic grayscale

Let's take a simple traffic grayscale release as an example to see how to implement it in k8s.

We create a service that provides external access. In K8s, we need to create the following resources:

• Deployment: workload for deploying applications

• Service: provide service access and load balancing capabilities

• Ingress: The function of providing domain name access externally

• HPA: We need to create HPA to realize automatic elasticity according to the load (cpu, memory).

At the initial stage, the service is provided through V1. If a new version of grayscale is needed, the V2 version of the corresponding resource needs to be created, and then the direct traffic grayscale of V1 and V2 versions is achieved through Ingress. As shown in the figure:

We can see that in k8s, the grayscale process is based on traffic. We need to control these resources in a fine-grained manner, including the creation of resources corresponding to the new version and the cleaning of resources in the old version after the grayscale is completed. It is still complex for users. So how to publish grayscale in Knative?

• Create a Knative service

• Update Knative service

• Adjust version flow ratio

Here we only need to operate the Knative Service resource. For new changes, we only need to update the Knative Service information (such as images), and a new version will be automatically created. For grayscale procedures, we only need to adjust the traffic proportion of the corresponding version in the Knative Service. As shown below:

After looking at the grayscale publishing above, we will further introduce the Knative application model.

Application model

Knative provides a minimal application model - Knative Service, which meets the requirements of service deployment, service access and grayscale publishing. It can be understood by the following formula: Knative Service=workload+service access+grayscale traffic+automatic elasticity. The application model is as follows:

• Service: abstract the Serverless application model, and manage the application life cycle through service

• configuration: used to configure the information expected by the application. Configuration will be updated every time the service is updated

• revision: Each update of configuration will create a snapshot for version management

• route: route the request to Revision and forward different proportion of traffic to different Revisions

Rich flexible strategies

As a Serverless framework, its core capability is automatic elasticity. Knative provides a variety of elasticity strategies:

• Automatic expansion and contraction based on traffic request - KPA

• Automatic scaling based on CPU and Memory - HPA

• Support automatic scaling strategy of timing+HPA

• Provide event gateway to meet the precise distribution strategy of events

Integration of Knative and ASK

Let's learn about ASK first. Generally, we use K8s and need to prepare IaaS resources in advance to deploy applications, which undoubtedly violates the original intention of serverless. The answer is: ASK

ASK is a serverless Kubernetes launched by Alibaba Cloud. Users can directly deploy container applications without purchasing nodes, without node maintenance and capacity planning for the cluster. ASK cluster provides complete Kubernetes compatibility, and greatly reduces the threshold of Kubernetes use, allowing users to focus on applications rather than managing underlying infrastructure.

• Free of operation and maintenance: it is used out of the box, without node management, operation and maintenance and security maintenance.

• Extreme elastic capacity expansion: no capacity planning is required, and the capacity is expanded in seconds, and the capacity is expanded to 500 POD instances in 30s.

• Low cost: create POD on demand, support spot (preemptive instance), and reserve instance coupons

• Compatible with k8s: support deployment/statefulset/job/service/expression/crd, etc

• Knative: The application based on traffic is automatically elastic and shrinks to reserved instances

• Storage mount: support cloud disk, NAS, OSS storage volume

• Elastic Workload: support the ecl on-demand and spot mixed scheduling

• Integrate cloud products such as ARMS/SLS

Knative O&M complexity

After learning about ASK, let's take a look at some current problems faced by Knative itself:

• Gateway. The native community provides the Istio gateway capability, but there are many Istio components. Users need to pay resources and O&M costs when controlling these components. (Although Istio has been decoupled in the current community, users can choose more lightweight gateways by themselves, but resources and operation and maintenance costs still need to be invested)

• Knative control components. Currently, 7 control components need to be operated and maintained, and users need to invest additional resources and operation and maintenance costs

• Cold start problem. Serverless cannot bypass the problem of cold start of applications. When 0 to 1, we need to consider how to ensure the rapid response of services.

For the above problems, we provide the following capabilities in ASK Knative.

Gateway and SLB integration

Provide gateway capabilities through Alibaba Cloud SLB:

• Cost reduction: more than ten components have been reduced, greatly reducing operation and maintenance costs and IaaS costs

• Stability: SLB cloud products and services are more stable, reliable and easy to use

Control component sinking

Hosting Knative control components:

• Out of the box: users directly use the Serverless Framework without installing it themselves

• Free of operation and maintenance, low cost: the integration of Knative components and K8s clusters, users do not have to bear the burden of operation and maintenance, nor do they need to bear additional resource costs

• High control: all components are deployed at the control side, making upgrading and iteration easier

Reserved Instance

Solve the problem of cold start from 0 to 1:

• Cold start free: the 30-second cold start time from 0 to 1 is eliminated by reserving instances

• Controllable cost: the cost of the burst performance instance is 40% lower than that of the standard specification instance. If combined with the Spot instance, the cost can be further reduced

Demo example

• Install Knative in the ASK cluster

• Deploy the helloworld application and access

• Retain instances

Install Knative in the ASK cluster

Currently, it is supported to install Knative when creating an ASK cluster. You can also deploy Knative by clicking the component management tab in Application>Knative after the ASK cluster deployment is completed. The operation of deploying Knative on the existing ASK cluster is as follows:

1. Log in to the container service management console.

2. In the left navigation bar of the console, click Cluster.

3. On the cluster list page, click the target cluster name or the details under the operation column on the right of the target cluster.

4. In the left navigation bar of the cluster management page, select Application>Knative.

5. Click on the component management tab of Knative to deploy Knative.

6. After selecting the Knative component to install, click Deploy.

After the deployment of Knative, the results are as follows:

Deploy the helloworld application and access

1. Log in to the container service management console.

2. On the cluster list page, click the target cluster name or the details under the operation column on the right of the target cluster.

3. In the left navigation bar of the cluster management page, select Application>Knative.

4. In the upper right corner of the Service Management tab, click Create Service.

5. Set the cluster, namespace, service name, and select the configuration information such as the image and image version to use. Here we use the helloworld sample image.

6. Click Create. After creation, you can see the newly created service in the list of the service management tab. Click the service name to enter the service details page. The content is as follows:

7. Service access.

We bind the domain name to the host for access, or we can access it directly through the curl command as follows:

Reserved Instance

After the reserved instance is ready, the normal instance will be offline.