Shulou(Shulou.com)06/01 Report--

This article is about how to Knative in the Build, Serving and Eventing three core components, editor feel very practical, so share with you to learn, I hope you can learn something after reading this article, say no more, follow the editor to have a look.

Author | Yuan Yi, senior development engineer of Aliyun Intelligent Business Group

Draw the key points

First acquaintance with Knative: the cross-platform Serverless choreography framework gives us a preliminary understanding of Knative. Knative is mainly composed of Build, Serving and Eventing core components. Knative relies on these three core components to drive the Serverless ship Knative. This paper introduces these three core components respectively.

Build

Knative Build is a set of standardized, portable and reusable container image construction methods based on the existing Kubernetes capabilities. By running complex build tasks on Kubernetes, Knative Build eliminates the need to develop and repeat these mirror build processes separately, thus reducing image build time and cost in a systematic and engineering way.

Build is implemented through Kubernetes Custom Resource definition (CRD). With Build you can customize a build process from run to finish. For example, you can use Knative Build to get, build, and package code. Build has the following features:

Source source mount is supported. Currently, supported Source sources include:

* git code repository

* any container image

Support for the creation of repeatable build templates through BuildTemplate

Support for K8s ServiceAccount authentication

A typical Build diagram:

Although Knative Build does not provide a complete independent CI/CD solution at present, it does provide an underlying building module that users can use alone to integrate and utilize in large systems.

Serving

Knative as a Severless framework is ultimately used to provide services, then Knative Serving arises at the historic moment.

Knative Serving is built on Kubernetes and Istio to provide deployment and service support for Serverless applications. Its characteristics are as follows:

Rapid deployment of Serverless containers

Support automatic scaling and shrinking to 0 instances

Based on Istio components, provide routing and network programming

Support for deployment snapshots

The following CRD resources are defined in Knative Serving:

Service: automatically manages the entire lifecycle of the workload. Responsible for creating Route, Configuration, and Revision resources. Service allows you to specify whether routed traffic uses the latest Revision or a fixed Revision

Route: responsible for mapping network endpoints to one or more Revision. Traffic can be managed in a variety of ways, including grayscale traffic and renamed rout

Configuration: responsible for maintaining the desired state of Deployment, providing a clear separation between code and configuration, and following the 12 elements of application development. Modify Configuration to produce one Revision at a time

The Revision:Revision resource is a point-in-time snapshot of the code and configuration for each modification to the workload. Revision is an immutable object and can be retained for a long time

Resource diagram:

Eventing

Knative Eventing is designed to meet common needs in cloud native development, providing a combinable way to bind event sources and event consumers. Its design objectives are:

The services provided by Knative Eventing are loosely coupled and can be developed and deployed independently. Services can be used across platforms (such as Kubernetes, VMs, SaaS or FaaS)

The producer and the consumer of the event are independent of each other. The producer (event source) of any event can generate the event before the consumer of the event is listening, and the consumer of the same event can listen for the event before it occurs.

Support third-party services to dock the Eventing system

Ensure interoperability across servic

Event handling diagram:

As shown in the figure above, Eventing is mainly composed of three parts: event source (Event Source), event processing (Flow) and event consumer (Event Consumer).

Event source (Event Source)

The following types of event sources are currently supported:

ApiserverSource: every time a Kubernetes resource is created or updated, ApiserverSource triggers a new event

During the GitHubSource:GitHub operation, GitHubSource triggers a new event

GcpPubSubSource: GCP cloud platform Pub/Sub service will trigger a new event

AwsSqsSource:Aws cloud platform SQS service will trigger a new event

ContainerSource: ContainerSource will instantiate a container through which events are generated

CronJobSource: generating events through CronJob

KafkaSource: receives the Kafka event and triggers a new event

CamelSource: receives Camel related component events and triggers a new event

Event receive / forward (Flow)

Currently, Knative supports the following event reception processing:

Direct event reception

Forwarded directly to a single event consumer through the event source. You can directly call Knative Service or Kubernetes Service for consumption processing. In such a scenario, if the invoked service is not available, the event source is responsible for the retry mechanism processing.

Forward event processing through event channel (Channel) and event subscription (Subscriptions)

In such cases, events can be guaranteed not to be lost and buffered through Channel, and events can be subscribed to by Subscriptions to satisfy multiple consumers' processing.

Support event consumption and filtering mechanisms through brokers and triggers

Starting with v0.5, Knative Eventing defines Broker and Trigger objects to filter events (like filtering network traffic through ingress and ingress controller) to create Channel by defining Broker, to create Channel subscriptions (subscription) through Trigger, and to generate event filtering rules.

Event consumer (Event Consumer)

To satisfy the consumption of sending events to different types of services, Knative Eventing defines two common interfaces through multiple K8s resources:

The Addressable interface provides HTTP request addresses that can be used to receive and send events, which are defined by the status.address.hostname field. As a special case, the Kubernetes Service object can also implement the Addressable interface

The Callable interface receives events passed through HTTP and converts events. These returned events can be further processed in the same way that events from external event sources are handled.

Currently, Knative supports consumption events through Knative Service or Kubernetes Service.

In addition, for event consumers, how to know in advance which events can be consumed? Knative Eventing provides a Registry event registration mechanism in the latest version 0.6, so that event consumers can know in advance which event types in Broker can be consumed through Registry.

Summary

Knative uses Build to provide cloud native "from source code to container" image building capabilities, deploys containers and provides a common service model through Serving, and provides global event subscription, delivery and management capabilities with Eventing to achieve event-driven. This is the standard Serverless orchestration framework that Knative presents to us.

These are the three core components of Build, Serving and Eventing in Knative. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.