Chapter 3. Connecting to Knative with Kamelets

You can connect kamelets to Knative destinations (channels or brokers). Red Hat OpenShift Serverless is based on the open source Knative project, which provides portability and consistency across hybrid and multi-cloud environments by enabling an enterprise-grade serverless platform. OpenShift Serverless includes support for the Knative Eventing and Knative Serving components.

Red Hat OpenShift Serverless, Knative Eventing, and Knative Serving enable you to use an event-driven architecture with serverless applications, decoupling the relationship between event producers and consumers by using a publish-subscribe or event-streaming model. Knative Eventing uses standard HTTP POST requests to send and receive events between event producers and consumers. These events conform to the CloudEvents specifications, which enables creating, parsing, sending, and receiving events in any programming language.

You can use kamelets to send CloudEvents to Knative and send them from Knative to event consumers. Kamelets can translate messages to CloudEvents and you can use them to apply any pre-processing and post-processing of the data within CloudEvents.

3.1. Overview of connecting to Knative with kamelets

If you use a Knative stream-processing framework, you can use kamelets to connect services and applications to a Knative destination (channel or broker).

Figure 3.1 illustrates the flow of connecting source and sink kamelets to a Knative destination.

Data flow with kamelets and a Knative destination

Figure 3.1: Data flow with kamelets and a Knative channel

Here is an overview of the basic steps for using kamelets and kamelet bindings to connect applications and services to a Knative destination:

  1. Set up Knative:

    1. Prepare your OpenShift cluster by installing the Camel K and OpenShift Serverless operators.
    2. Install the required Knative Serving and Eventing components.
    3. Create a Knative channel or broker.
  2. Determine which services or applications you want to connect to your Knative channel or broker.
  3. View the Kamelet Catalog to find the kamelets for the source and sink components that you want to add to your integration. Also, determine the required configuration parameters for each kamelet that you want to use.
  4. Create kamelet bindings:

    • Create a kamelet binding that connects a source kamelet to a Knative channel (or broker).
    • Create a kamelet binding that connects the Knative channel (or broker) to a sink kamelet.
  5. Optionally, manipulate the data that is passing between the Knative channel (or broker) and the data source or sink by adding one or more action kamelets as intermediary steps within a kamelet binding.
  6. Optionally, define how to handle errors within a kamelet binding.
  7. Apply the kamelet bindings as resources to the project.

The Camel K operator generates a separate Camel integration for each kamelet binding.

When you configure a kamelet binding to use a Knative channel or a broker as the source of events, the Camel K operator materializes the corresponding integration as a Knative Serving service, to leverage the auto-scaling capabilities offered by Knative.

3.2. Setting up Knative

Setting up Knative involves installing the required OpenShift operators and creating a Knative channel.

3.2.1. Preparing your OpenShift cluster

To use kamelets and OpenShift Serverless, install the following operators, components, and CLI tools:

  • Red Hat Integration - Camel K operator and CLI tool - The operator installs and manages Camel K - a lightweight integration framework that runs natively in the cloud on OpenShift. The kamel CLI tool allows you to access all Camel K features.

    See the installation instructions in Installing Camel K.

  • OpenShift Serverless operator - Provides a collection of APIs that enables containers, microservices, and functions to run "serverless". Serverless applications can scale up and down (to zero) on demand and be triggered by a number of event sources. When you install the OpenShift Serverless operator, it automatically creates the knative-serving namespace (for installing the Knative Serving component) and the knative-eventing namespace (required for installing the Knative Eventing component).
  • Knative Eventing component
  • Knative Serving component
  • Knative CLI tool (kn) - Allows you to create Knative resources from the command line or from within Shell scripts.

3.2.1.1. Installing OpenShift Serverless

You can install the OpenShift Serverless Operator on your OpenShift cluster from the OperatorHub. The OperatorHub is available from the OpenShift Container Platform web console and provides an interface for cluster administrators to discover and install Operators.

The OpenShift Serverless Operator supports both Knative Serving and Knative Eventing features. For more details, see Getting started with OpenShift Serverless.

Prerequisites

  • You have cluster administrator access to an OpenShift project in which the Camel K Operator is installed.
  • You installed the OpenShift CLI tool (oc) so that you can interact with the OpenShift cluster at the command line. For details on how to install the OpenShift CLI, see Installing the OpenShift CLI.

