Creating and managing serverless applications | Serverless

Serverless applications using Knative services
Creating serverless applications using the OpenShift Container Platform web console
- Creating serverless applications using the Administrator perspective
Creating serverless applications using the Knative CLI
Creating serverless applications using YAML
Verifying your serverless application deployment
Interacting with a serverless application using HTTP2 and gRPC

Serverless applications using Knative services

To deploy a serverless application using OpenShift Serverless, you must create a Knative service. Knative services are Kubernetes services, defined by a route and a configuration, and contained in a YAML file.

Example Knative service YAML

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: hello (1)
  namespace: default (2)
spec:
  template:
    spec:
      containers:
        - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest (3)
          env:
            - name: RESPONSE (4)
              value: "Hello Serverless!"

1	The name of the application.
2	The namespace the application will use.
3	The image of the application.
4	The environment variable printed out by the sample application.

You can create a serverless application by using one of the following methods: * Create a Knative service from the OpenShift Container Platform web console. * Create a Knative service using the kn CLI. * Create and apply a YAML file.

Creating serverless applications using the OpenShift Container Platform web console

You can create a serverless application using either the Developer or Administrator perspective in the OpenShift Container Platform web console.

For more information about creating applications using the Developer perspective in OpenShift Container Platform, see the documentation on Creating applications using the Developer perspective.

Creating serverless applications using the Administrator perspective

Prerequisites

To create serverless applications using the Administrator perspective, ensure that you have completed the following steps.

The OpenShift Serverless Operator and Knative Serving are installed.
You have logged in to the web console and are in the Administrator perspective.

Procedure

Navigate to the Serverless → Services page.
Click Create Service.
Manually enter YAML or JSON definitions, or by dragging and dropping a file into the editor.
Click Create.

Creating serverless applications using the Knative CLI

The following procedure describes how you can create a basic serverless application using the kn CLI.

Prerequisites

OpenShift Serverless Operator and Knative Serving are installed on your cluster.
You have installed the kn CLI.

Procedure

Create a Knative service:

$ kn service create <service_name> --image <image> --env <key=value>

Example command

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

Example output

Creating service 'event-display' in namespace 'default':

  0.271s The Route is still working to reflect the latest desired specification.
  0.580s Configuration "event-display" is waiting for a Revision to become ready.
  3.857s ...
  3.861s Ingress has not yet been reconciled.
  4.270s Ready to serve.

Service 'event-display' created with latest revision 'event-display-bxshg-1' and URL:
http://event-display-default.apps-crc.testing

Creating serverless applications using YAML

To create a serverless application by using YAML, you must create a YAML file that defines a Service resource, then apply it by using oc apply.

Procedure

Create a YAML file containing the following sample code:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: event-delivery
  namespace: default
spec:
  template:
    spec:
      containers:
        - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest
          env:
            - name: RESPONSE
              value: "Hello Serverless!"

Navigate to the directory where the YAML file is contained, and deploy the application by applying the YAML file:
```
$ oc apply -f <filename>
```

After the service is created and the application is deployed, Knative creates an immutable revision for this version of the application.

Knative also performs network programming to create a route, ingress, service, and load balancer for your application and automatically scales your pods up and down based on traffic, including inactive pods.

Verifying your serverless application deployment

To verify that your serverless application has been deployed successfully, you must get the application URL created by Knative, and then send a request to that URL and observe the output.

OpenShift Serverless supports the use of both HTTP and HTTPS URLs, however the output from oc get ksvc will always print URLs using the http:// format.

Procedure

Find the application URL:

$ oc get ksvc <service_name>

Example command

$ oc get ksvc event-delivery

Example output

NAME            URL                                        LATESTCREATED         LATESTREADY           READY   REASON
event-delivery   http://event-delivery-default.example.com   event-delivery-4wsd2   event-delivery-4wsd2   True

Make a request to your cluster and observe the output.

Example HTTP request

$ curl http://event-delivery-default.example.com

Example HTTPS request

$ curl https://event-delivery-default.example.com

Example output

Hello Serverless!

Optional. If you receive an error relating to a self-signed certificate in the certificate chain, you can add the --insecure flag to the curl command to ignore the error:
```
$ curl https://event-delivery-default.example.com --insecure
```
Example output
```
Hello Serverless!
```
Self-signed certificates must not be used in a production deployment. This method is only for testing purposes.
Optional. If your OpenShift Container Platform cluster is configured with a certificate that is signed by a certificate authority (CA) but not yet globally configured for your system, you can specify this with the curl command. The path to the certificate can be passed to the curl command by using the --cacert flag:
```
$ curl https://event-delivery-default.example.com --cacert <file>
```
Example output
```
Hello Serverless!
```

Interacting with a serverless application using HTTP2 and gRPC

OpenShift Serverless supports only insecure or edge-terminated routes.

Insecure or edge-terminated routes do not support HTTP2 on OpenShift Container Platform. These routes also do not support gRPC because gRPC is transported by HTTP2.

If you use these protocols in your application, you must call the application using the ingress gateway directly. To do this you must find the ingress gateway’s public address and the application’s specific host.

Procedure

Find the application host. See the instructions in Verifying your serverless application deployment.

Find the ingress gateway’s public address:

$ oc -n knative-serving-ingress get svc kourier

Example output

NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP                                                             PORT(S)                                                                                                                                      AGE
kourier   LoadBalancer   172.30.51.103   a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com   80:31380/TCP,443:31390/TCP   67m

The public address is surfaced in the EXTERNAL-IP field, and in this case is a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com.

Manually set the host header of your HTTP request to the application’s host, but direct the request itself against the public address of the ingress gateway.
```
$ curl -H "Host: hello-default.example.com" a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com
```
Example output
```
Hello Serverless!
```
You can also make a gRPC request by setting the authority to the application’s host, while directing the request against the ingress gateway directly:
```
grpc.Dial(
    "a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com:80",
    grpc.WithAuthority("hello-default.example.com:80"),
    grpc.WithInsecure(),
)
```
Ensure that you append the respective port, 80 by default, to both hosts as shown in the previous example.