Serverless applications

Procedure

1. In the OpenShift Container Platform web console, navigate to the Operators → OperatorHub page.

2. Scroll, or type they keyword Serverless into the Filter by keyword box to find the OpenShift Serverless Operator.

   

3. Review the information about the Operator and click Install.

   

4. On the Create Operator Subscription page:

   
   1. The Installation Mode is All namespaces on the cluster (default). This mode installs the Operator in the default openshift-operators namespace to watch and be made available to all namespaces in the cluster.
   2. The Installed Namespace will be openshift-operators.
   3. Select the 4.4 channel as the Update Channel. The 4.4 channel will enable installation of the latest stable release of the OpenShift Serverless Operator.
   4. Select Automatic or Manual approval strategy.
5. Click Subscribe to make the Operator available to the selected namespaces on this OpenShift Container Platform cluster.

6. From the Catalog → Operator Management page, you can monitor the OpenShift Serverless Operator subscription’s installation and upgrade progress.

   1. If you selected a Manual approval strategy, the subscription’s upgrade status will remain Upgrading until you review and approve its install plan. After approving on the Install Plan page, the subscription upgrade status moves to Up to date.
   2. If you selected an Automatic approval strategy, the upgrade status should resolve to Up to date without intervention.

1. Switch to the Catalog → Operator Management page and inspect the Operator Subscriptions and Install Plans tabs for any failure or errors under Status.
2. Check the logs in any pods in the openshift-operators project on the Workloads → Pods page that are reporting issues to troubleshoot further.

Procedure

1. In the Administrator perspective of the OpenShift Container Platform web console, navigate to Operators → Installed Operators.
2. Check that the Project dropdown at the top of the page is set to Project: knative-serving.

3. Click Knative Serving in the list of Provided APIs for the OpenShift Serverless Operator to go to the Knative Serving tab.

   

4. Click the Create Knative Serving button.

   

5. In the Create Knative Serving page, you can install Knative Serving using the default settings by clicking Create.

   You can also modify settings for the Knative Serving installation by editing the KnativeServing object using either the form provided, or by editing the YAML.

   • Using the form is recommended for simpler configurations that do not require full control of KnativeServing object creation.

   • Editing the YAML is recommended for more complex configurations that require full control of KnativeServing object creation. You can access the YAML by clicking the edit YAML link in the top right of the Create Knative Serving page.

     After you complete the form, or have finished modifying the YAML, click Create.

     Note

     For more information about configuration options for the KnativeServing custom resource definition, see the documentation on Advanced installation configuration options.

     
     

6. After you have installed Knative Serving, the KnativeServing object is created, and you will be automically directed to the Knative Serving tab.

   

   You will see knative-serving in the list of resources.

Verification steps

1. Click on knative-serving in the Knative Serving tab.

2. You will be automatically directed to the Knative Serving Overview page.

   
3. Scroll down to look at the list of Conditions.

4. You should see a list of conditions with a status of True, as shown in the example image.

   
   Note

   It may take a few seconds for the Knative Serving resources to be created. You can check their status in the Resources tab.

5. If the conditions have a status of Unknown or False, wait a few moments and then check again after you have confirmed that the resources have been created.

Procedure

1. Create a file named serving.yaml.

2. Copy the following sample YAML into serving.yaml:

   apiVersion: operator.knative.dev/v1alpha1
   kind: KnativeServing
   metadata:
       name: knative-serving
       namespace: knative-serving

3. Apply the serving.yaml file:

   $ oc apply -f serving.yaml

Verification steps

1. To verify the installation is complete, enter the following command:

   $ oc get knativeserving.operator.knative.dev/knative-serving -n knative-serving --template='{{range .status.conditions}}{{printf "%s=%s\n" .type .status}}{{end}}'

   The output should be similar to:

   DependenciesInstalled=True
   DeploymentsAvailable=True
   InstallSucceeded=True
   Ready=True

   Note

   It may take a few seconds for the Knative Serving resources to be created.

2. If the conditions have a status of Unknown or False, wait a few moments and then check again after you have confirmed that the resources have been created.

3. Check that the Knative Serving resources have been created by entering:

   $ oc get pods -n knative-serving

   The output should look similar to:

   NAME                               READY   STATUS    RESTARTS   AGE
   activator-5c596cf8d6-5l86c         1/1     Running   0          9m37s
   activator-5c596cf8d6-gkn5k         1/1     Running   0          9m22s
   autoscaler-5854f586f6-gj597        1/1     Running   0          9m36s
   autoscaler-hpa-78665569b8-qmlmn    1/1     Running   0          9m26s
   autoscaler-hpa-78665569b8-tqwvw    1/1     Running   0          9m26s
   controller-7fd5655f49-9gxz5        1/1     Running   0          9m32s
   controller-7fd5655f49-pncv5        1/1     Running   0          9m14s
   kn-cli-downloads-8c65d4cbf-mt4t7   1/1     Running   0          9m42s
   webhook-5c7d878c7c-n267j           1/1     Running   0          9m35s

