Reference architecture for offering Eventing capabilities in Kubernetes or OpenShift as a platform team using Knative Eventing with Apache Kafka.
This repository is meant to provide guidance on configuring OpenShift operators to offer Eventing capabilities in Kubernetes or OpenShift as a platform team using Knative Eventing with Apache Kafka but resource requests, limits and storage are on the very low-end for demo purposes and to avoid wasting resources during demos.
For production deployments, we recommend revisiting "sizing" related subjects, such as:
- Knative Eventing resource requests, limits, and replicas
- Apache Kafka cluster and Strimzi operators resource requests, limits, storage size, and replicas
- Jaeger resource requests, limits, storage size, and replicas
- Administrator access to an OpenShift cluster
backstage-cli create-github-app keventmesh # Replace `keventmesh` with your org nameand then place the credentials file in the parent directory of this repository in a file
called github-app-backstage-keventmesh-credentials.yaml.
./install.sh./install-demo-resources.shWhen we need to onboard a new namespace to a platform configured following this architecture we need to follow a few steps:
- Create a
KafkaUserto give the project access to the Apache Kafka cluster.- see examples:
- If we've opted to
use Knative's "bring your own topic"
we need to pre-provision all the topics in the Apache Kafka cluster that the project will need
to use.
- see examples:
- Distribute the credentials associated with the previously created
KafkaUserto the user's namespace.- In our case, we configure kluctl to propagate
the secret that Strimzi operator creates in the
Kafkacluster namespace (kafkain our case) to the user's namespace with the Knative Eventing expected secret format
- In our case, we configure kluctl to propagate
the secret that Strimzi operator creates in the