Setting up Knative Eventing Resources

Before you start to manage events, you need to create the objects needed to transport the events.

Creating and configuring an Eventing namespace

In this section you create the event-example namespace and then add the knative-eventing-injection label to that namespace. You use namespaces to group together and organize your Knative resources, including the Eventing subcomponents.

This gives the event-example namespace the knative-eventing-injection label, which adds resources that will allow you to manage your events.

In the next section, you will need to verify that the resources you added in this section are running correctly. Then, you can create the rest of the eventing resources you need to manage events.

Validating that the Broker is running

The Broker ensures that every event sent by event producers arrives at the correct event consumers. The Broker was created when you labeled your namespace as ready for eventing, but it is important to verify that your Broker is working correctly. In this guide, you will use the default broker.

Run the following command to verify that the Broker is in a healthy state:

When the Broker has the READY=True state, it can begin to manage any events it receives.

If READY=False, wait 2 minutes and re-run the command. If you continue to receive the READY=False, see the Debugging Guide to help troubleshoot the issue.

Now that your Broker is ready to manage events, you can create and configure your event producers and consumers.

Creating event consumers

Your event consumers receive the events sent by event producers. In this step, you will create two event consumers, hello-display and goodbye-display, to demonstrate how you can configure your event producers to selectively target a specific consumer.

To deploy the hello-display consumer to your cluster, run the following command:

This lists the hello-display and goodbye-display consumers that you deployed:

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
hello-display 1111 26s
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
goodbye-display 1111 16s

The number of replicas in your DESIRED column should match the number of replicas in your AVAILABLE column, which might take a few minutes. If after two minutes the numbers do not match, then see the Debugging Guide to help troubleshoot the issue.

Creating Triggers

A Trigger defines the events that you want each of your event consumers
to receive. Your Broker uses triggers to forward events to the right consumers. Each trigger can specify a filter to select relevant events based on the Cloud Event context attributes.

If the triggers are correctly configured, they will be ready and pointing to the correct Broker (the default broker) and SUBSCRIBER_URI (triggerName.namespaceName.svc.cluster.local). If this is not the case, see the Debugging Guide to help troubleshoot the issue.

You have now created all of the resources needed to receive and manage events. You created the Broker, which manages the events sent to event consumers with the help of triggers. In the next section, you will make the event producer that will be used to create your events.

Creating event producers

In this section you will create an event producer that you can use to interact with the Knative Eventing subcomponents you created earlier. Most events are created systematically, but this guide uses curl to manually send individual events and demonstrate how these events are received by the correct event consumer. Because you can only access the Broker from within your Eventing cluster, you must create a Pod within that cluster to act as your event producer.

In the following step, you will create a Pod that executes your curl commands to send events to the Broker in your Eventing cluster.

Now that you’ve set up your Eventing cluster to send and consume events, you will use HTTP requests to manually send separate events and demonstrate how each of those events can target your individual event consumers in the next section.

Sending Events to the Broker

Now that you’ve created the Pod, you can create an event by sending an HTTP request to the Broker. SSH into the Pod by running the following command:

kubectl --namespace event-example attach curl -it

You have sshed into the Pod, and can now make a HTTP request. A prompt similar to the one below will appear:

Defaulting container name to curl.
Use 'kubectl describe pod/ -n event-example' to see all of the containers in this pod.
If you don't see a command prompt, try pressing enter.
[ root@curl:/ ]$

To show the various types of events you can send, you will make three requests:

To make the first request, which creates an event that has the typegreeting, run the following in the SSH terminal:

You have sent two events to the hello-display event consumer and two events to the goodbye-display event consumer (note that say-hello-goodbye activates the trigger conditions for bothhello-display and goodbye-display). You will verify that these events were received correctly in the next section.

Verifying events were received

After sending events, verify that your events were received by the appropriate Subscribers.

Look at the logs for the hello-display event consumer by running the following command:

Cleaning up

After you finish this guide, delete your namespace to conserve resources if you do not plan to use them.

Note: If you plan to continue learning about Knative Eventing with one of our code samples, check the requirements of the sample and make sure you do not need a namespace before you delete event-example. You can always reuse your namespaces.

Run the following command to delete event-example:

kubectl delete namespace event-example

This removes the namespace and all of its resources from your cluster.

What’s next

You’ve learned the basics of the Knative Eventing workflow. Here are some additional resources to help you continue to build with the Knative Eventing component.