Serverless

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 Install Operator 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.5 channel as the Update Channel. The 4.5 channel will enable installation of the latest stable release of the OpenShift Serverless Operator.
   4. Select Automatic or Manual approval strategy.
5. Click Install 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

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

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

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

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.5, and then click Save.
6. Wait until all pods have been upgraded in the knative-serving namespace and the KnativeServing custom resource (CR) reports the latest Knative Serving version.

1. Check the status of the pods:

   $ 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:

   $ 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. 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 system logs will be 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 the parsing of these logs by customizing the cluster logging Fluentd settings. This makes the logs more searchable and enables filtering on the log level to quickly identify issues.

Procedure

1. Use the following command to find the URL to Kibana:

   $ 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 system logs will be 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

      

1. Create a Channel object.

   1. Create a YAML file and copy the following sample code into it:

      apiVersion: messaging.knative.dev/v1
      kind: Channel
      metadata:
        name: example-channel
        namespace: default

   2. Apply the YAML file by entering:

      $ oc apply -f <filename>

Procedure

1. Create a YAML file and copy the following sample code into it:

   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:

   $ oc apply -f <FILENAME>

Procedure

1. Create a service account, role, and role binding for the event source 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 event 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.

2. Create the service account, role binding, and cluster binding by entering the following command:

   $ oc apply --filename authentication.yaml

Procedure

1. Navigate to the Add page and select Event Source.

2. In the Event Sources page, select ApiServerSource in the Type section.

   

3. Configure the ApiServerSource settings:

   1. Enter v1 as the APIVERSION, and Event as the KIND.

   2. Select the Service Account Name for the service account that you created.

      
   3. Select the targeted Knative service from the dropdown menu in Sink → Knative Service.
4. Click Create.

Verification

1. After you have created the ApiServerSource, you will see it connected to the service it is sinked to in the Topology view.

   

Procedure

1. Navigate to the Topology view.

2. Right-click the ApiServerSource and select Delete ApiServerSource.

   

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 ksvc:<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/v1)
   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/v1
         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:latest

   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/v1
   kind: Trigger
   metadata:
     name: event-display-trigger
     namespace: default
   spec:
     broker: default
     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/v1
         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 ksvc: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 log of the service.

   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!"
     }

Procedure

1. To check that sink binding 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 object that directs events to the service:

   $ kn source binding create bind-heartbeat --subject Job:batch/v1:app=heartbeat-cron --sink ksvc: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
              bindings.knative.dev/include: "true"
          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

      Important

      To use sink binding, you must manually add a bindings.knative.dev/include=true label to your Knative resources.

      For example, to add this label to a CronJob object, add the following lines to the Job resource YAML definition:

        jobTemplate:
          metadata:
            labels:
              app: heartbeat-cron
              bindings.knative.dev/include: "true"

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

      $ 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 sink binding 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:

      $ oc apply -f service.yaml

2. Create a SinkBinding object 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.

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

      $ oc apply -f sinkbinding.yaml

3. Create a CronJob object.

   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
              bindings.knative.dev/include: "true"
          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

      Important

      To use sink binding, you must manually add a bindings.knative.dev/include=true label to your Knative resources.

      For example, to add this label to a cron job instance, add the following lines to the Job resource YAML definition:

        jobTemplate:
          metadata:
            labels:
              app: heartbeat-cron
              bindings.knative.dev/include: "true"

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

      $ 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:

   $ 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. Add the sidecar.istio.io/inject="true" annotation to the Service resource:

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: hello-example-1
   spec:
     template:
       metadata:
         annotations:
           sidecar.istio.io/inject: "true" 1
       spec:
         containers:
         - image: docker.io/openshift/hello-openshift
           name: container

   1

   Add the sidecar.istio.io/inject="true" annotation.

2. Apply the Service resource YAML file:

   $ oc apply -f <filename>

Procedure

1. Create an Istio gateway to accept traffic.

   1. Create a YAML file, and copy the following YAML into it:

      apiVersion: networking.istio.io/v1alpha3
      kind: Gateway
      metadata:
        name: default-gateway
      spec:
        selector:
          istio: ingressgateway
        servers:
        - port:
            number: 80
            name: http
            protocol: HTTP
          hosts:
          - "*"

   2. Apply the YAML file:

      $ oc apply -f <filename>

2. Create an Istio VirtualService object to rewrite the host header.

   1. Create a YAML file, and copy the following YAML into it:

      apiVersion: networking.istio.io/v1alpha3
      kind: VirtualService
      metadata:
        name: hello
      spec:
        hosts:
        - custom-ksvc-domain.example.com
        gateways:
        - default-gateway
        http:
        - rewrite:
            authority: hello.default.svc 1
          route:
          - destination:
              host: hello.default.svc 2
              port:
                number: 80

      1 2

      Your Knative service in the format <service_name>.<namespace>.svc.

   2. Apply the YAML file:

      $ oc apply -f <filename>

3. Create an Istio ServiceEntry object. This is required for OpenShift Serverless because Kourier is outside of the service mesh.

   1. Create a YAML file, and copy the following YAML into it:

      apiVersion: networking.istio.io/v1alpha3
      kind: ServiceEntry
      metadata:
        name: hello.default.svc
      spec:
        hosts:
        - hello.default.svc 1
        location: MESH_EXTERNAL
        endpoints:
        - address: kourier-internal.knative-serving-ingress.svc
        ports:
        - number: 80
          name: http
          protocol: HTTP
        resolution: DNS

      1

      Your Knative service in the format <service_name>.<namespace>.svc.

   2. Apply the YAML file:

      $ oc apply -f <filename>

4. Create an OpenShift Container Platform route that points to the VirtualService object.

   1. Create a YAML file, and copy the following YAML into it:

      apiVersion: route.openshift.io/v1
      kind: Route
      metadata:
        name: hello
        namespace: istio-system 1
      spec:
        host: custom-ksvc-domain.example.com
        port:
          targetPort: 8080
        to:
          kind: Service
          name: istio-ingressgateway

Procedure

1. Access the custom domain by using the Host header in a curl request. For example:

   $ curl -H "Host: custom-ksvc-domain.example.com" http://<ip_address>

   where <ip_address> is the IP address that the OpenShift Container Platform ingress router is exposed to.

   Example output

   Hello OpenShift!

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

   $ oc apply -f <report_name>.yaml

2. You can then check the report by entering the following command:

   $ 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