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:
Field | Description | Required or optional |
---|---|---|
ref | This points to an Addressable. | Required if not using uri |
ref.apiVersion | API version of the referent. | Required if using ref |
ref.kind | Kind of the referent. | Required if using ref |
ref.namespace | Namespace of the referent. If omitted this defaults to the object holding it. | Optional |
ref.name | Name of the referent. | Required if using ref |
uri | This can be an absolute URL with a non-empty scheme and non-empty host that points to the target or a relative URI. Relative URIs are resolved using the base URI retrieved from Ref. | Required if not using ref |
Note
At least one of ref
or uri
is required. If both are specified, uri
is resolved into the URL from the Addressable ref
result.
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
Contract
This results in the K_SINK
environment variable being set on the subject
as "http://mysink.default.svc.cluster.local/extra/path"
.
Using custom resources as sinks
To use a Kubernetes custom resource (CR) as a sink for events, you must:
Make the CR Addressable. You must ensure that the CR contains a
status.address.url
. For more information, see the spec for Addressable resources.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 allowget
,list
, andwatch
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.
Tip
You can configure which resources can be used with the --sink
flag for kn
CLI commands by customizing kn.
Supported third-party sink types
Name | Maintainer | Description |
---|---|---|
KafkaSink | Knative | Send events to a Kafka topic |
RedisSink | Knative | Send events to a Redis Stream |