Procedure

  1. In the OpenShift Container Platform web console, log in by using an account with cluster administrator privileges.
  2. In the left navigation menu, click Operators > OperatorHub.
  3. In the Filter by keyword text box, enter Serverless to find the OpenShift Serverless Operator.
  4. Read the information about the Operator and then click Install to display the Operator subscription page.
  5. Select the default subscription settings:

    • Update Channel > Select the channel that matches your OpenShift version, for example, 4.7
    • Installation Mode > All namespaces on the cluster
    • Approval Strategy > Automatic

      Note

      The Approval Strategy > Manual setting is also available if required by your environment.

  6. Click Install, and wait a few moments until the Operator is ready for use.
  7. Install the required Knative components using the steps in the OpenShift documentation:

  8. (Optional) Download and install the OpenShift Serverless CLI tool:

    1. From the Help menu (?) at the top of the OpenShift web console, select Command line tools.
    2. Scroll down to the kn - OpenShift Serverless - Command Line Interface section.
    3. Click the link to download the binary for your local operating system (Linux, Mac, Windows)
    4. Unzip and install the CLI in your system path.
    5. To verify that you can access the kn CLI, open a command window and then type the following:

      kn --help

      This command shows information about OpenShift Serverless CLI commands.

      For more details, see the OpenShift Serverless CLI documentation.

Additional resources

3.2.2. Creating a Knative channel

A Knative channel is a custom resource that forwards events. After events have been sent to a channel from an event source or producer, these events can be sent to multiple Knative services, or other sinks, by using a subscription.

This example uses an InMemoryChannel channel, which you use with OpenShift Serverless for development purposes. Note that InMemoryChannel type channels have the following limitations:

  • No event persistence is available. If a pod goes down, events on that pod are lost.
  • InMemoryChannel channels do not implement event ordering, so two events that are received in the channel at the same time can be delivered to a subscriber in any order.
  • If a subscriber rejects an event, there are no re-delivery attempts by default. You can configure re-delivery attempts by modifying the delivery spec in the Subscription object.

Prerequisites

  • The OpenShift Serverless operator, Knative Eventing, and Knative Serving components are installed on your OpenShift Container Platform cluster.
  • You have installed the OpenShift Serverless CLI (kn).
  • You have created a project or have access to a project with the appropriate roles and permissions to create applications and other workloads in OpenShift Container Platform.

Procedure

  1. Log in to your OpenShift cluster.
  2. Open the project in which you want to create your integration application. For example:

    oc project camel-k-knative

  3. Create a channel by using the Knative (kn) CLI command

    kn channel create <channel_name> --type <channel_type>

    For example, to create a channel named mychannel:

    kn channel create mychannel --type messaging.knative.dev:v1:InMemoryChannel

  4. To confirm that the channel now exists, type the following command to list all existing channels:

    kn channel list

    You should see your channel in the list.

3.2.3. Creating a Knative broker

A Knative broker is a custom resource that defines an event mesh for collecting a pool of CloudEvents. OpenShift Serverless provides a default Knative broker that you can create by using the kn CLI.

You can use a broker in a kamelet binding, for example, when your application handles multiple event types and you do not want to create a channel for each event type.

Prerequisites

  • The OpenShift Serverless operator, Knative Eventing, and Knative Serving components are installed on your OpenShift Container Platform cluster.
  • You have installed the OpenShift Serverless CLI (kn).
  • You have created a project or have access to a project with the appropriate roles and permissions to create applications and other workloads in OpenShift Container Platform.

Procedure

  1. Log in to your OpenShift cluster.
  2. Open the project in which you want to create your integration application. For example:

    oc project camel-k-knative

  3. Create the broker by using this Knative (kn) CLI command:

    kn broker create default

  4. To confirm that the broker now exists, type the following command to list all existing brokers:

    kn broker list

You should see the default broker in the list.

3.3. Connecting a data source to a Knative destination in a kamelet binding

To connect a data source to a Knative destination (channel or broker), you create a kamelet binding as illustrated in Figure 3.2.

Connecting a data source to a Knative destination

Figure 3.2 Connecting a data source to a Knative destination

The Knative destination can be a Knative channel or a Knative broker.

