Creating your first Trigger

Creating your first Trigger

kn

  1. kn trigger create cloudevents-trigger --sink cloudevents-player  --broker example-broker
  1. Trigger 'cloudevents-trigger' successfully created in namespace 'default'.

YAML

  1. apiVersion: eventing.knative.dev/v1
  2. kind: Trigger
  3. metadata:
  4.   name: cloudevents-trigger
  5.   annotations:
  6.     knative-eventing-injection: enabled
  7. spec:
  8.   broker: example-broker
  9.   subscriber:
  10.     ref:
  11.       apiVersion: serving.knative.dev/v1
  12.       kind: Service
  13.       name: cloudevents-player

After you’ve created your YAML file, named something like ce-trigger.yaml, apply it by running the command:

  1. kubectl apply -f ce-trigger.yaml

Expected Output

  1. trigger.eventing.knative.dev/cloudevents-trigger created

trigger.eventing.knative.dev/cloudevents-player created

What CloudEvents is my Trigger listening for?

Because we didn’t specify a --filter in our kn command, the Trigger is listening for any CloudEvents coming into the Broker.

The following example shows how to use Filters.

Now, when we go back to the CloudEvents Player and send an Event, we see that CloudEvents are both sent and received by the CloudEvents Player:

Creating your first Trigger - 图1

You may need to refresh the page to see your changes

What if I want to filter on CloudEvent attributes?

First, delete your existing Trigger:

  1.   kn trigger delete cloudevents-player

Now let’s add a Trigger that listens for a certain CloudEvent Type

  1.   kn trigger create cloudevents-player-filter --sink cloudevents-player  --broker example-broker --filter type=some-type

If you send a CloudEvent with type “some-type,” it is reflected in the CloudEvents Player UI. The Trigger ignores any other types.

You can filter on any aspect of the CloudEvent you would like to.

Some people call this “Event-Driven Architecture” which can be used to create your own “Functions as a Service” on Kubernetes 🎉 🌮 🔥