Knative Eventing Installed Then What Next?
summary
Quick Start gives an in-memory broker for quick demos but production needs a persistent backend: the demo wires GitHub Source → Kafka Channel → Slack adapter to restore ordering and handle bursts. Configured retries (5 attempts, linear 1s backoff) plus a dead letter sink catch poison‑pill failures; HTTP sources autoscale via Knative Serving while non‑HTTP/messaging consumers require KEDA. High availability uses multiple availability zones and replicated Kafka (Strimzi, IBM Event Streams, OpenShift Streams).
AI-written summary · about
chapters (15)
- 0:00Introduction
- 3:15Quick start limitations
- 5:25Knative Eventing building blocks
- 8:15Event flow mental model
- 12:34Demo: Direct delivery
- 15:11Direct delivery GitHub Slack
- 16:18Kafka Channel ordering
- 18:23Kafka ordering demo
- 19:30Retry policies for errors
- 20:58Poison pills dead letter
- 22:22Dead letter demo production
- 23:28Broker vs Channel
- 25:13Broker demo filtering
- 26:46Key takeaways
- 28:09Q&A
related talks
01h 02mModern Event-Driven Workloads with Knative
48mLet's Go Knative
31mKnative: Is it for me?
48mEvent-driven serverless architectures using Knative and Cloud Run.
27mGoverning the Cloud Native Event Bus: Applying ServiceMesh to Knative Eventing Workshop (Part 2)
44mKnative Serverless to architect decomposed components
38mOverview and State of Knative
32mGetting Started with Knative: The Way to Build Serverless