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: 1
      selector:
        matchLabels: &labels
          app: event-display
      template:
        metadata:
          labels: *labels
        spec:
          containers:
            - name: event-display
              image: ikubernetes/event_display
    ---
    kind: Service
    apiVersion: v1
    metadata:
      name: event-display
    spec:
      selector:
        app: event-display
      ports:
      - protocol: TCP
        port: 80
        targetPort: 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: v1
          kind: Service
          name: 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_display
              ports:
                - 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/v1
          kind: Service
          name: 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_display
              ports:
                - 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:latest
              name: heartbeats
              env:
              - name: POD_NAME
                valueFrom:
                  fieldRef:
                    fieldPath: metadata.name
              - name: POD_NAMESPACE
                valueFrom:
                  fieldRef:
                    fieldPath: metadata.namespace
      sink:
        ref:
          apiVersion: serving.knative.dev/v1
          kind: Service
          name: 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_display
              ports:
                - 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:
      - pods
      verbs:
      - get
      - list
      - watch
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: pod-reader
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: Role
      name: pod-reader
    subjects:
    - kind: ServiceAccount
      name: pod-watcher
    

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

    apiVersion: sources.knative.dev/v1
    kind: ApiServerSource
    metadata:
      name: pods-event
    spec:
      serviceAccountName: pod-watcher
      mode: Reference
      resources:
      - apiVersion: v1
        kind: Pod
      sink:
        ref:
          apiVersion: serving.knative.dev/v1
          kind: Service
          name: 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”