TriggerMesh and Knative
TriggerMesh depends on Knative Serving to run on Kubernetes, but Knative Eventing is optional. You can either use the provided, self-contained TriggerMesh eventing components which are the Broker and their Triggers, or you can choose to use Knative Eventing Brokers and Triggers. By default, TriggerMesh installations will use the new TriggerMesh Broker and Trigger, whether locally with
tmctl or on Kubernetes.
Why does TriggerMesh need Knative Serving on Kubernetes?
TriggerMesh sources and targets use Knative Serving to run as addressable services and to scale.
How to use TriggerMesh with Knative Eventing?
If you want to, you can use the Brokers and Triggers from Knative Eventing instead of those provided by TriggerMesh.
To do this, you'll want to avoid installing the TriggerMesh Brokers and Triggers on Kubernetes, and instead install Knative Eventing.
First you'll need to have Knative Eventing and Serving installed on your cluster.
Install the CRDs
All TriggerMesh APIs are implemented as Kubernetes CRDs, which we need to create before deploying the controller. The following
kubectl apply command will create all of the CRDs. We're intentionally omitting
Install the controllers
By default, the controllers are deployed in the
triggermesh namespace. Deploy the controllers with the following
kubectl apply command. We're intentionally omitting
Add the TriggerMesh chart repository to Helm:
To install the chart with the release name
This command specifically omits
triggermesh-core, so that is doesn't install the TriggerMesh Brokers and Triggers.
tmctl with Knative
tmctl, you can run
tmctl dump --knative which will export a Kubernetes manifest that uses the Knative Eventing Brokers and Triggers instead of those provided by TriggerMesh.