Procedure

1. In the Administrator perspective of the OpenShift Container Platform web console, navigate to Operators → Installed Operators.
2. Check that the Project dropdown at the top of the page is set to Project: knative-eventing.

3. Click Knative Eventing in the list of Provided APIs for the OpenShift Serverless Operator to go to the Knative Eventing tab.

   

4. Click the Create Knative Eventing button.

   

5. In the Create Knative Eventing page, you can choose to configure the KnativeEventing object by using either the default form provided, or by editing the YAML.

   • Using the form is recommended for simpler configurations that do not require full control of KnativeEventing object creation.

     Optional. If you are configuring the KnativeEventing object using the form, make any changes that you want to implement for your Knative Eventing deployment.

6. Click Create.

   

   • Editing the YAML is recommended for more complex configurations that require full control of KnativeEventing object creation. You can access the YAML by clicking the edit YAML link in the top right of the Create Knative Eventing page.

     Optional. If you are configuring the KnativeEventing object by editing the YAML, make any changes to the YAML that you want to implement for your Knative Eventing deployment.

7. Click Create.

   

8. After you have installed Knative Eventing, the KnativeEventing object is created, and you will be automically directed to the Knative Eventing tab.

   

   You will see knative-eventing in the list of resources.

Verification steps

1. Click on knative-eventing in the Knative Eventing tab.

2. You will be automatically directed to the Knative Eventing Overview page.

   
3. Scroll down to look at the list of Conditions.

4. You should see a list of conditions with a status of True, as shown in the example image.

   
   Note

   It may take a few seconds for the Knative Eventing resources to be created. You can check their status in the Resources tab.

5. If the conditions have a status of Unknown or False, wait a few moments and then check again after you have confirmed that the resources have been created.

Procedure

1. Create a file named eventing.yaml.

2. Copy the following sample YAML into eventing.yaml:

   apiVersion: operator.knative.dev/v1alpha1
   kind: KnativeEventing
   metadata:
       name: knative-eventing
       namespace: knative-eventing

3. Optional. Make any changes to the YAML that you want to implement for your Knative Eventing deployment.

4. Apply the eventing.yaml file by entering:

   $ oc apply -f eventing.yaml

Verification steps

1. To verify the installation is complete, enter:

   $ oc get knativeeventing.operator.knative.dev/knative-eventing \
     -n knative-eventing \
     --template='{{range .status.conditions}}{{printf "%s=%s\n" .type .status}}{{end}}'

   The output should be similar to:

   InstallSucceeded=True
   Ready=True

   Note

   It may take a few seconds for the Knative Eventing resources to be created.

2. If the conditions have a status of Unknown or False, wait a few moments and then check again after you have confirmed that the resources have been created.

3. Check that the Knative Eventing resources have been created by entering:

   $ oc get pods -n knative-eventing

   The output should look similar to:

   NAME                                   READY   STATUS    RESTARTS   AGE
   broker-controller-58765d9d49-g9zp6     1/1     Running   0          7m21s
   eventing-controller-65fdd66b54-jw7bh   1/1     Running   0          7m31s
   eventing-webhook-57fd74b5bd-kvhlz      1/1     Running   0          7m31s
   imc-controller-5b75d458fc-ptvm2        1/1     Running   0          7m19s
   imc-dispatcher-64f6d5fccb-kkc4c        1/1     Running   0          7m18s

Procedure

1. Select the openshift-operators namespace in the OpenShift Container Platform web console.
2. Navigate to the Operators → Installed Operators page.
3. Select the OpenShift Serverless Operator Operator.
4. Click Subscription → Channel.
5. In the Change Subscription Update Channel window, select 4.4, and then click Save.
6. Wait until all pods have been upgraded in the knative-serving namespace and the KnativeServing custom resource reports the latest Knative Serving version.

1. Check the status of the pods by entering the following command:

   $ oc get knativeserving.operator.knative.dev knative-serving -n knative-serving -o=jsonpath='{.status.conditions[?(@.type=="Ready")].status}'

   The previous command should return a status of True.