When you send data to a channel, there is only one event type for the channel. You do not need to specify any property values for the channel in a kamelet binding.

When you send data to a broker, because the broker can handle more than one event type, you must specify a value for the type property when you reference the broker in a kamelet binding.

Prerequisites

  • You know the name and type of the Knative channel or broker to which you want to send events.

    The example in this procedure uses the InMemoryChannel channel named mychannel or the broker named default. For the broker example, the type property value is coffee for coffee events.

  • You know which kamelet you want to add to your Camel integration and the required instance parameters.

    The example kamelet for this procedure is the coffee-source kamelet. It has an optional parameter, period, that specifies how often to send each event. You can copy the code from Example source kamelet to a file named coffee-source.kamelet.yaml file and then run the following command to add it as a resource to your namespace:

    oc apply -f coffee-source.kamelet.yaml

Procedure

To connect a data source to a Knative destination, create a kamelet binding:

  1. In an editor of your choice, create a YAML file with the following basic structure:

    apiVersion: camel.apache.org/v1alpha1
    kind: KameletBinding
    metadata:
      name:
    spec:
      source:
      sink:
  2. Add a name for the kamelet binding. For this example, the name is coffees-to-knative because the binding connects the coffee-source kamelet to a Knative destination.

    apiVersion: camel.apache.org/v1alpha1
    kind: KameletBinding
    metadata:
      name: coffees-to-knative
    spec:
      source:
      sink:
  3. For the kamelet binding’s source, specify a data source kamelet (for example, the coffee-source kamelet produces events that contain data about coffee) and configure any parameters for the kamelet.

    apiVersion: camel.apache.org/v1alpha1
    kind: KameletBinding
    metadata:
      name: coffees-to-knative
    spec:
      source:
        ref:
          kind: Kamelet
          apiVersion: camel.apache.org/v1alpha1
          name: coffee-source
        properties:
          period: 5000
      sink:
  4. For the kamelet binding’s sink specify the Knative channel or broker and the required parameters.

    This example specifies a Knative channel as the sink:

    apiVersion: camel.apache.org/v1alpha1
    kind: KameletBinding
    metadata:
      name: coffees-to-knative
    spec:
      source:
        ref:
          kind: Kamelet
          apiVersion: camel.apache.org/v1alpha1
          name: coffee-source
        properties:
          period: 5000
      sink:
        ref:
          apiVersion: messaging.knative.dev/v1
          kind: InMemoryChannel
          name: mychannel

    This example specifies a Knative broker as the sink:

    apiVersion: camel.apache.org/v1alpha1
    kind: KameletBinding
    metadata:
      name: coffees-to-knative
    spec:
      source:
        ref:
          kind: Kamelet
          apiVersion: camel.apache.org/v1alpha1
          name: coffee-source
        properties:
          period: 5000
      sink:
          ref:
            kind: Broker
            apiVersion: eventing.knative.dev/v1
            name: default
          properties:
            type: coffee
  5. Save the YAML file (for example, coffees-to-knative.yaml).
  6. Log into your OpenShift project.
  7. Add the kamelet binding as a resource to your OpenShift namespace:

    oc apply -f <kamelet binding filename>

    For example:

    oc apply -f coffees-to-knative.yaml

    The Camel K operator generates and runs a Camel K integration by using the KameletBinding resource. It might take a few minutes to build.

  8. To see the status of the KameletBinding:

    oc get kameletbindings

  9. To see the status of their integrations:

    oc get integrations

  10. To view the integration’s log:

    kamel logs <integration> -n <project>

    For example:

    kamel logs coffees-to-knative -n my-camel-knative

    The result is similar to the following output:

    ...
    [1] INFO  [io.quarkus] (main) camel-k-integration 1.4.0 on JVM (powered by Quarkus 1.13.0.Final) started in 2.790s.

3.4. Connecting a Knative destination to a data sink in a kamelet binding

To connect a Knative destination to a data sink, you create a kamelet binding as illustrated in Figure 3.3.

Connecting a Knative destination to a data sink

Figure 3.3 Connecting a Knative destination to a data sink

The Knative destination can be a Knative channel or a Knative broker.

When you send data from a channel, there is only one event type for the channel. You do not need to specify any property values for the channel in a kamelet binding.

When you send data from a broker, because the broker can handle more than one event type, you must specify a value for the type property when you reference the broker in a kamelet binding.

