Chapter 11. Event sources

Procedure

1. Create a service account, role, and role binding for the ApiServerSource object.

   You can do this by creating a file named authentication.yaml and copying the following sample code into it:

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: events-sa
     namespace: default 

   1

   
   
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: event-watcher
     namespace: default 

   2

   
   rules:
     - apiGroups:
         - ""
       resources:
         - events
       verbs:
         - get
         - list
         - watch
   
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: k8s-ra-event-watcher
     namespace: default 

   3

   
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: event-watcher
   subjects:
     - kind: ServiceAccount
       name: events-sa
       namespace: default 

   4

   1 2 3 4

   Change this namespace to the namespace that you have selected for installing the API server source.

   Note

   If you want to reuse an existing service account with the appropriate permissions, you must modify the authentication.yaml file for that service account.

   Create the service account, role binding and cluster binding:

   $ oc apply -f authentication.yaml

2. Create an ApiServerSource object that uses a broker as an event sink:

   $ kn source apiserver create <event_source_name> --sink broker:<broker_name> --resource "event:v1" --service-account <service_account_name> --mode Resource

3. Create a Knative service that dumps incoming messages to its log:

   $ kn service create <service_name> --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest

4. Create a trigger to filter events from the default broker to the service:

   $ kn trigger create <trigger_name> --sink svc:<service_name>

5. Create events by launching a Pod in the default namespace:

   $ oc create deployment hello-node --image=quay.io/openshift-knative/knative-eventing-sources-event-display

6. Check that the controller is mapped correctly by inspecting the output generated by the following command:

   $ kn source apiserver describe testevents

   Example output

   Name:                testevents
   Namespace:           default
   Annotations:         sources.knative.dev/creator=developer, sources.knative.dev/lastModifier=developer
   Age:                 3m
   ServiceAccountName:  events-sa
   Mode:                Resource
   Sink:
     Name:       default
     Namespace:  default
     Kind:       Broker (eventing.knative.dev/v1alpha1)
   Resources:
     Kind:        event (v1)
     Controller:  false
   Conditions:
     OK TYPE                     AGE REASON
     ++ Ready                     3m
     ++ Deployed                  3m
     ++ SinkProvided              3m
     ++ SufficientPermissions     3m
     ++ EventTypesProvided        3m

1. Get the pods:

   $ oc get pods

2. View the message dumper function logs for the pods:

   $ oc logs $(oc get pod -o name | grep event-display) -c user-container

   Example output

   ☁️  cloudevents.Event
   Validation: valid
   Context Attributes,
     specversion: 1.0
     type: dev.knative.apiserver.resource.update
     datacontenttype: application/json
     ...
   Data,
     {
       "apiVersion": "v1",
       "involvedObject": {
         "apiVersion": "v1",
         "fieldPath": "spec.containers{hello-node}",
         "kind": "Pod",
         "name": "hello-node",
         "namespace": "default",
          .....
       },
       "kind": "Event",
       "message": "Started container",
       "metadata": {
         "name": "hello-node.159d7608e3a3572c",
         "namespace": "default",
         ....
       },
       "reason": "Started",
       ...
     }

Procedure

1. Delete the trigger:

   $ kn trigger delete <trigger_name>

2. Delete the service:

   $ kn service delete <service_name>

3. Delete the API server source:

   $ kn source apiserver delete <source_name>

4. Delete the service account, cluster role, and cluster binding:

Procedure

1. To create a service account, role, and role binding for the API server source, create a file named authentication.yaml and copy the following sample code into it:

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: events-sa
     namespace: default 

   1

   
   
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: event-watcher
     namespace: default 

   2

   
   rules:
     - apiGroups:
         - ""
       resources:
         - events
       verbs:
         - get
         - list
         - watch
   
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: k8s-ra-event-watcher
     namespace: default 

   3

   
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: event-watcher
   subjects:
     - kind: ServiceAccount
       name: events-sa
       namespace: default 

   4

   1 2 3 4

   Change this namespace to the namespace that you have selected for installing the API server source.

   Note

   If you want to re-use an existing service account with the appropriate permissions, you must modify the authentication.yaml for that service account.

   After you have created the authentication.yaml file, apply it:

   $ oc apply -f authentication.yaml