2. Check the version of the KnativeServing CR by entering the following command:

   $ oc get knativeserving.operator.knative.dev knative-serving -n knative-serving -o=jsonpath='{.status.version}'

   The previous command should return the latest version of Knative Serving. You can check the latest version in the OpenShift Serverless Operator release notes.

Procedure

1. To remove Knative Serving, enter the following command:

   $ oc delete knativeservings.operator.knative.dev knative-serving -n knative-serving

2. After the command has completed and all pods have been removed from the knative-serving namespace, delete the namespace by entering the following command:

   $ oc delete namespace knative-serving

Procedure

1. To remove Knative Eventing, enter the following command:

   $ oc delete knativeeventings.operator.knative.dev knative-eventing -n knative-eventing

2. After the command has completed and all pods have been removed from the knative-eventing namespace, delete the namespace by entering the following command:

   $ oc delete namespace knative-eventing

Procedure

1. To delete the remaining OpenShift Serverless CRDs, enter the following command:

   $ oc get crd -oname | grep 'knative.dev' | xargs oc delete

Procedure

1. Download the kn CLI from the Command Line Tools page.

2. Unpack the archive:

   $ tar -xf <file>

3. Move the kn binary to a directory on your PATH.

4. To check your path, run:

   $ echo $PATH

   Note

   If you do not use RHEL or Fedora, ensure that libc is installed in a directory on your library path. If libc is not available, you might see the following error when you run CLI commands:

   $ kn: No such file or directory

Procedure

1. Download the CLI.

2. Unpack the archive:

   $ tar -xf <file>

3. Move the kn binary to a directory on your PATH.

4. To check your path, run:

   $ echo $PATH

   Note

   If you do not use RHEL or Fedora, ensure that libc is installed in a directory on your library path. If libc is not available, you might see the following error when you run CLI commands:

   $ kn: No such file or directory

Procedure

1. Download the CLI.
2. Unpack and unzip the archive.
3. Move the kn binary to a directory on your PATH.

4. To check your PATH, open a terminal window and run:

   $ echo $PATH

Procedure

1. Download the CLI.
2. Unzip the archive with a ZIP program.
3. Move the kn binary to a directory on your PATH.

4. To check your PATH, open the Command Prompt and run the command:

   C:\> path

Procedure

1. Navigate to the Serverless → Services page.

   
2. Click Create Service.

3. Manually enter YAML or JSON definitions, or by dragging and dropping a file into the editor.

   
4. Click Create.

Procedure

1. Create a service in the default namespace from an image:

   $ kn service create hello --image docker.io/openshift/hello-openshift --env RESPONSE="Hello Serverless!"

   Example output

   Creating service 'hello' in namespace 'default':
   
     0.085s The Route is still working to reflect the latest desired specification.
     0.101s Configuration "hello" is waiting for a Revision to become ready.
    11.590s ...
    11.650s Ingress has not yet been reconciled.
    11.726s Ready to serve.
   
   Service 'hello' created with latest revision 'hello-gsdks-1' and URL:
   http://hello-default.apps-crc.testing

2. List the service:

   $ kn service list

   Example output

   NAME    URL                                     LATEST          AGE     CONDITIONS   READY   REASON
   hello   http://hello-default.apps-crc.testing   hello-gsdks-1   8m35s   3 OK / 3     True

3. Check if the service is working by using the curl service endpoint command:

   $ curl http://hello-default.apps-crc.testing

   Example output

   Hello Serverless!

4. Update the service:

   $ kn service update hello --env RESPONSE="Hello OpenShift!"

   Example output

   Updating Service 'hello' in namespace 'default':
   
    10.136s Traffic is not yet migrated to the latest revision.
    10.175s Ingress has not yet been reconciled.
    10.348s Ready to serve.
   
   Service 'hello' updated with latest revision 'hello-dghll-2' and URL:
   http://hello-default.apps-crc.testing

   The service’s environment variable RESPONSE is now set to "Hello OpenShift!".

5. Describe the service.

   $ kn service describe hello

   Example output

   Name:       hello
   Namespace:  default
   Age:        13m
   URL:        http://hello-default.apps-crc.testing
   
   Revisions:
     100%  @latest (hello-dghll-2) [2] (1m)
           Image:  docker.io/openshift/hello-openshift (pinned to 5ea96b)
   
   Conditions:
     OK TYPE                   AGE REASON
     ++ Ready                   1m
     ++ ConfigurationsReady     1m
     ++ RoutesReady             1m

6. Delete the service:

   $ kn service delete hello

   Example output

   Service 'hello' successfully deleted in namespace 'default'.

7. Verify that the hello service is deleted by attempting to list it:

   $ kn service list hello

   Example output

   No services found.

Procedure

