Create a SinkBinding¶
This topic describes how to create a SinkBinding object.
SinkBinding resolves a sink as a URI, sets the URI in the environment
variable K_SINK
, and adds the URI to a subject using K_SINK
.
If the URI changes, SinkBinding updates the value of K_SINK
.
In the following examples, the sink is a Knative Service and the subject is a CronJob. If you have an existing subject and sink, you can replace the examples with your own values.
Before you begin¶
Before you can create a SinkBinding object:
- You must have Knative Eventing installed on your cluster.
- Optional: If you want to use
kn
commands with SinkBinding, install thekn
CLI.
Optional: Choose SinkBinding namespace selection behavior¶
The SinkBinding object operates in one of two modes: exclusion
or inclusion
.
The default mode is exclusion
.
In exclusion mode, SinkBinding behavior is enabled for the namespace by default.
To disallow a namespace from being evaluated for mutation you must exclude it
using the label bindings.knative.dev/exclude: true
.
In inclusion mode, SinkBinding behavior is not enabled for the namespace.
Before a namespace can be evaluated for mutation, you must
explicitly include it using the label bindings.knative.dev/include: true
.
To set the SinkBinding object to inclusion mode:
-
Change the value of
SINK_BINDING_SELECTION_MODE
fromexclusion
toinclusion
by running:kubectl -n knative-eventing set env deployments eventing-webhook --containers="eventing-webhook" SINK_BINDING_SELECTION_MODE=inclusion
-
To verify that
SINK_BINDING_SELECTION_MODE
is set as desired, run:kubectl -n knative-eventing set env deployments eventing-webhook --containers="eventing-webhook" --list | grep SINK_BINDING
Create a namespace¶
If you do not have an existing namespace, create a namespace for the SinkBinding object:
kubectl create namespace <namespace>
<namespace>
is the namespace that you want your SinkBinding to use.
For example, sinkbinding-example
.
Note
If you have selected inclusion mode, you must add the
bindings.knative.dev/include: true
label to the namespace to enable
SinkBinding behavior.
Create a sink¶
The sink can be any addressable Kubernetes object that can receive events.
If you do not have an existing sink that you want to connect to the SinkBinding object, create a Knative service.
Note
To create a Knative service you must have Knative Serving installed on your cluster.
Create a Knative service by running:
kn service create <app-name> --image <image-url>
<app-name>
is the name of the application.<image-url>
is the URL of the image container.
For example:
$ kn service create event-display --image gcr.io/knative-releases/knative.dev/eventing/cmd/event_display
-
Create a YAML file for the Knative service using the following template:
Where:apiVersion: serving.knative.dev/v1 kind: Service metadata: name: <app-name> spec: template: spec: containers: - image: <image-url>
<app-name>
is the name of the application. For example,event-display
.<image-url>
is the URL of the image container. For example,gcr.io/knative-releases/knative.dev/eventing/cmd/event_display
.
-
Apply the YAML file by running the command:
Wherekubectl apply -f <filename>.yaml
<filename>
is the name of the file you created in the previous step.
Create a subject¶
The subject must be a PodSpecable resource. You can use any PodSpecable resource in your cluster, for example:
Deployment
Job
DaemonSet
StatefulSet
Service.serving.knative.dev
If you do not have an existing PodSpecable subject that you want to use, you can
use the following sample to create a CronJob object as the subject.
The following CronJob makes a single cloud event that targets K_SINK
and adds
any extra overrides given by CE_OVERRIDES
.
-
Create a YAML file for the CronJob using the following example:
apiVersion: batch/v1 kind: CronJob metadata: name: heartbeat-cron spec: # Run every minute schedule: "*/1 * * * *" jobTemplate: metadata: labels: app: heartbeat-cron spec: template: spec: restartPolicy: Never containers: - name: single-heartbeat image: gcr.io/knative-nightly/knative.dev/eventing/cmd/heartbeats args: - --period=1 env: - name: ONE_SHOT value: "true" - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace
-
Apply the YAML file by running the command:
Wherekubectl apply -f <filename>.yaml
<filename>
is the name of the file you created in the previous step.
Create a SinkBinding object¶
Create a SinkBinding
object that directs events from your subject to the sink.
Create a SinkBinding
object by running:
kn source binding create <name> \
--namespace <namespace> \
--subject "<subject>" \
--sink <sink> \
--ce-override "<cloudevent-overrides>"
<name>
is the name of the SinkBinding object you want to create.<namespace>
is the namespace you created for your SinkBinding to use.<subject>
is the subject to connect. Examples:Job:batch/v1:app=heartbeat-cron
matches all jobs in namespace with labelapp=heartbeat-cron
.Deployment:apps/v1:myapp
matches a deployment calledmyapp
in the namespace.Service:serving.knative.dev/v1:hello
matches the service calledhello
.
<sink>
is the sink to connect. For examplehttp://event-display.svc.cluster.local
.- Optional:
<cloudevent-overrides>
in the formkey=value
. Cloud Event overrides control the output format and modifications of the event sent to the sink and are applied before sending the event. You can provide this flag multiple times.
For a list of available options, see the Knative client documentation.
For example:
$ 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"
-
Create a YAML file for the
SinkBinding
object using the following template:Where:apiVersion: sources.knative.dev/v1 kind: SinkBinding metadata: name: <name> spec: subject: apiVersion: <api-version> kind: <kind> selector: matchLabels: <label-key>: <label-value> sink: ref: apiVersion: serving.knative.dev/v1 kind: Service name: <sink>
<name>
is the name of the SinkBinding object you want to create. For example,bind-heartbeat
.<api-version>
is the API version of the subject. For examplebatch/v1
.<kind>
is the Kind of your subject. For exampleJob
.<label-key>: <label-value>
is a map of key-value pairs to select subjects that have a matching label. For example,app: heartbeat-cron
selects any subject with the labelapp=heartbeat-cron
.<sink>
is the sink to connect. For exampleevent-display
.
For more information about the fields you can configure for the SinkBinding object, see Sink Binding Reference.
-
Apply the YAML file by running the command:
Wherekubectl apply -f <filename>.yaml
<filename>
is the name of the file you created in the previous step.
Verify the SinkBinding object¶
-
Verify that a message was sent to the Knative eventing system by looking at the service logs for your sink:
Where:kubectl logs -l <sink> -c <container> --since=10m
<sink>
is the name of your sink.<container>
is the name of the container your sink is running in.
For example:
$ kubectl logs -l serving.knative.dev/service=event-display -c user-container --since=10m
-
From the output, observe the lines showing the request headers and body of the event message, sent by the source to the display function. For example:
☁️ cloudevents.Event Validation: valid Context Attributes, specversion: 1.0 type: dev.knative.eventing.samples.heartbeat source: https://knative.dev/eventing-contrib/cmd/heartbeats/#default/heartbeat-cron-1582120020-75qrz id: 5f4122be-ac6f-4349-a94f-4bfc6eb3f687 time: 2020-02-19T13:47:10.41428688Z datacontenttype: application/json Extensions, beats: true heart: yes the: 42 Data, { "id": 1, "label": "" }
Delete a SinkBinding¶
To delete the SinkBinding object and all of the related resources in the namespace, delete the namespace by running:
kubectl delete namespace <namespace>
<namespace>
is the name of the namespace that contains the SinkBinding object.