This topic describes how to verify that Knative Eventing was successfully installed.

Note: The Knative eventing functionality is in beta. VMware does not recommend using Knative eventing functionality in a production environment.

About Verifying Knative Eventing

You can verify Knative Eventing by setting up a broker, creating a producer, and creating a consumer. If your installation was successful, you can create a test eventing workflow and see that the events appear in the logs.

You can use either an in-memory broker or a RabbitMQ broker to verify Knative Eventing:

  • RabbitMQ broker: Using a RabbitMQ broker to verify Knative Eventing is a scalable and reliable way to verify your installation. Verifying with RabbitMQ uses methods similar to production environments.

  • In-memory broker: Using an in-memory broker is a fast and lightweight way to verify that the basic elements of Knative Eventing are installed. An in-memory broker is not meant for production environments or for use with apps that you intend to take to production.

Prerequisites

Before you verify Knative Eventing, you must:

  • Have created the cnr-demo namespace and variable. See step 1 of Verifying Your Installation.

  • Create the following role binding in the cnr-demo namespace. Run:

    kubectl apply -f - << EOF
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: ${WORKLOAD_NAMESPACE}-psp
      namespace: ${WORKLOAD_NAMESPACE}
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: cnr-restricted
    subjects:
    - kind: Group
      name: system:serviceaccounts:${WORKLOAD_NAMESPACE}
    EOF
    

Prepare the RabbitMQ Environment

If you are using a RabbitMQ broker to verify Knative Eventing, follow the procedure in this section. If you are verifying with the in-memory broker, skip to Verify Knative Eventing.

To prepare the RabbitMQ environment before verifying Knative Eventing:

  1. Set up the RabbitMQ integration as described in Integrating RabbitMQ with Cloud Native Runtimes for Tanzu.

  2. On the Kubernetes cluster where Cloud Native Runtimes is installed, deploy a RabbitMQ cluster using the RabbitMQ Cluster Operator by running:

    kubectl apply -f - << EOF
    apiVersion: rabbitmq.com/v1beta1
    kind: RabbitmqCluster
    metadata:
      name: my-rabbit
      namespace: ${WORKLOAD_NAMESPACE}
    spec:
      replicas: 1
      override:
        statefulSet:
          spec:
            template:
              spec:
                securityContext: {}
                containers: []
                initContainers:
                - name: setup-container
                  securityContext:
                    runAsUser: 999
                    runAsGroup: 999
    EOF
    

    Note: The override section can be omitted if your cluster allows containers to run as root.

Verify Knative Eventing

To verify installation of Knative Eventing create and test a broker, procedure, and consumer in the cnr-demo namespace:

  1. Create a broker.

    For the RabbitMQ broker. Run:

    kubectl apply -f - << EOF
    apiVersion: eventing.knative.dev/v1
    kind: Broker
    metadata:
      name: default
      namespace: ${WORKLOAD_NAMESPACE}
      annotations:
        eventing.knative.dev/broker.class: RabbitMQBroker
    spec:
      config:
        apiVersion: rabbitmq.com/v1beta1
        kind: RabbitmqCluster
        name: my-rabbit
        namespace: ${WORKLOAD_NAMESPACE}
    EOF
    

    For the in-memory broker. Run:

    kubectl create -f - <<EOF
    apiVersion: eventing.knative.dev/v1
    kind: Broker
    metadata:
      name: default
      namespace: ${WORKLOAD_NAMESPACE}
    EOF
    
  2. Create a consumer for the events. Run:

    cat <<EOF | kubectl create -f -
    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:
      name: event-display
      namespace: ${WORKLOAD_NAMESPACE}
    spec:
      template:
        spec:
          containers:
            - image: gcr.io/knative-releases/knative.dev/eventing-contrib/cmd/event_display
    EOF
    
  3. Create a trigger. Run:

    kubectl apply -f - << EOF
    apiVersion: eventing.knative.dev/v1
    kind: Trigger
    metadata:
      name: event-display
      namespace: ${WORKLOAD_NAMESPACE}
    spec:
      broker: default
      subscriber:
        ref:
         apiVersion: serving.knative.dev/v1
         kind: Service
         name: event-display
         namespace: ${WORKLOAD_NAMESPACE}
    EOF
    
  4. Create a producer. Run:

    cat <<EOF | kubectl create -f -
    apiVersion: sources.knative.dev/v1
    kind: PingSource
    metadata:
      name: test-ping-source
      namespace: ${WORKLOAD_NAMESPACE}
    spec:
      schedule: "*/1 * * * *"
      data: '{"message": "Hello Eventing!"}'
      sink:
        ref:
          apiVersion: eventing.knative.dev/v1
          kind: Broker
          name: default
          namespace: ${WORKLOAD_NAMESPACE}
    EOF
    
  5. Verify that the event appears in your consumer logs. Run:

    kubectl logs -l serving.knative.dev/service=event-display -c user-container -n ${WORKLOAD_NAMESPACE} --since=10m --tail=50
    

Delete the Eventing Resources

After verifying your serving installation, clean up by deleting the resources used for the test:

  1. Delete the eventing resources:

    kubectl delete pingsource/test-ping-source -n ${WORKLOAD_NAMESPACE}
    kubectl delete trigger/event-display -n ${WORKLOAD_NAMESPACE}
    kubectl delete kservice/event-display -n ${WORKLOAD_NAMESPACE}
    kubectl delete broker/default -n ${WORKLOAD_NAMESPACE}
    
  2. If you created a RabbitMQ cluster:

    kubectl delete rabbitmqcluster/my-rabbit -n ${WORKLOAD_NAMESPACE}
    
  3. Delete the role binding:

    kubectl delete rolebinding/${WORKLOAD_NAMESPACE}-psp -n ${WORKLOAD_NAMESPACE}
    
check-circle-line exclamation-circle-line close-line
Scroll to top icon