当前位置：首页 > news >正文

青岛公司网站建设价格低2345网址导航

news 2025/7/8 10:52:11

青岛公司网站建设价格低,2345网址导航,如何给网站增加外链,做网站宣传1 Knative Eventing的相关组件 Knative Eventing具有四个最基本的组件：Sources、Brokers、Triggers 和 Sinks 事件会从Source发送至SinkSink是能够接收传入的事件可寻址（Addressable）或可调用（Callable）资源 Knative S…

1 Knative Eventing的相关组件

Knative Eventing具有四个最基本的组件：Sources、Brokers、Triggers 和 Sinks
- 事件会从Source发送至Sink
- Sink是能够接收传入的事件可寻址（Addressable）或可调用（Callable）资源
  - Knative Service、Channel和Broker都可用作Sink
Knative Eventing的关键术语
- Event Source
  - Knative Eventing中的事件源主要就是指事件的生产者
  - 事件将被发往Sink或Subscriber
- Channel和Subscription
  - 事件管道模型，负责在Channel及其各Subscription之间格式化和路由事件
- Broker和Trigger
  - 事件网格（mesh）模型，Producer把事件发往Broker，再由Broker统一经Trigger发往各Consumer
  - 各Consumer利用Trigger向Broker订阅其感兴趣的事件
- Event Registry
  - Knative Eventing使用EventType来帮助Consumer从Broker上发现其能够消费的事件类型
  - Event Registry即为存储着EventType的集合，这些EventType含有Consumer创建Trigger的所有必要信息

2 Event 处理示意图

Event Source：事件源，即生产者抽象，负责从真正的事件源导入事件至Eventing拓扑中
Event Type：事件类型，它们定义于Event Registry中
Flow：事件处理流，可简单地手工定义流，也可使用专用的API进行定义
Event Sinks：能接收Event的可寻址（Addressable）或可调用（Callable）资源，例如KService等

在这里插入图片描述

3 Knative的事件传递模式

Knative Eventing中的Sink的用例主要有Knative service、channel、Broker三种
Knative Eventing支持的事件传递模式
- Sources to Sink
  - 单一Sink模式，事件接收过程中不存在排队和过滤等操作
  - Event Source的职责仅是传递消息，且无需等待Sink响应
  - fire and forget
- Channels and Subscriptions
  - Event Source将事件发往Channel
  - Channel可以有一到多个Subscription（即Sink）
  - Channel中的每个事件都被格式化Cloud Event并发送至各Subscription
  - 不支持消息过滤机制
- Brokers and Triggers
  - 功能类似于Channel和Subscription模式，但支持消息过滤机制
  - 事件过滤机制允许Subscription使用基于事件属性的条件表达式（Trigger）筛选感兴趣的事件
  - Trigger负责订阅Broker，并对Broker上的消息进行过滤
  - Trigger将消息传递给感兴趣的Subscription之前，还需要负责完成消息的格式化
  - 这是在生产中推荐使用的消息投递模式

4 CloudEvents示例

最为简单的Event发送示例
- Source：curl命令，基于HTTP消息映射规范手动编制消息及事件内容
- Sink: 基于能够接收、解析事件，并将其存入日志的event_display应用为例来模拟事件处理
  - event_display可运行为Kubernetes Service，或者Knative Service

步骤

将event_display运行为Kservice。

kn service create event-display --image ikubernetes/event_display --port 8080 --scale-min 1

在这里插入图片描述

启动一个client的pod，发起请求测试

kubectl run client --image=ikubernetes/admin-box:v1.2 --restart=Never --rm -it --command -- /bin/bash

发起请求测试命令：

curl -v "http://event-display.default.svc.cluster.local" \
-X POST \
-H "Ce-Id: say-hello" \
-H "Ce-Specversion: 1.0" \
-H "Ce-Type: com.icloud2native.sayhievent" \
-H "Ce-Time: 2023-12-01T11:35:56.7181741Z" \
-H "Ce-Source: sendoff" \
-H "Content-Type: application/json" \
-d '{"msg":"Hello littlyboy Knative!"}'

在这里插入图片描述

查看event_display中的log是否收到事件

kubectl logs -f event-display-00001-deployment-5ddb97ff7-mfhhq

在这里插入图片描述

5 Eventing的逻辑组件

Eventing API群组及相应的CRD
- sources.knative.dev # 声明式配置Event Source的API，提供了四个开箱即用的Source；
  - ApiServerSource：监听Kubernetes API事件
  - ContainerSource：在特定的容器中发出针对Sink的事件
  - PingSource：以周期性任务（cron）的方式生具有固定负载的事件
  - SinkBinding：链接任何可寻址的Kubernetes资源，以接收来自可能产生事件的任何其他Kubernetes资源
- eventing.knative.dev # 声明式配置“事件网格模型”的API
  - Broker
  - EventType
  - Trigger
- messaging.knative.dev # 声明式配置“事件管道模型”的API
  - Channel
  - Subscription
- flows.knative.dev # 事件流模型，即事件是以并行还是串行的被多个函数处理
  - Parallel
  - Sequence