Skip to content

Commit 1c0a2f2

Browse files
grantrknative-prow-robot
authored andcommitted
Add Broker/Trigger docs from eventing repo (#1279)
* Add Broker/Trigger docs from eventing repo Mostly a copy of github.com/knative/eventing/docs/broker/README.md, but with a new intro and without the Implementation section. * Update wording based on feedback * Add title yaml and remove errant apostrophe
1 parent f1174b1 commit 1c0a2f2

File tree

1 file changed

+277
-0
lines changed

1 file changed

+277
-0
lines changed

docs/eventing/broker-trigger.md

Lines changed: 277 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,277 @@
1+
---
2+
title: "Broker and Trigger"
3+
weight: 20
4+
type: "docs"
5+
---
6+
7+
Broker and Trigger are CRDs providing an event delivery mechanism that hides the
8+
details of event routing from the event producer and event consumer.
9+
10+
## Broker
11+
12+
A Broker represents an 'event mesh'. Events are sent to the Broker's ingress and
13+
are then sent to any subscribers that are interested in that event. Once inside
14+
a Broker, all metadata other than the CloudEvent is stripped away (e.g. unless
15+
set as a CloudEvent attribute, there is no concept of how this event entered the
16+
Broker).
17+
18+
Example:
19+
20+
```yaml
21+
apiVersion: eventing.knative.dev/v1alpha1
22+
kind: Broker
23+
metadata:
24+
name: default
25+
spec:
26+
channelTemplate:
27+
provisioner:
28+
apiVersion: eventing.knative.dev/v1alpha1
29+
kind: ClusterChannelProvisioner
30+
name: gcp-pubsub
31+
```
32+
33+
## Trigger
34+
35+
A Trigger represents a desire to subscribe to events from a specific Broker. Basic
36+
filtering on the type and source of events is provided.
37+
38+
Example:
39+
40+
```yaml
41+
apiVersion: eventing.knative.dev/v1alpha1
42+
kind: Trigger
43+
metadata:
44+
name: my-service-trigger
45+
spec:
46+
filter:
47+
sourceAndType:
48+
type: dev.knative.foo.bar
49+
subscriber:
50+
ref:
51+
apiVersion: serving.knative.dev/v1alpha1
52+
kind: Service
53+
name: my-service
54+
```
55+
56+
## Usage
57+
58+
### ClusterChannelProvisioner
59+
60+
`Broker`s use their `spec.channelTemplate` to create their internal `Channel`s,
61+
which dictate the durability guarantees of events sent to that `Broker`. If
62+
`spec.channelTemplate` is not specified, then the
63+
[default provisioner](https://www.knative.dev/docs/eventing/channels/default-channels/)
64+
for their namespace is used.
65+
66+
#### Setup
67+
68+
Have a `ClusterChannelProvisioner` installed and set as the
69+
[default provisioner](https://www.knative.dev/docs/eventing/channels/default-channels/)
70+
for the namespace you are interested in. For development, the
71+
[`in-memory` `ClusterChannelProvisioner`](https://github.com/knative/eventing/tree/master/config/provisioners/in-memory-channel#deployment-steps)
72+
is normally used.
73+
74+
#### Changing
75+
76+
**Note** changing the `ClusterChannelProvisioner` of a running `Broker` will
77+
lose all in-flight events.
78+
79+
If you want to change which `ClusterChannelProvisioner` is used by a given
80+
`Broker`, then determine if the `spec.channelTemplate` is specified or not.
81+
82+
If `spec.channelTemplate` is specified:
83+
84+
1. Delete the `Broker`.
85+
1. Create the `Broker` with the updated `spec.channelTemplate`.
86+
87+
If `spec.channelTemplate` is not specified:
88+
89+
1. Change the
90+
[default provisioner](https://github.com/knative/docs/blob/master/docs/eventing/channels/default-channels.md#setting-the-default-channel-configuration)
91+
for the namespace that `Broker` is in.
92+
1. Delete and recreate the `Broker`.
93+
94+
### Broker
95+
96+
There are two ways to create a Broker:
97+
98+
* [namespace annotation](#annotation)
99+
* [manual setup](#manual-setup)
100+
101+
Normally the [namespace annotation](#annotation) is used to do this setup.
102+
103+
#### Annotation
104+
105+
The easiest way to get started, is to annotate your namespace (replace `default`
106+
with the desired namespace):
107+
108+
```shell
109+
kubectl label namespace default knative-eventing-injection=enabled
110+
```
111+
112+
This should automatically create a `Broker` named `default` in the `default`
113+
namespace.
114+
115+
```shell
116+
kubectl -n default get broker default
117+
```
118+
119+
#### Manual Setup
120+
121+
In order to setup a `Broker` manually, we must first create the required
122+
`ServiceAccount` and give it the proper RBAC permissions. This setup is required
123+
once per namespace. These instructions will use the `default` namespace, but you
124+
can replace it with any namespace you want to install a `Broker` into.
125+
126+
Create the `ServiceAccount`.
127+
128+
```shell
129+
kubectl -n default create serviceaccount eventing-broker-filter
130+
```
131+
132+
Then give it the needed RBAC permissions:
133+
134+
```shell
135+
kubectl -n default create rolebinding eventing-broker-filter \
136+
--clusterrole=eventing-broker-filter \
137+
--user=eventing-broker-filter
138+
```
139+
140+
Note that the previous commands uses three different objects, all named
141+
`eventing-broker-filter`. The `ClusterRole` is installed with Knative Eventing
142+
[here](../../config/200-broker-clusterrole.yaml). The `ServiceAccount` was
143+
created two commands prior. The `RoleBinding` is created with this command.
144+
145+
Now we can create the `Broker`. Note that this example uses the name `default`,
146+
but could be replaced by any other valid name.
147+
148+
```shell
149+
cat << EOF | kubectl apply -f -
150+
apiVersion: eventing.knative.dev/v1alpha1
151+
kind: Broker
152+
metadata:
153+
namespace: default
154+
name: default
155+
EOF
156+
```
157+
158+
### Subscriber
159+
160+
Now create a function to receive those events. This document will
161+
assume the following manifest describing a Knative Service is created, but it
162+
could be anything that is `Addressable`.
163+
164+
```yaml
165+
apiVersion: serving.knative.dev/v1alpha1
166+
kind: Service
167+
metadata:
168+
name: my-service
169+
namespace: default
170+
spec:
171+
runLatest:
172+
configuration:
173+
revisionTemplate:
174+
spec:
175+
container:
176+
# This corresponds to
177+
# https://github.com/knative/eventing-sources/blob/v0.2.1/cmd/message_dumper/dumper.go.
178+
image: gcr.io/knative-releases/github.com/knative/eventing-sources/cmd/message_dumper@sha256:ab5391755f11a5821e7263686564b3c3cd5348522f5b31509963afb269ddcd63
179+
```
180+
181+
### Trigger
182+
183+
Create a `Trigger` using the following manifest that sends only events of a
184+
particular type to `my-service`:
185+
186+
```yaml
187+
apiVersion: eventing.knative.dev/v1alpha1
188+
kind: Trigger
189+
metadata:
190+
name: my-service-trigger
191+
namespace: default
192+
spec:
193+
filter:
194+
sourceAndType:
195+
type: dev.knative.foo.bar
196+
subscriber:
197+
ref:
198+
apiVersion: serving.knative.dev/v1alpha1
199+
kind: Service
200+
name: my-service
201+
```
202+
203+
#### Defaulting
204+
205+
The Webhook will default certain unspecified fields. For example if
206+
`spec.broker` is unspecified, it will default to `default`. If
207+
`spec.filter.sourceAndType.type` or `spec.filter.sourceAndType.Source` are
208+
unspecified, then they will default to the special value empty string, which
209+
matches everything.
210+
211+
The Webhook will default the YAML above to:
212+
213+
```yaml
214+
apiVersion: eventing.knative.dev/v1alpha1
215+
kind: Trigger
216+
metadata:
217+
name: my-service-trigger
218+
namespace: default
219+
spec:
220+
broker: default # Defaulted by the Webhook.
221+
filter:
222+
sourceAndType:
223+
type: dev.knative.foo.bar
224+
source: "" # Defaulted by the Webhook.
225+
subscriber:
226+
ref:
227+
apiVersion: serving.knative.dev/v1alpha1
228+
kind: Service
229+
name: my-service
230+
```
231+
232+
You can make multiple `Trigger`s on the same `Broker` corresponding to different
233+
types, sources, and subscribers.
234+
235+
### Source
236+
237+
Now have something emit an event of the correct type (`dev.knative.foo.bar`)
238+
into the `Broker`. We can either do this manually or with a normal Knative
239+
Source.
240+
241+
#### Manual
242+
243+
The `Broker`'s address is well known, it will always be
244+
`<name>-broker.<namespace>.svc.<ending>`. In our case, it is
245+
`default-broker.default.svc.cluster.local`.
246+
247+
While SSHed into a `Pod` and run:
248+
249+
```shell
250+
curl -v "http://default-broker.default.svc.cluster.local/" \
251+
-X POST \
252+
-H "X-B3-Flags: 1" \
253+
-H "CE-CloudEventsVersion: 0.1" \
254+
-H "CE-EventType: dev.knative.foo.bar" \
255+
-H "CE-EventTime: 2018-04-05T03:56:24Z" \
256+
-H "CE-EventID: 45a8b444-3213-4758-be3f-540bf93f85ff" \
257+
-H "CE-Source: dev.knative.example" \
258+
-H 'Content-Type: application/json' \
259+
-d '{ "much": "wow" }'
260+
```
261+
262+
#### Knative Source
263+
264+
Provide the Knative Source the `default` `Broker` as its sink:
265+
266+
```yaml
267+
apiVersion: sources.eventing.knative.dev/v1alpha1
268+
kind: ContainerSource
269+
metadata:
270+
name: heartbeats-sender
271+
spec:
272+
image: github.com/knative/eventing-sources/cmd/heartbeats/
273+
sink:
274+
apiVersion: eventing.knative.dev/v1alpha1
275+
kind: Broker
276+
name: default
277+
```

0 commit comments

Comments
 (0)