In a previous article, I covered [how to create a small app with Knative][2], which is an open source project that adds components to [Kubernetes][3] for deploying, running, and managing [serverless, cloud-native][4] applications. In this article, I'll explain Knative eventing, a way to create, send, and verify events in your cloud-native environment.
Events can be generated from many sources in your environment, and they can be confusing to manage or define. Since Knative follows the [CloudEvents][5] specification, it allows you to have one common abstraction point for your environment, where the events are defined to one specification.
This article explains how to install Knative eventing version 0.20.0 and create, trigger, and verify events. Because there are many steps involved, I suggest you look at my [GitHub repo][6] to walk through this article with the files.
### Set up your configuration
This walkthrough uses [Minikube][7] with Kubernetes 1.19.0. It also makes some configuration changes to the Minikube environment.
**Minikube pre-configuration commands:**
```
$ minikube config set kubernetes-version v1.19.0
$ minikube config set memory 4000
$ minikube config set cpus 4
```
Before starting Minikube, run the following commands to make sure your configuration stays and start Minikube:
```
$ minikube delete
$ minikube start
```
### Install Knative eventing
Install the Knative eventing custom resource definitions (CRDs) using kubectl. The following shows the command and a snippet of the output:
clusterrole.rbac.authorization.k8s.io/knative-eventing-mt-channel-broker-controller created
clusterrole.rbac.authorization.k8s.io/knative-eventing-mt-broker-filter created
```
Next, create a namespace and add a small broker to it; this broker routes events to triggers. Create your namespace using kubectl:
```
$ kubectl create namespace eventing-test
namespace/eventing-test created
```
Now create a small broker named `default` in your namespace. The following is the YAML from my **broker.yaml** file (which can be found in my GitHub repository):
```
apiVersion: eventing.knative.dev/v1
kind: broker
metadata:
name: default
namespace: eventing-test
```
Then apply your broker file using kubectl:
```
$ kubectl create -f broker.yaml
broker.eventing.knative.dev/default created
```
Verify that everything is up and running (you should see the confirmation output) after you run the command:
You'll need this URL from the broker output later for sending events, so save it.
### Create event consumers
Now that everything is installed, you can start configuring the components to work with events.
First, you need to create event consumers. You'll create two consumers in this walkthrough: **hello-display** and **goodbye-display**. Having two consumers allows you to see how to target a consumer per event message.
The differences in the YAML between the two consumers are in the `app` and `metadata name` sections. While both consumers are on the same ports, you can target one when generating an event. Create the consumers using kubectl:
Check to make sure the deployments are running after you've applied the YAML files:
```
$ kubectl -n eventing-test get deployments hello-display goodbye-display
NAME READY UP-TO-DATE AVAILABLE AGE
hello-display 1/1 1 1 2m4s
goodbye-display 1/1 1 1 34s
```
### Create triggers
Now, you need to create the triggers, which define the events the consumer receives. You can define triggers to use any filter from your cloud events. The broker receives events from the trigger and sends the events to the correct consumer. This set of examples creates two triggers with different definitions. For example, you can send events with the attribute type `greeting` to the `hello-display` consumer.
**The greeting-trigger.yaml code:**
```
apiVersion: eventing.knative.dev/v1
kind: Trigger
metadata:
name: hello-display
spec:
broker: default
filter:
attributes:
type: greeting
subscriber:
ref:
apiVersion: v1
kind: Service
name: hello-display
```
To create the first trigger, apply your YAML file:
trigger.eventing.knative.dev/hello-display created
```
Next, make the second trigger using **sendoff-trigger.yaml**. This sends anything with the attribute `source sendoff` to your `goodbye-display` consumer.
**The sendoff-trigger.yaml code:**
```
apiVersion: eventing.knative.dev/v1
kind: Trigger
metadata:
name: goodbye-display
spec:
broker: default
filter:
attributes:
source: sendoff
subscriber:
ref:
apiVersion: v1
kind: Service
name: goodbye-display
```
Next, apply your second trigger definition to the cluster:
Create a pod you can use to send events. This is a simple pod deployment with curl and SSH access for you to [send events using curl][8]. Because the broker can be accessed only from inside the cluster where Knative eventing is installed, the pod needs to be in the cluster; this is the only way to send events into the cluster. Use the **event-producer.yaml** file with this code:
To verify, get the deployment and make sure the pod is up and running:
```
$ kubectl get pods -n eventing-test
NAME READY STATUS RESTARTS AGE
curl 1/1 Running 0 8m13s
```
### Send some events
Since this article has been so configuration-heavy, I imagine you'll be happy to finally be able to send some events and test out your services. Events have to be passed internally in the cluster. Usually, events would be defined around applications internal to the cluster and come from those applications. But this example will manually send events from your pod named **curl**.
Use 'kubectl describe pod/curl -n eventing-test' to see all of the containers in this pod.
If you don't see a command prompt, try pressing enter.
[ root@curl:/ ]$
```
Now, generate an event using curl. This needs some extra definitions and requires the broker URL generated during the installation. This example sends a greeting to the broker:
`Ce` is short for CloudEvent, which is the [standardized CloudEvents specification][9]that Knative follows.You also need to know the event ID (this is useful to verify it was delivered), the type, the source (which must specify that it is not a `sendoff` so that it doesn't go to the source defined in the sendoff trigger), and a message.
When you run the command, this should be the output (and you should receive a [202 Accepted][10]response):
This time, it is a `sendoff` and not a greeting based on the previous setup section's trigger definition. It is directed to the **goodbye-display** consumer.
Your output should look like this, with another 202 returned:
You've confirmed the **hello-display** consumer received the event! Now check the **goodbye-display** consumer and make sure the other message made it.
Start by running the same command but with **goodbye-display**:
It looks like both events made it to their proper locations. Congratulations—you have officially worked with Knative eventing!
### Bonus round: Send an event to multiple consumers
So you sent events to each consumer using curl, but what if you want to send an event to both consumers? This uses a similar curl command but with some interesting changes. In the previous triggers, each one was defined with a different attribute. The greeting trigger had attribute `type`, and sendoff trigger had attribute `source`. This means you can make a curl call and send it to both consumers.
Here is a curl example of a definition for sending an event to both consumers:
As you can see, the event went to both consumers based on your curl definition. If an event needs to be sent to more than one place, you can write definitions to send it to more than one consumer.
### Give it a try!
Internal eventing in cloud events is pretty easy to track if it's going to a predefined location of your choice. Enjoy seeing how far you can go with eventing in your cluster!