2. To create an ApiServerSource object, create a file named k8s-events.yaml and copy the following sample code into it:

   apiVersion: sources.knative.dev/v1alpha1
   kind: ApiServerSource
   metadata:
     name: testevents
   spec:
     serviceAccountName: events-sa
     mode: Resource
     resources:
       - apiVersion: v1
         kind: Event
     sink:
       ref:
         apiVersion: eventing.knative.dev/v1beta1
         kind: Broker
         name: default

   After you have created the k8s-events.yaml file, apply it:

   $ oc apply -f k8s-events.yaml

3. To check that the API server source is set up correctly, create a Knative service that dumps incoming messages to its log.

   Copy the following sample YAML into a file named service.yaml:

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: event-display
     namespace: default
   spec:
     template:
       spec:
         containers:
           - image: quay.io/openshift-knative/knative-eventing-sources-event-display:v0.13.2

   After you have created the service.yaml file, apply it:

   $ oc apply -f service.yaml

4. To create a trigger from the default broker that filters events to the service created in the previous step, create a file named trigger.yaml and copy the following sample code into it:

   apiVersion: eventing.knative.dev/v1alpha1
   kind: Trigger
   metadata:
     name: event-display-trigger
     namespace: default
   spec:
     subscriber:
       ref:
         apiVersion: serving.knative.dev/v1
         kind: Service
         name: event-display

   After you have created the trigger.yaml file, apply it:

   $ oc apply -f trigger.yaml

5. To create events, launch a pod in the default namespace:

   $ oc create deployment hello-node --image=quay.io/openshift-knative/knative-eventing-sources-event-display

6. To check that the controller is mapped correctly, enter the following command and inspect the output:

   $ oc get apiserversource.sources.knative.dev testevents -o yaml

   Example output

   apiVersion: sources.knative.dev/v1alpha1
   kind: ApiServerSource
   metadata:
     annotations:
     creationTimestamp: "2020-04-07T17:24:54Z"
     generation: 1
     name: testevents
     namespace: default
     resourceVersion: "62868"
     selfLink: /apis/sources.knative.dev/v1alpha1/namespaces/default/apiserversources/testevents2
     uid: 1603d863-bb06-4d1c-b371-f580b4db99fa
   spec:
     mode: Resource
     resources:
     - apiVersion: v1
       controller: false
       controllerSelector:
         apiVersion: ""
         kind: ""
         name: ""
         uid: ""
       kind: Event
       labelSelector: {}
     serviceAccountName: events-sa
     sink:
       ref:
         apiVersion: eventing.knative.dev/v1beta1
         kind: Broker
         name: default

1. Get the pods:

   $ oc get pods

2. View the message dumper function logs for the pods:

   $ oc logs $(oc get pod -o name | grep event-display) -c user-container

   Example output

   ☁️  cloudevents.Event
   Validation: valid
   Context Attributes,
     specversion: 1.0
     type: dev.knative.apiserver.resource.update
     datacontenttype: application/json
     ...
   Data,
     {
       "apiVersion": "v1",
       "involvedObject": {
         "apiVersion": "v1",
         "fieldPath": "spec.containers{hello-node}",
         "kind": "Pod",
         "name": "hello-node",
         "namespace": "default",
          .....
       },
       "kind": "Event",
       "message": "Started container",
       "metadata": {
         "name": "hello-node.159d7608e3a3572c",
         "namespace": "default",
         ....
       },
       "reason": "Started",
       ...
     }

Procedure

1. Delete the trigger:

   $ oc delete -f trigger.yaml

2. Delete the service:

   $ oc delete -f service.yaml

3. Delete the API server source:

   $ oc delete -f k8s-events.yaml

4. Delete the service account, cluster role, and cluster binding:

   $ oc delete -f authentication.yaml

Procedure

1. To verify that the ping source is working, create a simple Knative service that dumps incoming messages to the service’s logs:

   $ kn service create event-display \
       --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest

2. For each set of ping events that you want to request, create a PingSource object in the same namespace as the event consumer:

   $ kn source ping create test-ping-source \
       --schedule "*/2 * * * *" \
       --data '{"message": "Hello world!"}' \
       --sink svc:event-display

