Using Triggers

A trigger represents a desire to subscribe to events from a specific broker.

The subscriber value must be a Destination.

Example Triggers

The following trigger receives all the events from the default broker and delivers them to the Knative Serving service my-service:

  1. Create a YAML file using the following example:

    1. apiVersion: eventing.knative.dev/v1
    2. kind: Trigger
    3. metadata:
    4.   name: my-service-trigger
    5. spec:
    6.   broker: default
    7.   subscriber:
    8.     ref:
    9.       apiVersion: serving.knative.dev/v1
    10.       kind: Service
    11.       name: my-service

  2. Apply the YAML file by running the command:

    1. kubectl apply -f <filename>.yaml

    Where <filename> is the name of the file you created in the previous step.

The following trigger receives all the events from the default broker and delivers them to the custom path /my-custom-path for the Kubernetes service my-service:

  1. Create a YAML file using the following example:

    1. apiVersion: eventing.knative.dev/v1
    2. kind: Trigger
    3. metadata:
    4.   name: my-service-trigger
    5. spec:
    6.   broker: default
    7.   subscriber:
    8.     ref:
    9.       apiVersion: v1
    10.       kind: Service
    11.       name: my-service
    12.     uri: /my-custom-path

  2. Apply the YAML file by running the command:

    1. kubectl apply -f <filename>.yaml

    Where <filename> is the name of the file you created in the previous step.

Trigger filtering

Exact match filtering on any number of CloudEvents attributes as well as extensions are supported. If your filter sets multiple attributes, an event must have all of the attributes for the trigger to filter it. Note that we only support exact matching on string values.

Example

This example filters events from the default broker that are of type dev.knative.foo.bar and have the extension myextension with the value my-extension-value.

  1. Create a YAML file using the following example:

    1. apiVersion: eventing.knative.dev/v1
    2. kind: Trigger
    3. metadata:
    4.   name: my-service-trigger
    5. spec:
    6.   broker: default
    7.   filter:
    8.     attributes:
    9.       type: dev.knative.foo.bar
    10.       myextension: my-extension-value
    11.   subscriber:
    12.     ref:
    13.       apiVersion: serving.knative.dev/v1
    14.       kind: Service
    15.       name: my-service

  2. Apply the YAML file by running the command:

    1. kubectl apply -f <filename>.yaml

    Where <filename> is the name of the file you created in the previous step.

Trigger annotations

You can modify a Trigger’s behavior by setting the following two annotations:

  • eventing.knative.dev/injection: if set to enabled, Eventing automatically creates a Broker for a Trigger if it doesn’t exist. The Broker is created in the namespace where the Trigger is created. This annotation only works if you have the Sugar Controller enabled, which is optional and not enabled by default.
  • knative.dev/dependency: this annotation is used to mark the sources that the Trigger depends on. If one of the dependencies is not ready, the Trigger will not be ready.

The following YAML is an example of a Trigger with a dependency:

  1. apiVersion: eventing.knative.dev/v1
  2. kind: Trigger
  3. metadata:
  4.   name: my-service-trigger
  5.   annotations:
  6.     knative.dev/dependency: '{"kind":"PingSource","name":"test-ping-source","apiVersion":"sources.knative.dev/v1"}'
  7. spec:
  8.   broker: default
  9.   filter:
  10.     attributes:
  11.       type: dev.knative.foo.bar
  12.       myextension: my-extension-value
  13.     subscriber:
  14.       ref:
  15.         apiVersion: serving.knative.dev/v1
  16.         kind: Service
  17.         name: my-service