07-Eventing及实践

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

6 事件与Knative Eventing

• Knative Eventing
  • 负责为事件的生产和消费提供基础设施，可将事件从生产者路由到目标消费者，从而让开发人员能够使用事件驱动架构
  • 各资源者是松散耦合关系，可分别独立开发和部署
  • 遵循CloudEvents规范