Knative Cookbook

Chapter 4. Knative Eventing

In this chapter, we present recipes that will help you get started with Knative Eventing. We will start with a high-level overview of the usage patterns and then drill down into specific steps to connect the various components together into end-to-end working examples.

As previously described in Chapter 1, Knative has two major subprojects: Serving and Eventing. With Serving you have dynamic autoscaling, including scaling down to zero pods, based on the absence of HTTP traffic load. With Eventing, you now have that same autoscaling capability but bridged into other protocols or from other sources beyond HTTP. For example, a barrage of messages flowing through an Apache Kafka topic can cause autoscaling of your Kubernetes-based service to handle those messages. Or perhaps a scheduled event via cron can cause your service to awake from its slumber and perform its duties.

CloudEvents

CloudEvents is a specification for describing event data in a common way. An event might be produced by any number of sources (e.g., Kafka, S3, GCP PubSub, MQTT), and as a software developer, you want a common abstraction for all event inputs.

Usage Patterns

There are three primary usage patterns with Knative Eventing:

Source to Sink

Source to Sink provides the simplest getting started experience with Knative Eventing. It provides single Sink—that is, event receiving service—with no queuing, backpressure, and filtering. Source to Sink does not support replies, which means ...