1. To open the Kibana UI, the visualization tool for Elasticsearch, use the following command to get the Kibana route:

   $ oc -n openshift-logging get route kibana

2. Use the route’s URL to navigate to the Kibana dashboard and log in.
3. Ensure the index is set to .all. If the index is not set to .all, only the OpenShift Container Platform system logs are listed.

4. You can filter the logs by using the knative-serving namespace. Enter kubernetes.namespace_name:knative-serving in the search box to filter results.

   Note

   Knative Serving uses structured logging by default. You can enable parsing of these logs by customizing the cluster logging Fluentd settings. This enables filtering at the log level to quickly identify issues.

Procedure

1. Find the Kibana URL:

   $ oc -n cluster-logging get route kibana

2. Enter the URL in your browser to open the Kibana UI.
3. Ensure the index is set to .all. If the index is not set to .all, only the OpenShift Container Platform system logs are listed.

4. Filter the logs by using the Kubernetes namespace your service is deployed in. Add a filter to identify the service itself: kubernetes.namespace_name:default AND kubernetes.labels.serving_knative_dev\/service:{SERVICE_NAME}.

   Note

   You can also filter by using /configuration or /revision.

5. You can narrow your search by using kubernetes.container_name:<user-container> to only display the logs generated by your application. Otherwise, you will see logs from the queue-proxy.

   Note

   Use JSON-based structured logging in your application to allow for the quick filtering of these logs in production environments.

1. Click the serverless resource service, indicated by the quadrilateral, to see its overview in the side panel.

2. Click the Resources tab, to see a list of Revisions and Routes for the service.

   Figure 9.1. Serverless application

   
3. Click the service, indicated by the S icon at the top of the side panel, to see an overview of the service details.
4. Click the YAML tab and modify the service configuration in the YAML editor, and click Save. For example, change the timeoutseconds from 300 to 301 . This change in the configuration triggers a new revision. In the Topology view, the latest revision is displayed and the Resources tab for the service now displays the two revisions.

5. In the Resources tab, click the Set Traffic Distribution button to see the traffic distribution dialog box:

   1. Add the split traffic percentage portion for the two revisions in the Splits field.
   2. Add tags to create custom URLs for the two revisions.

   3. Click Save to see two nodes representing the two revisions in the Topology view.

      Figure 9.2. Serverless application revisions

      

Procedure

1. Create the ServiceAccount objects.

   1. Create the eventing-broker-ingress object by entering the following command:

      $ oc -n <namespace> create serviceaccount eventing-broker-ingress

   2. Create the eventing-broker-filter object by entering the following command:

      $ oc -n <namespace> create serviceaccount eventing-broker-filter

2. Give the objects that you have created RBAC permissions:

   $ oc -n default create rolebinding eventing-broker-ingress \
     --clusterrole=eventing-broker-ingress \
     --serviceaccount=default:eventing-broker-ingress

   $ oc -n default create rolebinding eventing-broker-filter \
     --clusterrole=eventing-broker-filter \
     --serviceaccount=default:eventing-broker-filter

3. Create a broker by creating and applying a YAML file containing the following:

   apiVersion: eventing.knative.dev/v1beta1
   kind: Broker
   metadata:
     namespace: default
     name: default 1

   1

   This example uses the name default, but you can replace this with any other valid name.

Procedure

1. Annotate your namespace by entering the following commands:

   $ oc label namespace default knative-eventing-injection=enabled 1
   $ oc -n default get broker default

   1

   Replace default with the desired namespace.

   The line shown in this example will automatically create a broker named default in the default namespace.

1. Delete the injected broker from the selected namespace (in this example, the default namespace):

   $ oc -n default delete broker default

Procedure

1. Create a Subscription object to connect a channel to a service, by creating a YAML file containing the following:

   apiVersion: messaging.knative.dev/v1beta1
   kind: Subscription
   metadata:
     name: my-subscription 1
     namespace: default
   spec:
     channel: 2
       apiVersion: messaging.knative.dev/v1beta1
       kind: Channel
       name: example-channel
     delivery: 3
       deadLetterSink:
         ref:
           apiVersion: serving.knative.dev/v1
           kind: Service
           name: error-handler
     subscriber: 4
       ref:
         apiVersion: serving.knative.dev/v1
         kind: Service
         name: event-display

   1

   Name of the subscription.

   2

   Configuration settings for the channel that the subscription connects to.

   3

   Configuration settings for event delivery. This tells the subscription what happens to events that cannot be delivered to the subscriber. When this is configured, events that failed to be consumed are sent to the deadLetterSink. The event is dropped, no re-delivery of the event is attempted, and an error is logged in the system. The deadLetterSink value must be a Destination.

   4

   Configuration settings for the subscriber. This is the event sink that events are delivered to from the channel.

