Knative leverages OpenShift Dedicated TLS termination to provide routing for Knative services. When a Knative service is created, an OpenShift Dedicated route is automatically created for the service. This route is managed by the OpenShift Serverless Operator. The OpenShift Dedicated route exposes the Knative service through the same domain as the OpenShift Dedicated cluster.

You can disable Operator control of OpenShift Dedicated routing so that you can configure a Knative route to directly use your TLS certificates instead.

Knative routes can also be used alongside the OpenShift Dedicated route to provide additional fine-grained routing capabilities, such as traffic splitting.

Customizing labels and annotations for OpenShift Dedicated routes

OpenShift Dedicated routes support the use of custom labels and annotations, which you can configure by modifying the metadata spec of a Knative service. Custom labels and annotations are propagated from the service to the Knative route, then to the Knative ingress, and finally to the OpenShift Dedicated route.

  • You must have the OpenShift Serverless Operator and Knative Serving installed on your OpenShift Dedicated cluster.

  • Install the OpenShift CLI (oc).

  1. Create a Knative service that contains the label or annotation that you want to propagate to the OpenShift Dedicated route:

    • To create a service by using YAML:

      Example service created by using YAML
      apiVersion: serving.knative.dev/v1
      kind: Service
        name: <service_name>
          <label_name>: <label_value>
          <annotation_name>: <annotation_value>
    • To create a service by using the Knative (kn) CLI, enter:

      Example service created by using a kn command
      $ kn service create <service_name> \
        --image=<image> \
        --annotation <annotation_name>=<annotation_value> \
        --label <label_value>=<label_value>
  2. Verify that the OpenShift Dedicated route has been created with the annotation or label that you added by inspecting the output from the following command:

    Example command for verification
    $ oc get routes.route.openshift.io \
         -l serving.knative.openshift.io/ingressName=<service_name> \ (1)
         -l serving.knative.openshift.io/ingressNamespace=<service_namespace> \ (2)
         -n knative-serving-ingress -o yaml \
             | grep -e "<label_name>: \"<label_value>\""  -e "<annotation_name>: <annotation_value>" (3)
    1 Use the name of your service.
    2 Use the namespace where your service was created.
    3 Use your values for the label and annotation names and values.

Configuring OpenShift Dedicated routes for Knative services

If you want to configure a Knative service to use your TLS certificate on OpenShift Dedicated, you must disable the automatic creation of a route for the service by the OpenShift Serverless Operator and instead manually create a route for the service.

When you complete the following procedure, the default OpenShift Dedicated route in the knative-serving-ingress namespace is not created. However, the Knative route for the application is still created in this namespace.

  • The OpenShift Serverless Operator and Knative Serving component must be installed on your OpenShift Dedicated cluster.

  • Install the OpenShift CLI (oc).

  1. Create a Knative service that includes the serving.knative.openshift.io/disableRoute=true annotation:

    The serving.knative.openshift.io/disableRoute=true annotation instructs OpenShift Serverless to not automatically create a route for you. However, the service still shows a URL and reaches a status of Ready. This URL does not work externally until you create your own route with the same hostname as the hostname in the URL.

    1. Create a Knative Service resource:

      Example resource
      apiVersion: serving.knative.dev/v1
      kind: Service
        name: <service_name>
          serving.knative.openshift.io/disableRoute: "true"
            - image: <image>
    2. Apply the Service resource:

      $ oc apply -f <filename>
    3. Optional. Create a Knative service by using the kn service create command:

      Example kn command
      $ kn service create <service_name> \
        --image=gcr.io/knative-samples/helloworld-go \
        --annotation serving.knative.openshift.io/disableRoute=true
  2. Verify that no OpenShift Dedicated route has been created for the service:

    Example command
    $ $ oc get routes.route.openshift.io \
      -l serving.knative.openshift.io/ingressName=$KSERVICE_NAME \
      -l serving.knative.openshift.io/ingressNamespace=$KSERVICE_NAMESPACE \
      -n knative-serving-ingress

    You will see the following output:

    No resources found in knative-serving-ingress namespace.
  3. Create a Route resource in the knative-serving-ingress namespace:

    apiVersion: route.openshift.io/v1
    kind: Route
        haproxy.router.openshift.io/timeout: 600s (1)
      name: <route_name> (2)
      namespace: knative-serving-ingress (3)
      host: <service_host> (4)
        targetPort: http2
        kind: Service
        name: kourier
        weight: 100
        insecureEdgeTerminationPolicy: Allow
        termination: edge (5)
        key: |-
          -----BEGIN PRIVATE KEY-----
          -----END PRIVATE KEY-----
        certificate: |-
          -----BEGIN CERTIFICATE-----
          -----END CERTIFICATE-----
        caCertificate: |-
          -----BEGIN CERTIFICATE-----
          -----END CERTIFICATE----
      wildcardPolicy: None
    1 The timeout value for the OpenShift Dedicated route. You must set the same value as the max-revision-timeout-seconds setting (600s by default).
    2 The name of the OpenShift Dedicated route.
    3 The namespace for the OpenShift Dedicated route. This must be knative-serving-ingress.
    4 The hostname for external access. You can set this to <service_name>-<service_namespace>.<domain>.
    5 The certificates you want to use. Currently, only edge termination is supported.
  4. Apply the Route resource:

    $ oc apply -f <filename>

Setting cluster availability to cluster local

By default, Knative services are published to a public IP address. Being published to a public IP address means that Knative services are public applications, and have a publicly accessible URL.

Publicly accessible URLs are accessible from outside of the cluster. However, developers may need to build back-end services that are only be accessible from inside the cluster, known as private services. Developers can label individual services in the cluster with the networking.knative.dev/visibility=cluster-local label to make them private.

For OpenShift Serverless 1.15.0 and newer versions, the serving.knative.dev/visibility label is no longer available. You must update existing services to use the networking.knative.dev/visibility label instead.

  • The OpenShift Serverless Operator and Knative Serving are installed on the cluster.

  • You have created a Knative service.

  • Set the visibility for your service by adding the networking.knative.dev/visibility=cluster-local label:

    $ oc label ksvc <service_name> networking.knative.dev/visibility=cluster-local
  • Check that the URL for your service is now in the format http://<service_name>.<namespace>.svc.cluster.local, by entering the following command and reviewing the output:

    $ oc get ksvc
    Example output
    NAME            URL                                                                         LATESTCREATED     LATESTREADY       READY   REASON
    hello           http://hello.default.svc.cluster.local                                      hello-tx2g7       hello-tx2g7       True