Red Hat Serverless Operator usage and troubleshooting in OpenShift 4

Red Hat Serverless Operator provides Knative features directly in Red Hat OpenShift.  

Let's start by exploring: What is serverless? Serverless refers to running back-end programs and processes in the cloud. Serverless works on an as-used basis, meaning that companies only use what they pay for. Knative is a platform-agnostic solution for running serverless deployments.

Red Hat OpenShift Serverless, built on top of the Knative project for Kubernetes and its Red Hat FaaS environments.

More so, Serverless computing offerings typically fall into two groups:

• Backend-as-a-Service (BaaS): BaaS gives developers access to a variety of third-party services and apps. For instance, a cloud-provider may offer authentication services, extra encryption, cloud-accessible databases, and high-fidelity usage data. 
• Function-as-a-Service (FaaS): Developers still write custom server-side logic, but it’s run in containers fully managed by a cloud services provider.

Figure 1 depicts the serverless components.

Installation

Selecting Red Hat OpenShift Serverless as shown in Figure 2 will be installed in a new namespace called openshift-serverless.

This Operator will provide three APIs: Knative Serving, Knative Eventing, and Knative Kafka as shown in Figure 3.

After its installation, the following will happen:

• A new namespace called openshift-serverless will be created, and in it, there will be three pods: knative-openshift, knative-openshift-ingress, and knative-operator-webhook.
• A new namespace called knative-serving will be created, without pods.
• A new namespace called knative-eventing will be created, without pods.

As soon as one Serving or Eventing is created, the Serverless menu will appear on the left side of the main menu (Figure 4).

Knative Serving

This type of resource allows the user to define and control how the serverless workload behaves on the cluster.

Knative Serving is a platform for streamlined application deployment, traffic-based auto-scaling from zero to N, and traffic-split rollouts, as the documentation explains.

The serving can only be created in the serving namespace, otherwise, it will fail as below:

- lastTransitionTime: '2024-08-01T18:26:56Z'
message: 'Install failed with message: Knative Serving must be installed into the namespace "knative-serving"'

Knative Eventing

Knative Eventing is a collection of APIs that enable you to use an event-driven architecture with your applications. You can use these APIs to create components that route events from event producers (known as sources) to event consumers (known as sinks) that receive events. Sinks can also be configured to respond to HTTP requests by sending a response event.

An event-driven application platform that leverages CloudEvents with a simple HTTP interface.

Knative Kafka

Knative Kafka is an extension to Knative Eventing, merging HTTP accessibility with Apache Kafka's proven efficiency and reliability.

Other CustomResources/Definitions

Upon the installation of the Serverless Operator and then the creation of Knative eventing and Knative serving other APIs (CustomResourceDefinitions) will be displayed. Below one sees that the default three main APIs were installed and then the others, such as pingsources.sources.knative.dev came right after together with the others:

$ oc get crd  | grep knative
apiserversources.sources.knative.dev                              2024-12-10T02:01:39Z
brokers.eventing.knative.dev                                      2024-12-10T02:01:39Z
certificates.networking.internal.knative.dev                      2024-12-10T02:01:33Z
channels.messaging.knative.dev                                    2024-12-10T02:01:39Z
clusterdomainclaims.networking.internal.knative.dev               2024-12-10T02:01:33Z
configurations.serving.knative.dev                                2024-12-10T02:01:33Z
containersources.sources.knative.dev                              2024-12-10T02:01:39Z
domainmappings.serving.knative.dev                                2024-12-10T02:01:34Z
eventtypes.eventing.knative.dev                                   2024-12-10T02:01:39Z
images.caching.internal.knative.dev                               2024-12-10T02:01:33Z
ingresses.networking.internal.knative.dev                         2024-12-10T02:01:34Z
inmemorychannels.messaging.knative.dev                            2024-12-10T02:01:45Z
knativeeventings.operator.knative.dev                             2024-12-10T02:00:22Z
knativekafkas.operator.serverless.openshift.io                    2024-12-10T02:00:22Z
knativeservings.operator.knative.dev                              2024-12-10T02:00:23Z
metrics.autoscaling.internal.knative.dev                          2024-12-10T02:01:34Z
parallels.flows.knative.dev                                       2024-12-10T02:01:39Z
pingsources.sources.knative.dev                                   2024-12-10T02:01:39Z
podautoscalers.autoscaling.internal.knative.dev                   2024-12-10T02:01:34Z
revisions.serving.knative.dev                                     2024-12-10T02:01:34Z
routes.serving.knative.dev                                        2024-12-10T02:01:34Z
sequences.flows.knative.dev                                       2024-12-10T02:01:40Z
serverlessservices.networking.internal.knative.dev                2024-12-10T02:01:34Z
services.serving.knative.dev                                      2024-12-10T02:01:34Z
sinkbindings.sources.knative.dev                                  2024-12-10T02:01:40Z
subscriptions.messaging.knative.dev                               2024-12-10T02:01:40Z
triggers.eventing.knative.dev                                     2024-12-10T02:01:40Z