2. Apply the YAML file by entering:

   $ oc apply -f <FILENAME>

Procedure

1. To check that SinkBinding is set up correctly, create a Knative event display service, or event sink, that dumps incoming messages to its log:

   $ kn service create event-display --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest

2. Create a SinkBinding that directs events to the service:

   $ kn source binding create bind-heartbeat --subject Job:batch/v1:app=heartbeat-cron --sink svc:event-display

3. Create a CronJob.

   1. Create a file named heartbeats-cronjob.yaml and copy the following sample code into it:

      apiVersion: batch/v1beta1
      kind: CronJob
      metadata:
        name: heartbeat-cron
      spec:
      spec:
        # Run every minute
        schedule: "* * * * *"
        jobTemplate:
          metadata:
            labels:
              app: heartbeat-cron
          spec:
            template:
              spec:
                restartPolicy: Never
                containers:
                  - name: single-heartbeat
                    image: quay.io/openshift-knative/knative-eventing-sources-heartbeats:latest
                    args:
                      - --period=1
                    env:
                      - name: ONE_SHOT
                        value: "true"
                      - name: POD_NAME
                        valueFrom:
                          fieldRef:
                            fieldPath: metadata.name
                      - name: POD_NAMESPACE
                        valueFrom:
                          fieldRef:
                            fieldPath: metadata.namespace

   2. After you have created the heartbeats-cronjob.yaml file, apply it by entering:

      $ oc apply --filename heartbeats-cronjob.yaml

4. Check that the controller is mapped correctly by entering the following command and inspecting the output:

   $ kn source binding describe bind-heartbeat

   Example output

   Name:         bind-heartbeat
   Namespace:    demo-2
   Annotations:  sources.knative.dev/creator=minikube-user, sources.knative.dev/lastModifier=minikub ...
   Age:          2m
   Subject:
     Resource:   job (batch/v1)
     Selector:
       app:      heartbeat-cron
   Sink:
     Name:       event-display
     Resource:   Service (serving.knative.dev/v1)
   
   Conditions:
     OK TYPE     AGE REASON
     ++ Ready     2m

Procedure

1. To check that SinkBinding is set up correctly, create a Knative event display service, or event sink, that dumps incoming messages to its log.

   1. Copy the following sample YAML into a file named service.yaml:

      apiVersion: serving.knative.dev/v1
      kind: Service
      metadata:
        name: event-display
      spec:
        template:
          spec:
            containers:
              - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest

   2. After you have created the service.yaml file, apply it by entering:

      $ oc apply -f service.yaml

2. Create a SinkBinding that directs events to the service.

   1. Create a file named sinkbinding.yaml and copy the following sample code into it:

      apiVersion: sources.knative.dev/v1alpha1
      kind: SinkBinding
      metadata:
        name: bind-heartbeat
      spec:
        subject:
          apiVersion: batch/v1
          kind: Job 1
          selector:
            matchLabels:
              app: heartbeat-cron
      
        sink:
          ref:
            apiVersion: serving.knative.dev/v1
            kind: Service
            name: event-display

   1

   In this example, any Job with the label app: heartbeat-cron will be bound to the event sink.

   1. After you have created the sinkbinding.yaml file, apply it by entering:

      $ oc apply -f sinkbinding.yaml

3. Create a CronJob.

   1. Create a file named heartbeats-cronjob.yaml and copy the following sample code into it:

      apiVersion: batch/v1beta1
      kind: CronJob
      metadata:
        name: heartbeat-cron
      spec:
      spec:
        # Run every minute
        schedule: "* * * * *"
        jobTemplate:
          metadata:
            labels:
              app: heartbeat-cron
          spec:
            template:
              spec:
                restartPolicy: Never
                containers:
                  - name: single-heartbeat
                    image: quay.io/openshift-knative/knative-eventing-sources-heartbeats:latest
                    args:
                      - --period=1
                    env:
                      - name: ONE_SHOT
                        value: "true"
                      - name: POD_NAME
                        valueFrom:
                          fieldRef:
                            fieldPath: metadata.name
                      - name: POD_NAMESPACE
                        valueFrom:
                          fieldRef:
                            fieldPath: metadata.namespace

   2. After you have created the heartbeats-cronjob.yaml file, apply it by entering:

      $ oc apply -f heartbeats-cronjob.yaml

