Routing - Develop | Serverless | OpenShift Dedicated

Customizing labels and annotations for OpenShift Dedicated routes
Configuring OpenShift Dedicated routes for Knative services
Setting cluster availability to cluster local

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.

Prerequisites

You must have the OpenShift Serverless Operator and Knative Serving installed on your OpenShift Dedicated cluster.
Install the OpenShift CLI (oc).

Procedure

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
metadata:
  name: <service_name>
  labels:
    <label_name>: <label_value>
  annotations:
    <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>

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.

Prerequisites

The OpenShift Serverless Operator and Knative Serving component must be installed on your OpenShift Dedicated cluster.
Install the OpenShift CLI (oc).

Procedure

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.

Create a Knative Service resource:

Example resource

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: <service_name>
  annotations:
    serving.knative.openshift.io/disableRoute: "true"
spec:
  template:
    spec:
      containers:
      - image: <image>
...

Apply the Service resource:
```
$ oc apply -f <filename>
```

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

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.

Create a Route resource in the knative-serving-ingress namespace:

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  annotations:
    haproxy.router.openshift.io/timeout: 600s (1)
  name: <route_name> (2)
  namespace: knative-serving-ingress (3)
spec:
  host: <service_host> (4)
  port:
    targetPort: http2
  to:
    kind: Service
    name: kourier
    weight: 100
  tls:
    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.

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.

Prerequisites

The OpenShift Serverless Operator and Knative Serving are installed on the cluster.
You have created a Knative service.

Procedure

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
```

Verification

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