[Cloud Native Series] Lecture 4: Eventing of Knative

Table of contents

preamble

1. Basic introduction 

2. Components

2.1 Event Source (Event Source)

2.2 Event processing (Flow)

2.3 Event Consumer (Event Consumer)

3. Architectural Patterns

3.1 Source to Service

​Edit 3.2Channels & Subscriptions

3.3 Brokers & Triggers

 3.4 Others

4. Summary

5. vote

---

preamble

A few words, it is better to explore carefully .

Today, I sorted out the knowledge points related to Eventing. I hope this article can help readers have a preliminary understanding of Knative Eventing.

Article tag color description:

• Yellow : important headlines
• Red : used to mark conclusions
• Green : Used to mark first-level arguments
• Blue : Used to mark secondary arguments

1. Basic introduction 

When Kubernetes users achieve loose coupling between services in the development and deployment phases, they often need to pass events through different event mechanisms. In order to solve most of the cloud-native message communication needs , Knative provides the Eventing component.

Features:

1. Loose coupling of service development and deployment
2. Support various event delivery
3. Event producers and event consumers are independent of each other

4. Ensure interoperability across services

5. Support third-party service docking Eventing system

2. Components

Eventing mainly consists of

1. Event Source
2. Event processing (Flow)
3. Event Consumer

It consists of three parts.

2.1 Event Source (Event Source)

Source is the source of the event, it is the way to define where the event is generated and how the event is delivered to the object of interest 

• event generation
• event delivery

Currently supports the following 8 event sources: 

1. ApiserverSource : ApiserverSource fires a new event every time a Kubernetes resource is created or updated

2. GitHubSource : GitHubSource fires a new event when GitHub operates

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

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

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

6. CronJobSource : Generate events through CronJob

7. KafkaSource : Receives Kafka events and triggers a new event

8. CamelSource : Receive Camel related component events and trigger a new event

2.2 Event processing (Flow)

Former Knative supports the following event receiving and processing:

• Receive : Direct Event Receive

  Forward directly to a single event consumer via the event source. It supports direct calling of Knative Service or Kubernetes Service for consumption processing. In such a scenario, if the called service is unavailable, the event source is responsible for the retry mechanism

• Forwarding : Forward event processing through event channels (Channel) and event subscriptions (Subscriptions)

  In such a case, the Channel can be used to ensure that the event is not lost and buffered, and the Subscriptions can be used to subscribe to the event to meet the processing requirements of multiple consumers.

• Filtering : Support event consumption and filtering mechanism through brokers and triggers

2.3 Event Consumer (Event Consumer)

In order to meet the requirements of sending events to different types of services for consumption, Knative Eventing defines two common interfaces through multiple k8s resources:

• Addressable interface : Provides the HTTP request address that can be used for event receiving and sending, and is defined by the status.address.hostname field. As a special case, Kubernetes Service objects can also implement the Addressable interface
• Callable interface : Receives events delivered via HTTP and transforms them. These returned events can be further processed in the same way as events from external event sources

Currently Knative supports consuming events through Knative Service or Kubernetes Service.

In addition, for event consumers, how to know in advance which events can be consumed? 

Event sources are sent to channels, and services are ready to handle them, but there is currently no way to get events sent from channels to services. To this end, Knative has designed a subscription function. Subscription is the link between channels and services , instructing Knative how to manage events throughout the system, as shown below

Summarize:

Services in Knative don't care how events and requests are obtained.

• HTTP requests from the ingress gateway can be obtained
• Events sent from the channel can be obtained

No matter how it is obtained, the service only accepts HTTP requests.

This is an important decoupling method in Knative .

It ensures that code is written into the architecture, rather than creating subscriptions, channels, and sending events to services under the hood. 

3. Architectural Patterns

There are three architectural patterns:

1. Source to Service
2. Channels & Subscriptions
3. Brokers & Triggers

3.1 Source to Service

Direct delivery from source to individual services (addressable endpoints, including Knative services or core Kubernetes services).

In this case, the source is responsible for retrying or queuing events if the destination service is unavailable 

 3.2Channels & Subscriptions

Through channels and subscriptions, the Knative event system defines a channel that can connect to various backends (such as in-memory, Kafka, and GCP PubSub) to source events.

Each channel can have one or more subscribers in the form of Sink Services

As shown in the figure, the subscriber can receive event messages and process them as needed. Each message in the channel will be formatted as a CloudEvent and sent further in the chain to other subscribers for further processing.

Channel and subscription usage patterns cannot filter messages .

3.3 Brokers & Triggers

Broker provides a series of events, which can be selected through attributes .

It receives events and forwards them to subscribers defined by one or more matching Triggers.

Trigger describes a filter of event properties that should be passed to the addressable object.

You can create as many Triggers as you need.

 

 3.4 Others

Higher level event constructs:

In some cases it may be desirable to use a set of collaborative features together, for these use cases Knative Eventing provides two additional resources:

• Sequence  provides a way to define an ordered list of features.
• Parallel  provides a way to define a list of event branches.

I will write an article later, specifically about ordered lists and branched lists

4. Summary

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

1. Build image build
2. Serving container deployment
3. Eventing event global subscription, delivery, management

5. vote