Chapter 4. Configuring OpenShift Serverless applications

Procedure

1. Modify your service to include additional containers. Only one container can handle requests, so specify ports for exactly one container. Here is an example configuration with two containers:

   Multiple containers configuration

   apiVersion: serving.knative.dev/v1
   kind: Service
   ...
   spec:
     template:
       spec:
         containers:
           - name: first-container 1
             image: gcr.io/knative-samples/helloworld-go
             ports:
               - containerPort: 8080 2
           - name: second-container 3
             image: gcr.io/knative-samples/helloworld-java

   1

   First container configuration.

   2

   Port specification for the first container.

   3

   Second container configuration.

Procedure

1. Configure multi-container probing for your service by enabling the multi-container-probing feature in the KnativeServing CR.

   Multi-container probing configuration

   ...
   spec:
     config:
       features:
         "multi-container-probing": enabled 1
   ...

   1

   Enabled multi-container-probing feature

2. Apply the updated KnativeServing CR.

   $ oc apply -f <filename>

3. Modify your multi-container service to include the specified probes.

   Multi-container probing

   apiVersion: serving.knative.dev/v1
   kind: Service
   ...
   spec:
    template:
      spec:
        containers:
          - name: first-container
            image: ghcr.io/knative/helloworld-go:latest
            ports:
              - containerPort: 8080
            readinessProbe: 1
              httpGet:
                port: 8080
          - name: second-container
            image: gcr.io/knative-samples/helloworld-java
            readinessProbe: 2
              httpGet:
                port: 8090

   1

   Readiness probe of the first container

   2

   Readiness probe of the second container

Procedure

1. To enable Knative Serving to use PVCs and write to them, modify the KnativeServing custom resource (CR) to include the following YAML:

   Enabling PVCs with write access

   ...
   spec:
     config:
       features:
         "kubernetes.podspec-persistent-volume-claim": enabled
         "kubernetes.podspec-persistent-volume-write": enabled
   ...

   • The kubernetes.podspec-persistent-volume-claim extension controls whether persistent volumes (PVs) can be used with Knative Serving.
   • The kubernetes.podspec-persistent-volume-write extension controls whether PVs are available to Knative Serving with the write access.

2. To claim a PV, modify your service to include the PV configuration. For example, you might have a persistent volume claim with the following configuration:

   Note

   Use the storage class that supports the access mode you are requesting. For example, you can use the ocs-storagecluster-cephfs storage class for the ReadWriteMany access mode.

   The ocs-storagecluster-cephfs storage class is supported and comes from Red Hat OpenShift Data Foundation.

   PersistentVolumeClaim configuration

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: example-pv-claim
     namespace: my-ns
   spec:
     accessModes:
       - ReadWriteMany
     storageClassName: ocs-storagecluster-cephfs
     resources:
       requests:
         storage: 1Gi

   In this case, to claim a PV with write access, modify your service as follows:

   Knative service PVC configuration

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     namespace: my-ns
   ...
   spec:
    template:
      spec:
        containers:
            ...
            volumeMounts: 1
              - mountPath: /data
                name: mydata
                readOnly: false
        volumes:
          - name: mydata
            persistentVolumeClaim: 2
              claimName: example-pv-claim
              readOnly: false 3

   1

   Volume mount specification.

   2

   Persistent volume claim specification.

   3

   Flag that enables read-only access.

   Note

   To successfully use persistent storage in Knative services, you need additional configuration, such as the user permissions for the Knative container user.

Procedure

1. Add the knative.openshift.io/system-namespace=true label to each Knative system namespace that requires access to your application:

   1. Label the knative-serving namespace:

      $ oc label namespace knative-serving knative.openshift.io/system-namespace=true

   2. Label the knative-serving-ingress namespace:

      $ oc label namespace knative-serving-ingress knative.openshift.io/system-namespace=true

   3. Label the knative-eventing namespace:

      $ oc label namespace knative-eventing knative.openshift.io/system-namespace=true

   4. Label the knative-kafka namespace:

      $ oc label namespace knative-kafka knative.openshift.io/system-namespace=true

2. Create a NetworkPolicy object in your application namespace to allow access from namespaces with the knative.openshift.io/system-namespace label:

   Example NetworkPolicy object

   apiVersion: networking.k8s.io/v1
   kind: NetworkPolicy
   metadata:
     name: <network_policy_name> 1
     namespace: <namespace> 2
   spec:
     ingress:
     - from:
       - namespaceSelector:
           matchLabels:
             knative.openshift.io/system-namespace: "true"
     podSelector: {}
     policyTypes:
     - Ingress

   1

   Provide a name for your network policy.

   2

   The namespace where your application exists.