- Documentation
- OpenShift Dedicated
- Serverless
- Eventing
- Brokers
- Kafka broker history bug_report picture_as_pdf
- About
- Introduction to OpenShift Dedicated
- Red Hat OpenShift Cluster Manager
- Planning your environment
- Getting started
- Installing, accessing, and deleting OpenShift Dedicated clusters
- Cluster administration
- Security and compliance
- Authentication and authorization
- Upgrading
- CI/CD
- Add-on services
- Storage
- Registry
- Networking
- Applications
-
Logging
- Release notes
- About Logging
- Installing Logging
- Accessing the service logs
-
Configuring your Logging deployment
- About the Cluster Logging custom resource
- Configuring the logging collector
- Configuring the log store
- Configuring the log visualizer
- Configuring Logging storage
- Configuring CPU and memory limits for Logging components
- Using tolerations to control Logging pod placement
- Moving the Logging resources with node selectors
- Maintenance and support
- Logging with the LokiStack
- Viewing logs for a specific resource
- Viewing cluster logs in Kibana
- Forwarding logs to third party systems
- Enabling JSON logging
- Collecting and storing Kubernetes events
- Updating Logging
- Viewing cluster dashboards
- Troubleshooting Logging
- Uninstalling Logging
- Exported fields
- Monitoring user-defined projects
-
Serverless
- Release notes
- About Serverless
- Installing Serverless
- Knative Serving
-
Eventing
- Knative Eventing
- Event sources
- Event sinks
- Brokers
-
Triggers
- Triggers overview
- Creating triggers from the web console
- Creating triggers from the command line
- Creating a trigger from the Administrator perspective
- List triggers from the command line
- Describe triggers from the command line
- Connecting a trigger to a sink
- Filtering triggers from the command line
- Updating triggers from the command line
- Deleting triggers from the command line
- Channels
- Subscriptions
- Event discovery
- Tuning eventing configuration
- kn-event plugin
-
Functions
- Setting up OpenShift Serverless Functions
- Getting started with functions
- Developing Quarkus functions
- Developing Node.js functions
- Developing TypeScript functions
- Using functions with Knative Eventing
- Function project configuration in func.yaml
- Accessing secrets and config maps from functions
- Adding annotations to functions
- Functions development reference guide
- Knative CLI
- Administer
- Security
- Observability
- Removing Serverless
- Serverless support
- Troubleshooting
Kafka broker
For production-ready Knative Eventing deployments, Red Hat recommends using the Knative Kafka broker implementation. The Kafka broker is an Apache Kafka native implementation of the Knative broker, which sends CloudEvents directly to the Kafka instance.
|
The Federal Information Processing Standards (FIPS) mode is disabled for Kafka broker. |
The Kafka broker has a native integration with Kafka for storing and routing events. This allows better integration with Kafka for the broker and trigger model over other broker types, and reduces network hops. Other benefits of the Kafka broker implementation include:
-
At-least-once delivery guarantees
-
Ordered delivery of events, based on the CloudEvents partitioning extension
-
Control plane high availability
-
A horizontally scalable data plane
The Knative Kafka broker stores incoming CloudEvents as Kafka records, using the binary content mode. This means that all CloudEvent attributes and extensions are mapped as headers on the Kafka record, while the data spec of the CloudEvent corresponds to the value of the Kafka record.
For information about using Kafka brokers, see Creating brokers.