About sinks¶

When you create an event source, you can specify a sink where events are sent to from the source. A sink is an Addressable or a Callable resource that can receive incoming events from other resources. Knative Services, Channels, and Brokers are all examples of sinks.

Addressable objects receive and acknowledge an event delivered over HTTP to an address defined in their status.address.url field. As a special case, the core Kubernetes Service object also fulfils the Addressable interface.

Callable objects are able to receive an event delivered over HTTP and transform the event, returning 0 or 1 new events in the HTTP response. These returned events may be further processed in the same way that events from an external event source are processed.

Sink as a parameter¶

Sink is used as a reference to an object that resolves to a URI to use as the sink.

A sink definition supports the following fields:

Sink parameter example¶

Given the following YAML, if ref resolves into "http://mysink.default.svc.cluster.local", then uri is added to this resulting in "http://mysink.default.svc.cluster.local/extra/path".

apiVersion: sources.knative.dev/v1
kind: SinkBinding
metadata:
  name: bind-heartbeat
spec:
  ...
  sink:
    ref:
      apiVersion: v1
      kind: Service
      namespace: default
      name: mysink
    uri: /extra/path

Using custom resources as sinks¶

To use a Kubernetes custom resource (CR) as a sink for events, you must:

1. Make the CR Addressable. You must ensure that the CR contains a status.address.url. For more information, see the spec for Addressable resources.

2. Create an Addressable-resolver ClusterRole to obtain the necessary RBAC rules for the sink to receive events.

   For example, you can create a kafkasinks-addressable-resolver ClusterRole to allow get, list, and watch access to KafkaSink objects and statuses:

   kind: ClusterRole
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: kafkasinks-addressable-resolver
     labels:
       kafka.eventing.knative.dev/release: devel
       duck.knative.dev/addressable: "true"
   # Do not use this role directly. These rules will be added to the "addressable-resolver" role.
   rules:
     - apiGroups:
         - eventing.knative.dev
       resources:
         - kafkasinks
         - kafkasinks/status
       verbs:
         - get
         - list
         - watch
   

Filtering events sent to sinks by using Triggers¶

You can connect a Trigger to a sink, so that events are filtered before they are sent to the sink. A sink that is connected to a Trigger is configured as a subscriber in the Trigger resource spec.

For example:

apiVersion: eventing.knative.dev/v1
kind: Trigger
metadata:
  name: <trigger-name>
spec:
...
  subscriber:
    ref:
      apiVersion: eventing.knative.dev/v1alpha1
      kind: KafkaSink
      name: <kafka-sink-name>

Where;

• <trigger-name> is the name of the Trigger being connected to the sink.
• <kafka-sink-name> is the name of a KafkaSink object.

Specifying sinks using the kn CLI --sink flag¶

When you create an event-producing CR by using the Knative (kn) CLI, you can specify a sink where events are sent to from that resource, by using the --sink flag.

The following example creates a SinkBinding that uses a Service, http://event-display.svc.cluster.local, as the sink:

kn source binding create bind-heartbeat \
  --namespace sinkbinding-example \
  --subject "Job:batch/v1:app=heartbeat-cron" \
  --sink http://event-display.svc.cluster.local \
  --ce-override "sink=bound"

The svc in http://event-display.svc.cluster.local determines that the sink is a Knative Service. Other default sink prefixes include Channel and Broker.

Supported third-party sink types¶