Prerequisites

  • You know the name and type of the Knative channel or the name of the broker from which you want to receive events. For a broker, you also know the type of events that you want to receive.

    The example in this procedure uses the InMemoryChannel channel named mychannel or the broker named mybroker and coffee events (for the type property). These are the same example destinations that are used to receive events from the coffee source in Connecting a data source to a Knative channel in a kamelet binding.

  • You know which kamelet you want to add to your Camel integration and the required instance parameters.

    The example kamelet for this procedure is the log-sink kamelet. You can copy the code from the Example sink kamelet to a file named log-sink.kamelet.yaml file and then run the following command to add it as a resource to your namespace:

    oc apply -f log-sink.kamelet.yaml

Procedure

To connect a Knative channel to a data sink, create a kamelet binding:

  1. In an editor of your choice, create a YAML file with the following basic structure:

    apiVersion: camel.apache.org/v1alpha1
    kind: KameletBinding
    metadata:
      name:
    spec:
      source:
      sink:
  2. Add a name for the kamelet binding. For this example, the name is knative-to-log because the binding connects the Knative destination to the log-sink kamelet.

    apiVersion: camel.apache.org/v1alpha1
    kind: KameletBinding
    metadata:
      name: knative-to-log
    spec:
      source:
      sink:
  3. For the kamelet binding’s source, specify the Knative channel or broker and the required parameters.

    This example specifies a Knative channel as the source:

    apiVersion: camel.apache.org/v1alpha1
    kind: KameletBinding
    metadata:
      name: knative-to-log
    spec:
      source:
        ref:
                apiVersion: messaging.knative.dev/v1
                kind: InMemoryChannel
                name: mychannel
      sink:

    This example specifies a Knative broker as the source:

    apiVersion: camel.apache.org/v1alpha1
    kind: KameletBinding
    metadata:
      name: knative-to-log
    spec:
      source:
        ref:
              kind: Broker
              apiVersion: eventing.knative.dev/v1
              name: default
             properties:
             type: coffee
    sink:
  4. For the kamelet binding’s sink, specify the data consumer kamelet (for example, the log-sink kamelet) and configure any parameters for the kamelet, for example:

    apiVersion: camel.apache.org/v1alpha1
    kind: KameletBinding
    metadata:
      name: knative-to-log
    spec:
      source:
        ref:
                apiVersion: messaging.knative.dev/v1
                kind: InMemoryChannel
                name: mychannel
      sink:
        ref:
          apiVersion: camel.apache.org/v1alpha1
          kind: Kamelet
          name: log-sink
  5. Save the YAML file (for example, knative-to-log.yaml).
  6. Log into your OpenShift project.
  7. Add the kamelet binding as a resource to your OpenShift namespace: oc apply -f <kamelet binding filename>

    For example:

    oc apply -f knative-to-log.yaml

    The Camel K operator generates and runs a Camel K integration by using the KameletBinding resource. It might take a few minutes to build.

  8. To see the status of the KameletBinding:

    oc get kameletbindings

  9. To see the status of the integration:

    oc get integrations

  10. To view the integration’s log:

    kamel logs <integration> -n <project>

    For example:

    kamel logs knative-to-log -n my-camel-knative

    In the output, you should see coffee events, for example:

    [1] 2021-07-23 13:06:38,111 INFO [sink] (vert.x-worker-thread-1) {"id":254,"uid":"8e180ef7-8924-4fc7-ab81-d6058618cc42","blend_name":"Good-morning Star","origin":"Santander, Colombia","variety":"Kaffa","notes":"delicate, creamy, lemongrass, granola, soil","intensifier":"sharp"}
    [1] 2021-07-23 13:06:43,273 INFO [sink] (vert.x-worker-thread-2) {"id":8169,"uid":"3733c3a5-4ad9-43a3-9acc-d4cd43de6f3d","blend_name":"Caf? Java","origin":"Nayarit, Mexico","variety":"Red Bourbon","notes":"unbalanced, full, granola, bittersweet chocolate, nougat","intensifier":"delicate"}
  11. To stop a running integration, delete the associated kamelet binding resource:

    oc delete kameletbindings/<kameletbinding-name>

    For example:

    oc delete kameletbindings/knative-to-log