4. Check that the controller is mapped correctly by entering the following command and inspecting the output:

   $ oc get sinkbindings.sources.knative.dev bind-heartbeat -oyaml

   Example output

   spec:
     sink:
       ref:
         apiVersion: serving.knative.dev/v1
         kind: Service
         name: event-display
         namespace: default
     subject:
       apiVersion: batch/v1
       kind: Job
       namespace: default
       selector:
         matchLabels:
           app: heartbeat-cron

1. View the message dumper function logs by entering the following commands:

   $ oc get pods

   $ oc logs $(oc get pod -o name | grep event-display) -c user-container

   Example output

   ☁️  cloudevents.Event
   Validation: valid
   Context Attributes,
     specversion: 1.0
     type: dev.knative.eventing.samples.heartbeat
     source: https://knative.dev/eventing-contrib/cmd/heartbeats/#event-test/mypod
     id: 2b72d7bf-c38f-4a98-a433-608fbcdd2596
     time: 2019-10-18T15:23:20.809775386Z
     contenttype: application/json
   Extensions,
     beats: true
     heart: yes
     the: 42
   Data,
     {
       "id": 1,
       "label": ""
     }

Procedure

1. Create a service account, role, and role binding for the ApiServerSource object.

   You can do this by creating a file named authentication.yaml and copying the following sample code into it:

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: events-sa
     namespace: default 1
   
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: event-watcher
     namespace: default 2
   rules:
     - apiGroups:
         - ""
       resources:
         - events
       verbs:
         - get
         - list
         - watch
   
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: k8s-ra-event-watcher
     namespace: default 3
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: event-watcher
   subjects:
     - kind: ServiceAccount
       name: events-sa
       namespace: default 4

   1 2 3 4

   Change this namespace to the namespace that you have selected for installing the API server source.

   Note

   If you want to reuse an existing service account with the appropriate permissions, you must modify the authentication.yaml file for that service account.

   Create the service account, role binding and cluster binding:

   $ oc apply -f authentication.yaml

2. Create an ApiServerSource object that uses a broker as an event sink:

   $ kn source apiserver create <event_source_name> --sink broker:<broker_name> --resource "event:v1" --service-account <service_account_name> --mode Resource

3. Create a Knative service that dumps incoming messages to its log:

   $ kn service create <service_name> --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest

4. Create a trigger to filter events from the default broker to the service:

   $ kn trigger create <trigger_name> --sink svc:<service_name>

5. Create events by launching a Pod in the default namespace:

   $ oc create deployment hello-node --image=quay.io/openshift-knative/knative-eventing-sources-event-display

6. Check that the controller is mapped correctly by inspecting the output generated by the following command:

   $ kn source apiserver describe testevents

   Example output

   Name:                testevents
   Namespace:           default
   Annotations:         sources.knative.dev/creator=developer, sources.knative.dev/lastModifier=developer
   Age:                 3m
   ServiceAccountName:  events-sa
   Mode:                Resource
   Sink:
     Name:       default
     Namespace:  default
     Kind:       Broker (eventing.knative.dev/v1alpha1)
   Resources:
     Kind:        event (v1)
     Controller:  false
   Conditions:
     OK TYPE                     AGE REASON
     ++ Ready                     3m
     ++ Deployed                  3m
     ++ SinkProvided              3m
     ++ SufficientPermissions     3m
     ++ EventTypesProvided        3m

1. Get the pods:

   $ oc get pods

2. View the message dumper function logs for the pods:

   $ oc logs $(oc get pod -o name | grep event-display) -c user-container

   Example output

   ☁️  cloudevents.Event
   Validation: valid
   Context Attributes,
     specversion: 1.0
     type: dev.knative.apiserver.resource.update
     datacontenttype: application/json
     ...
   Data,
     {
       "apiVersion": "v1",
       "involvedObject": {
         "apiVersion": "v1",
         "fieldPath": "spec.containers{hello-node}",
         "kind": "Pod",
         "name": "hello-node",
         "namespace": "default",
          .....
       },
       "kind": "Event",
       "message": "Started container",
       "metadata": {
         "name": "hello-node.159d7608e3a3572c",
         "namespace": "default",
         ....
       },
       "reason": "Started",
       ...
     }

Procedure

1. Delete the trigger:

   $ kn trigger delete <trigger_name>

2. Delete the service:

   $ kn service delete <service_name>

3. Delete the API server source:

   $ kn source apiserver delete <source_name>

4. Delete the service account, cluster role, and cluster binding:

Procedure

