Event Sources are the components that receive the external events and forward them onto Sinks.
Note : kn doesn't have Knative Eventing implemented yet. So we will be using yaml files for now.
Different types of event sources are possible that are listed here. In this example we will add an event source to test Direct delivery.
Direct delivery from a source to a single Service (an Addressable endpoint, including a Knative Service or a core Kubernetes Service). In this case, the Source is responsible for retrying or queueing events if the destination Service is not available.
- Knative Eventing is installed
- You have a Knative service deployed. Add a knative service running
kn service create msgtxr-sl --image=image-registry.openshift-image-registry.svc:5000/kn-demo/msgtxr -l app.openshift.io/runtime=quarkus --env format=none
Let us create an event source based on a PingSource that generates an event every 1 minute. In this example,we will use our previously deployed application as the sink.
kn source ping create msgtxr-pingsource \
--schedule="* * * * *" \
--data="This message is from PingSource" \
--sink svc:msgtxr-sl
Ping source 'msgtxr-pingsource' created in namespace 'kn-demo'.
Alternately you can also add this from developer console by choosing ADD button on the left menu
- Event Sources tile
- Selecting Ping Source and filling in rest of the details and pressing on Create button
You can confirm the source is created by running
$ kn source ping list
NAME SCHEDULE SINK AGE CONDITIONS READY REASON
msgtxr-pingsource * * * * * svc:msgtxr-sl 4m30s 6 OK / 6 True
Now, the PingSource is set up to send events to the knative service and you will observe that the pod is up and running.
$ oc get po | grep Running
pingsource-msgtxr-pingsour-48373f6a-da18-4484-b309-2b88c29bjcg6 1/1 Running 0 31s
In about a minute, you will notice two pods running :
- PingEventSource will run as a pod
- Knative service for our application is a separate pod.
% oc get po | grep Running
msgtxr-sl-fzpfp-1-deployment-d55996b47-r4n52 2/2 Running 0 4m54s
pingsource-msgtxr-pingsour-48373f6a-da18-4484-b309-2b88c29bjcg6 1/1 Running 0 5m25s
and with this view in the developer console
Note the application's pod name. You can watch the logs for the application to verify that the app is being called continuously by running
oc logs -f $(oc get po | grep msgtxr-sl | awk '{print $1}') -c user-container
and you should see logs like below:
__ ____ __ _____ ___ __ ____ ______
--/ __ \/ / / / _ | / _ \/ //_/ / / / __/
-/ /_/ / /_/ / __ |/ , _/ ,< / /_/ /\ \
--\___\_\____/_/ |_/_/|_/_/|_|\____/___/
2020-05-14 04:16:07,134 INFO [io.quarkus] (main) getting-started 1.0-SNAPSHOT (powered by Quarkus 1.3.2.Final) started in 0.010s. Listening on: http://0.0.0.0:8080
2020-05-14 04:16:07,134 INFO [io.quarkus] (main) Profile prod activated.
2020-05-14 04:16:07,134 INFO [io.quarkus] (main) Installed features: [cdi, resteasy]
04:16:07.868 IN {"body":"This message is from PingSource"} OUT {"body":"This message is from PingSource"}
04:17:00.007 IN {"body":"This message is from PingSource"} OUT {"body":"This message is from PingSource"}
04:18:00.006 IN {"body":"This message is from PingSource"} OUT {"body":"This message is from PingSource"}
...
...
You will notice from the logs that the events coming in every 1 minute from the cron job.
Delete the event source
% kn source ping delete msgtxr-pingsource
Ping source 'msgtxr-pingsource' deleted in namespace 'kn-demo'.
This should remove the event source pod. In a minute or so, the application pod should scale down to 0.
We saw a simple example of a direct event source in this lab.