Knative Eventing orchestrates events from inside or outside a Kubernetes cluster, routes them through event-mesh resources, and delivers them to Knative or Kubernetes Services. It supports predefined integrations and custom event sources while scaling event-driven containers from a few events to sustained streams. section 9.3.3
Decompose an Eventing pipeline into these responsibilities:
- Event sources send events to a Broker and act as the control-plane integration for external systems. section 9.3.3
- A Broker provides the event mesh that receives or pulls events and makes them available for routing. section 9.3.3
- Triggers filter Broker events by CloudEvents attributes and route matching events to subscribers. section 9.3.3
- Controllers reconcile these resources from Kubernetes custom resource definitions, while the messaging layer can use memory or persistent storage. section 9.3.3
Route a Cloud Pub/Sub event
Deploy a CloudPubSubSource for the testing topic and point its sink at an event-display Service. A Trigger can then select events by type and source from the default Broker and deliver them to a named Service. This separates source integration, filtering, and application delivery instead of embedding event handling in the service.
Install Eventing on a Kubernetes cluster by applying its CRDs, core components, default channel layer, Broker layer, and optional source extensions. YAML files or an operator support installations across managed and on-premises Kubernetes environments. Choose a cluster deployment when portability, direct infrastructure access, custom hardware, or service-mesh integration outweighs the operational simplicity of fully managed Cloud Run. section 9.3.5