1. To create a service account, role, and role binding for the API server source, create a file named authentication.yaml and copy the following sample code into it:

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: events-sa
     namespace: default 1
   
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: event-watcher
     namespace: default 2
   rules:
     - apiGroups:
         - ""
       resources:
         - events
       verbs:
         - get
         - list
         - watch
   
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: k8s-ra-event-watcher
     namespace: default 3
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: event-watcher
   subjects:
     - kind: ServiceAccount
       name: events-sa
       namespace: default 4

   1 2 3 4

   Change this namespace to the namespace that you have selected for installing the API server source.

   Note

   If you want to re-use an existing service account with the appropriate permissions, you must modify the authentication.yaml for that service account.

   After you have created the authentication.yaml file, apply it:

   $ oc apply -f authentication.yaml

2. To create an ApiServerSource object, create a file named k8s-events.yaml and copy the following sample code into it:

   apiVersion: sources.knative.dev/v1alpha1
   kind: ApiServerSource
   metadata:
     name: testevents
   spec:
     serviceAccountName: events-sa
     mode: Resource
     resources:
       - apiVersion: v1
         kind: Event
     sink:
       ref:
         apiVersion: eventing.knative.dev/v1beta1
         kind: Broker
         name: default

   After you have created the k8s-events.yaml file, apply it:

   $ oc apply -f k8s-events.yaml

3. To check that the API server source is set up correctly, create a Knative service that dumps incoming messages to its log.

   Copy the following sample YAML into a file named service.yaml:

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: event-display
     namespace: default
   spec:
     template:
       spec:
         containers:
           - image: quay.io/openshift-knative/knative-eventing-sources-event-display:v0.13.2

   After you have created the service.yaml file, apply it:

   $ oc apply -f service.yaml

4. To create a trigger from the default broker that filters events to the service created in the previous step, create a file named trigger.yaml and copy the following sample code into it:

   apiVersion: eventing.knative.dev/v1alpha1
   kind: Trigger
   metadata:
     name: event-display-trigger
     namespace: default
   spec:
     subscriber:
       ref:
         apiVersion: serving.knative.dev/v1
         kind: Service
         name: event-display

   After you have created the trigger.yaml file, apply it:

   $ oc apply -f trigger.yaml

5. To create events, launch a pod in the default namespace:

   $ oc create deployment hello-node --image=quay.io/openshift-knative/knative-eventing-sources-event-display

6. To check that the controller is mapped correctly, enter the following command and inspect the output:

   $ oc get apiserversource.sources.knative.dev testevents -o yaml

   Example output

   apiVersion: sources.knative.dev/v1alpha1
   kind: ApiServerSource
   metadata:
     annotations:
     creationTimestamp: "2020-04-07T17:24:54Z"
     generation: 1
     name: testevents
     namespace: default
     resourceVersion: "62868"
     selfLink: /apis/sources.knative.dev/v1alpha1/namespaces/default/apiserversources/testevents2
     uid: 1603d863-bb06-4d1c-b371-f580b4db99fa
   spec:
     mode: Resource
     resources:
     - apiVersion: v1
       controller: false
       controllerSelector:
         apiVersion: ""
         kind: ""
         name: ""
         uid: ""
       kind: Event
       labelSelector: {}
     serviceAccountName: events-sa
     sink:
       ref:
         apiVersion: eventing.knative.dev/v1beta1
         kind: Broker
         name: default

1. Get the pods:

   $ oc get pods

2. View the message dumper function logs for the pods:

   $ oc logs $(oc get pod -o name | grep event-display) -c user-container

   Example output

   ☁️  cloudevents.Event
   Validation: valid
   Context Attributes,
     specversion: 1.0
     type: dev.knative.apiserver.resource.update
     datacontenttype: application/json
     ...
   Data,
     {
       "apiVersion": "v1",
       "involvedObject": {
         "apiVersion": "v1",
         "fieldPath": "spec.containers{hello-node}",
         "kind": "Pod",
         "name": "hello-node",
         "namespace": "default",
          .....
       },
       "kind": "Event",
       "message": "Started container",
       "metadata": {
         "name": "hello-node.159d7608e3a3572c",
         "namespace": "default",
         ....
       },
       "reason": "Started",
       ...
     }

Procedure

1. Delete the trigger:

   $ oc delete -f trigger.yaml

2. Delete the service:

   $ oc delete -f service.yaml

3. Delete the API server source:

   $ oc delete -f k8s-events.yaml

4. Delete the service account, cluster role, and cluster binding:

   $ oc delete -f authentication.yaml

Procedure

1. To verify that the ping source is working, create a simple Knative service that dumps incoming messages to the service’s logs:

   $ kn service create event-display \
       --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest

2. For each set of ping events that you want to request, create a PingSource object in the same namespace as the event consumer:

   $ kn source ping create test-ping-source \
       --schedule "*/2 * * * *" \
       --data '{"message": "Hello world!"}' \
       --sink svc:event-display

3. Check that the controller is mapped correctly by entering the following command and inspecting the output:

   $ kn source ping describe test-ping-source

   Example output

   Name:         test-ping-source
   Namespace:    default
   Annotations:  sources.knative.dev/creator=developer, sources.knative.dev/lastModifier=developer
   Age:          15s
   Schedule:     */2 * * * *
   Data:         {"message": "Hello world!"}
   
   Sink:
     Name:       event-display
     Namespace:  default
     Resource:   Service (serving.knative.dev/v1)
   
   Conditions:
     OK TYPE                 AGE REASON
     ++ Ready                 8s
     ++ Deployed              8s
     ++ SinkProvided         15s
     ++ ValidSchedule        15s
     ++ EventTypeProvided    15s
     ++ ResourcesCorrect     15s

1. Watch for new pods created:

   $ watch oc get pods

2. Cancel watching the pods using Ctrl+C, then look at the logs of the created pod:

   $ oc logs $(oc get pod -o name | grep event-display) -c user-container

   Example output

   ☁️  cloudevents.Event
   Validation: valid
   Context Attributes,
     specversion: 1.0
     type: dev.knative.sources.ping
     source: /apis/v1/namespaces/default/pingsources/test-ping-source
     id: 99e4f4f6-08ff-4bff-acf1-47f61ded68c9
     time: 2020-04-07T16:16:00.000601161Z
     datacontenttype: application/json
   Data,
     {
       "message": "Hello world!"
     }

Procedure

1. To verify that the ping source is working, create a simple Knative service that dumps incoming messages to the service’s logs.

   1. Copy the example YAML into a file named service.yaml:

      apiVersion: serving.knative.dev/v1
      kind: Service
      metadata:
        name: event-display
      spec:
        template:
          spec:
            containers:
              - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest

   2. Apply the service.yaml file:

      $ oc apply --filename service.yaml

2. For each set of ping events that you want to request, create a PingSource object in the same namespace as the event consumer.

   1. Copy the example YAML into a file named ping-source.yaml:

      apiVersion: sources.knative.dev/v1alpha2
      kind: PingSource
      metadata:
        name: test-ping-source
      spec:
        schedule: "*/2 * * * *"
        jsonData: '{"message": "Hello world!"}'
        sink:
          ref:
            apiVersion: serving.knative.dev/v1
            kind: Service
            name: event-display

   2. Apply the ping-source.yaml file:

      $ oc apply --filename ping-source.yaml

3. Check that the controller is mapped correctly by entering the following command and observing the output:

   $ oc get pingsource.sources.knative.dev test-ping-source -oyaml

   Example output

   apiVersion: sources.knative.dev/v1alpha2
   kind: PingSource
   metadata:
     annotations:
       sources.knative.dev/creator: developer
       sources.knative.dev/lastModifier: developer
     creationTimestamp: "2020-04-07T16:11:14Z"
     generation: 1
     name: test-ping-source
     namespace: default
     resourceVersion: "55257"
     selfLink: /apis/sources.knative.dev/v1alpha2/namespaces/default/pingsources/test-ping-source
     uid: 3d80d50b-f8c7-4c1b-99f7-3ec00e0a8164
   spec:
     jsonData: '{ value: "hello" }'
     schedule: '*/2 * * * *'
     sink:
       ref:
         apiVersion: serving.knative.dev/v1
         kind: Service
         name: event-display
         namespace: default

1. Watch for new pods created:

   $ watch oc get pods

2. Cancel watching the pods using Ctrl+C, then look at the logs of the created pod:

   $ oc logs $(oc get pod -o name | grep event-display) -c user-container

   Example output

   ☁️  cloudevents.Event
   Validation: valid
   Context Attributes,
     specversion: 1.0
     type: dev.knative.sources.ping
     source: /apis/v1/namespaces/default/pingsources/test-ping-source
     id: 042ff529-240e-45ee-b40c-3a908129853e
     time: 2020-04-07T16:22:00.000791674Z
     datacontenttype: application/json
   Data,
     {
       "message": "Hello world!"
     }

1. Run the report by applying it as a YAML file:

   $ oc apply -f <report_name>.yaml

2. Check the report:

   $ oc get report

   Example output

   NAME                        QUERY                       SCHEDULE   RUNNING    FAILED   LAST REPORT TIME       AGE
   knative-service-cpu-usage   knative-service-cpu-usage              Finished            2019-06-30T23:59:59Z   10h