The new CustomResourceDefinitions (CRDs) build upon the three main CustomResources (CRs: knative eventing, knative serving, knative kafka) to provide advanced features such as Ping Sources, which is an event source that produces events with a fixed payload on a specified cron schedule. 

Demo

The steps below basically reiterate the learning path Create an OpenShift Serverless function by Don Schenck. See below:

1. Install the OpenShift Serverless Operator.
2. Verify the Serverless Option on the menu is created (see above).
3. Deploy the Photobooth application.

4. Create a Serving $oc get kservice, which can be trivial for this demo:

   apiVersion: operator.knative.dev/v1beta1
   kind: KnativeServing
   metadata:
     name: knative-serving
     namespace: knative-serving
   spec:
     controller-custom-certs:
       name: ''
       type: ''
     registry: {}

   After the Serving creation, several pods will appear in the knative-serving namespace:

   $ oc project knative-serving
   $ oc get pod
   NAME                              READY   STATUS    RESTARTS   AGE
   activator-7b7d4557cc-4rfk9        2/2     Running   0          16m
   activator-7b7d4557cc-jsf5s        2/2     Running   0          17m
   autoscaler-f794648c6-h4p2x        2/2     Running   0          17m
   autoscaler-f794648c6-rknhg        2/2     Running   0          17m
   autoscaler-hpa-659f6f48b7-gm9jx   2/2     Running   0          17m
   autoscaler-hpa-659f6f48b7-z4ddb   2/2     Running   0          17m
   controller-85c7c98dfc-2bgbg       2/2     Running   0          16m
   controller-85c7c98dfc-gp5kp       2/2     Running   0          17m
   webhook-7c4994d865-fqdlr          2/2     Running   0          16m
   webhook-7c4994d865-l2mvt          2/2     Running   0          17m

5. Create a Service ($oc get ksvc). This must be created after the Serving:

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: imageoverlay
     namespace: knative-serving
   spec:
     template:
       spec:
         containers:
           - image: quay.io/rhdevelopers/imageoverlay:latest

6. Get the route using $oc get ksvc:

   $ oc get ksvc
   NAME           URL                                                                                        LATESTCREATED        LATESTREADY          READY   REASON
   imageoverlay   https://imageoverlay-knative-serving.apps.rosa.example.com   imageoverlay-00001   imageoverlay-00001   True    

7. Apply the ksvc in the field Service URL Setting: https://imageoverlay-knative-serving.apps.rosa.example.com.
8. Take the picture (Figure 5).

Customization

For customizing settings, such as the container settings, one can do as explained in the solution Setting Serverless Operator container limits and requests in OCP 4. For example:

$ oc get kservice -o yaml
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: showcase
  namespace: knative-serving
  annotations:
    serving.knative.dev/creator: cluster-admin
    serving.knative.dev/lastModifier: cluster-admin
spec:
  template:
    metadata:
      annotations:
        queue.sidecar.serving.knative.dev/resourcePercentage: "40" <---- 40% of the user-container will be queue-proxy

Troubleshooting

For troubleshooting, we usually verify:

• The CustomResources: serving, events, $oc get kservice, and $oc get kevent.
• Inspect bundle, where the pod YAMLs and pod logs will be.
• In most cases we ask the serverless must-gather as well, but not in all cases.

Learn more

This article covers the introduction, installation, customization, and finally troubleshooting of Red Hat OpenShift Serverless. 

Don Schenck's learning path Create an OpenShift Serverless function is an excellent resource for learning more. 

Additional resources

For any other specific inquiries, please open a case with Red Hat support. Our global team of experts can help you with any issues.

Special thanks to Jonathan Edwards for the excellent collaboration last year on Knative, Alexander Barbosa
for the contribution to this article with the diagrams/reviews, and finally Josh Brandenburg for allocating time for my research on this topic as well.