08-Event Sources和Sink架构

本文主要是介绍08-Event Sources和Sink架构，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

1 PingSource -> Kubernetes Service Sink

• 架构模型

  

• 示例1

  • 部署一个kubernetes类型的sink，这里面还是以event-display为例，下面是资源清单

    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:name: event-display
    spec:replicas: 1selector:matchLabels: &labelsapp: event-displaytemplate:metadata:labels: *labelsspec:containers:- name: event-displayimage: ikubernetes/event_display
    ---
    kind: Service
    apiVersion: v1
    metadata:name: event-display
    spec:selector:app: event-displayports:- protocol: TCPport: 80targetPort: 8080
    

  • 定义pingsource资源，指定sink为event-display

    apiVersion: sources.knative.dev/v1
    kind: PingSource
    metadata:name: ping-00001
    spec:schedule: "* * * * *"contentType: "application/json"data: '{"message": "Hello Eventing!"}'sink:ref:apiVersion: v1kind: Servicename: event-display
    

    后面knative-eventing的namespace会出现pingsource的POD

    

  • 获取event-display当中的日志信息，验证是否进行了事件发送

    kubectl logs -f event-display-6496b6c66d-7drk5
    

    

2 PingSource → Knative Service Sink

• 架构

  

• 示例2

  • 部署一个kservice类型的sink，这里面还是以event-display为例，下面是资源清单

    ---
    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:name: event-display
    spec:template:metadata:annotations:autoscaling.knative.dev/min-scale: "1"spec:containers:- image: ikubernetes/event_displayports:- containerPort: 8080
    

  • 定义pingsource资源，指定sink为event-display

    ---
    apiVersion: sources.knative.dev/v1
    kind: PingSource
    metadata:name: pingsource-00001
    spec:schedule: "* * * * *"contentType: "application/json"data: '{"message": "Hello Eventing!"}'sink:ref:apiVersion: serving.knative.dev/v1kind: Servicename: event-display
    

  • 获取event-display当中的日志信息，验证是否进行了事件发送

    kubectl logs -f event-display-00001-deployment-7f488cb57b-grsc6
    

    

3 ContainerSource → Knative Service Sink

• 旨在收集一些容器的event是，比如容器的一些元数据，下面是架构：

  

• 示例2

  • 部署一个kservice类型的sink，这里面还是以event-display为例，下面是资源清单

    ---
    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:name: event-display
    spec:template:metadata:annotations:autoscaling.knative.dev/min-scale: "1"spec:containers:- image: ikubernetes/event_displayports:- containerPort: 8080
    

  • 定义containergsource资源，指定sink为event-display

    apiVersion: sources.knative.dev/v1
    kind: ContainerSource
    metadata:name: containersource-heartbeat
    spec:template:spec:containers:- image: ikubernetes/containersource-heartbeats:latestname: heartbeatsenv:- name: POD_NAMEvalueFrom:fieldRef:fieldPath: metadata.name- name: POD_NAMESPACEvalueFrom:fieldRef:fieldPath: metadata.namespacesink:ref:apiVersion: serving.knative.dev/v1kind: Servicename: event-display
    

    在event-display的名称空间创建了一个containersource的pod

    

  • 获取event-display当中的日志信息，验证是否进行了事件发送

    kubectl logs -f event-display-00001-deployment-645944b779-2b4vt
    

    

4 ApiServerSource → Knative Service Sink

• apiserversource主要记录了aoiserver上的event，比如create/delete/update/get，架构如下：

  

• 示例4：

  • 部署一个kservice类型的sink，这里面还是以event-display为例，下面是资源清单

    ---
    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:name: event-display
    spec:template:metadata:annotations:autoscaling.knative.dev/min-scale: "1"spec:containers:- image: ikubernetes/event_displayports:- containerPort: 8080
    

  • 定义ServiceAccount：定义向指定目标资源的get,watch,list的相关权限

    apiVersion: v1
    kind: ServiceAccount
    metadata:name: pod-watcher
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:name: pod-reader
    rules:
    - apiGroups:- ""resources:- podsverbs:- get- list- watch
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:name: pod-reader
    roleRef:apiGroup: rbac.authorization.k8s.iokind: Rolename: pod-reader
    subjects:
    - kind: ServiceAccountname: pod-watcher
    

  • 定义apiserversource资源，结合serviceaccount，对指定权限的pod进行收集event

    apiVersion: sources.knative.dev/v1
    kind: ApiServerSource
    metadata:name: pods-event
    spec:serviceAccountName: pod-watchermode: Referenceresources:- apiVersion: v1kind: Podsink:ref:apiVersion: serving.knative.dev/v1kind: Servicename: event-display
    

    会发现创建一个apiserversource的pod

    

  • 获取event-display当中的日志信息，验证是否进行了事件发送

    kubectl logs -f event-display-00001-deployment-9469968cd-vb4l2 
    

    

5 GitLab Source

• 关于GitLabSource
  • 将GitLab仓库上的事件转为CloudEvents
  • GitLabSource为指定的事件类型创建一个Webhook，监听传入的事件，并将其传给消费者
• GitLabSource支持的事件类型包括如下这些：
  • 推送事件：push_events
    • 对应的CloudEvents的类型为“dev.knative.sources.gitlab.push”，以下类同
  • tag推送事件：tag_push_events
  • 议题事件：issues_events
  • 合并请求事件：merge_requests_events
  • 私密议题事件：confidential_issues_events
  • 私密评论：confidential_note_events
  • 部署事件：deployment_events
  • 作业事件：job_events
  • 评论：note_events
  • 流水线事件：pipeline_events
  • Wiki页面事件：wiki_page_events

5.1 GitLab Source 实践

• 示例环境说明

  • 一个部署可用的GitLab服务
  • GitLab服务上隶于某个用户（例如root）的代码仓库（例如myproject）
  • 负责接收CloudEvents的kservice/event-display

  

• 具体步骤

  • 部署Gitlab
  • GitLab上的操作
    • 为GitLab用户设置Personal Access Token
    • 准备示例仓库myproject
  • 在Knative上部署GitLabSource
  • 在Knative上部署KService/event-display
  • 创建Secret资源，包含两个数据项
    • GitLab上的Personal Access Token
    • GitLab调用GitLabSource与Webhook Secret
  • 创建GitLabSource资源
    • 从GitLab仓库加载事件
    • 将事件转为CloudEvents，并发往Sink

• 具体操作

  • 部署GitLab
  • Gitlab上操作
    • 通用→可见性：设定“自定义HTTP(S)协议Git克隆URL”

这篇关于08-Event Sources和Sink架构的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---