Knative Eventing On-Premises Kubernetes?

My team is working on an eventing implementation for the new platform. Our bread and butter for events and messaging is RabbitMQ. We are early in our journey of this Kubernetes platform and while we were working on yet another set of sidecars for an application. Kerberos for a database authentication mechanism and now a publisher and consumer for RabbitMQ. It remains unclear if we will continue on this path of adding more sidecars. So far users need to opt into these sidecars for their app but linkerd and vault are automatically enabled as sidecars currently.


While implementing eventing one of team members stumbled upon Knative. From the looks of the project and its stability and adoption it seems like a perfect fit. Until I stumbled on what brokers require. Since we operate in an on-premises environment and the platform team is small so far. We have two people that are experts at Kubernetes administration and five general developers. According to this page in order to use the broker functionality of Knative we need to have Kafka or Nats Streaming Server running on the cluster. We are avoiding persistent storage on Kubernetes for as long as possible. The semantics of eventing look intriguing. As a small team we are seeking to avoid unnecessary complexity and burdens caused by technologies like Istio or stateful workloads.

If you are not on-premises or already are a champ at running stateful workloads or have plenty of staff this might not be convincing to you. I love the breadth of the Kubernetes community but it isn’t always clear what the level of commitment to any one technology or implementation requires.