×

Creating serverless applications using the Administrator perspective

Serverless applications are created and deployed as Kubernetes services, defined by a route and a configuration, and contained in a YAML file. To deploy a serverless application using OpenShift Serverless, you must create a Knative Service object.

Example Knative Service object YAML file
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: hello (1)
  namespace: default (2)
spec:
  template:
    spec:
      containers:
        - image: docker.io/openshift/hello-openshift (3)
          env:
            - name: RESPONSE (4)
              value: "Hello Serverless!"
1 The name of the application.
2 The namespace the application uses.
3 The image of the application.
4 The environment variable printed out by the sample application.

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.

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
  1. Navigate to the ServerlessServing page.

  2. In the Create list, select Service.

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

  4. Click Create.

Mapping a custom domain to a service by using the Administrator perspective

Knative services are automatically assigned a default domain name based on your cluster configuration. For example, <service_name>-<namespace>.example.com. You can customize the domain for your Knative service by mapping a custom domain name that you own to a Knative service.

You can do this by creating a DomainMapping resource for the service. You can also create multiple DomainMapping resources to map multiple domains and subdomains to a single service.

If you have cluster administrator permissions, you can create a DomainMapping custom resource (CR) by using the Administrator perspective in the OpenShift Container Platform web console.

Prerequisites
  • You have logged in to the web console.

  • You are in the Administrator perspective.

  • You have installed the OpenShift Serverless Operator.

  • You have installed Knative Serving.

  • You have created a project or have access to a project with the appropriate roles and permissions to create applications and other workloads in OpenShift Container Platform.

  • You have created a Knative service and control a custom domain that you want to map to that service.

    Your custom domain must point to the IP address of the OpenShift Container Platform cluster.

Procedure
  1. Navigate to CustomResourceDefinitions and use the search box to find the DomainMapping custom resource definition (CRD).

  2. Click the DomainMapping CRD, then navigate to the Instances tab.

  3. Click Create DomainMapping.

  4. Modify the YAML for the DomainMapping CR so that it includes the following information for your instance:

    apiVersion: serving.knative.dev/v1alpha1
    kind: DomainMapping
    metadata:
     name: <domain_name> (1)
     namespace: <namespace> (2)
    spec:
     ref:
       name: <target_name> (3)
       kind: <target_type> (4)
       apiVersion: serving.knative.dev/v1
    1 The custom domain name that you want to map to the target CR.
    2 The namespace of both the DomainMapping CR and the target CR.
    3 The name of the target CR to map to the custom domain.
    4 The type of CR being mapped to the custom domain.
    Example domain mapping to a Knative service
    apiVersion: serving.knative.dev/v1alpha1
    kind: DomainMapping
    metadata:
     name: custom-ksvc-domain.example.com
     namespace: default
    spec:
     ref:
       name: example-service
       kind: Service
       apiVersion: serving.knative.dev/v1
Verification
  • Access the custom domain by using a curl request. For example:

    Example command
    $ curl custom-ksvc-domain.example.com
    Example output
    Hello OpenShift!

Creating an event source by using the Administrator perspective

A Knative event source can be any Kubernetes object that generates or imports cloud events, and relays those events to another endpoint, known as a sink. Sourcing events is critical to developing a distributed system that reacts to events.

Prerequisites
  • The OpenShift Serverless Operator and Knative Eventing are installed on your OpenShift Container Platform cluster.

  • You have logged in to the web console and are in the Administrator perspective.

  • You have cluster administrator permissions for OpenShift Container Platform.

Procedure
  1. In the Administrator perspective of the OpenShift Container Platform web console, navigate to ServerlessEventing.

  2. In the Create list, select Event Source. You will be directed to the Event Sources page.

  3. Select the event source type that you want to create.

Creating a broker by using the Administrator perspective

Brokers can be used in combination with triggers to deliver events from an event source to an event sink. Events are sent from an event source to a broker as an HTTP POST request. After events have entered the broker, they can be filtered by CloudEvent attributes using triggers, and sent as an HTTP POST request to an event sink.