3. Check that the controller is mapped correctly by entering the following command and inspecting the output:

   $ kn source ping describe test-ping-source

   Example output

   Name:         test-ping-source
   Namespace:    default
   Annotations:  sources.knative.dev/creator=developer, sources.knative.dev/lastModifier=developer
   Age:          15s
   Schedule:     */2 * * * *
   Data:         {"message": "Hello world!"}
   
   Sink:
     Name:       event-display
     Namespace:  default
     Resource:   Service (serving.knative.dev/v1)
   
   Conditions:
     OK TYPE                 AGE REASON
     ++ Ready                 8s
     ++ Deployed              8s
     ++ SinkProvided         15s
     ++ ValidSchedule        15s
     ++ EventTypeProvided    15s
     ++ ResourcesCorrect     15s

1. Watch for new pods created:

   $ watch oc get pods

2. Cancel watching the pods using Ctrl+C, then look at the logs of the created pod:

   $ oc logs $(oc get pod -o name | grep event-display) -c user-container

   Example output

   ☁️  cloudevents.Event
   Validation: valid
   Context Attributes,
     specversion: 1.0
     type: dev.knative.sources.ping
     source: /apis/v1/namespaces/default/pingsources/test-ping-source
     id: 99e4f4f6-08ff-4bff-acf1-47f61ded68c9
     time: 2020-04-07T16:16:00.000601161Z
     datacontenttype: application/json
   Data,
     {
       "message": "Hello world!"
     }

Procedure

1. To verify that the ping source is working, create a simple Knative service that dumps incoming messages to the service’s logs.

   1. Copy the example YAML into a file named service.yaml:

      apiVersion: serving.knative.dev/v1
      kind: Service
      metadata:
        name: event-display
      spec:
        template:
          spec:
            containers:
              - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest

   2. Apply the service.yaml file:

      $ oc apply --filename service.yaml

2. For each set of ping events that you want to request, create a PingSource object in the same namespace as the event consumer.

   1. Copy the example YAML into a file named ping-source.yaml:

      apiVersion: sources.knative.dev/v1alpha2
      kind: PingSource
      metadata:
        name: test-ping-source
      spec:
        schedule: "*/2 * * * *"
        jsonData: '{"message": "Hello world!"}'
        sink:
          ref:
            apiVersion: serving.knative.dev/v1
            kind: Service
            name: event-display

   2. Apply the ping-source.yaml file:

      $ oc apply --filename ping-source.yaml

3. Check that the controller is mapped correctly by entering the following command and observing the output:

   $ oc get pingsource.sources.knative.dev test-ping-source -oyaml

   Example output

   apiVersion: sources.knative.dev/v1alpha2
   kind: PingSource
   metadata:
     annotations:
       sources.knative.dev/creator: developer
       sources.knative.dev/lastModifier: developer
     creationTimestamp: "2020-04-07T16:11:14Z"
     generation: 1
     name: test-ping-source
     namespace: default
     resourceVersion: "55257"
     selfLink: /apis/sources.knative.dev/v1alpha2/namespaces/default/pingsources/test-ping-source
     uid: 3d80d50b-f8c7-4c1b-99f7-3ec00e0a8164
   spec:
     jsonData: '{ value: "hello" }'
     schedule: '*/2 * * * *'
     sink:
       ref:
         apiVersion: serving.knative.dev/v1
         kind: Service
         name: event-display
         namespace: default

1. Watch for new pods created:

   $ watch oc get pods

2. Cancel watching the pods using Ctrl+C, then look at the logs of the created pod:

   $ oc logs $(oc get pod -o name | grep event-display) -c user-container

   Example output

   ☁️  cloudevents.Event
   Validation: valid
   Context Attributes,
     specversion: 1.0
     type: dev.knative.sources.ping
     source: /apis/v1/namespaces/default/pingsources/test-ping-source
     id: 042ff529-240e-45ee-b40c-3a908129853e
     time: 2020-04-07T16:22:00.000791674Z
     datacontenttype: application/json
   Data,
     {
       "message": "Hello world!"
     }