Chapter 3. Configuring OpenShift Serverless applications
Chapter 3. Configuring OpenShift Serverless applications 3.1. Multi-container support for Serving You can deploy a multi-container pod by using a single Knative service. This method is useful for separating application responsibilities into smaller, specialized parts. 3.1.1. Configuring a multi-container service Multi-container support is enabled by default. You can create a multi-container pod by specifiying multiple containers in the service. Procedure 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. 3.2. EmptyDir volumes emptyDir volumes are empty volumes that are created when a pod is created, and are used to provide temporary working disk space. emptyDir volumes are deleted when the pod they were created for is deleted. 3.2.1. Configuring the EmptyDir extension The kubernetes.podspec-volumes-emptydir extension controls whether emptyDir volumes can be used with Knative Serving. To enable using emptyDir volumes, you must modify the KnativeServing custom resource (CR) to include the following YAML: Example KnativeServing CR apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving spec: config: features: kubernetes.podspec-volumes-emptydir: enabled ... 3.3. Persistent Volume Claims for Serving Some serverless applications require permanent data storage. By configuring different volume types, you can provide data storage for Knative services. Serving supports mounting of the volume types such as secret , configMap , projected , and emptyDir . You can configure persistent volume claims (PVCs) for your Knative services. The Persistent volume types are implemented as plugins. To determine if there are any persistent volume types available, you can check the available or installed storage classes in your cluster. Persistent volumes are supported, but require a feature flag to be enabled. Warning The mounting of large volumes can lead to a considerable delay in the start time of the application. 3.3.1. Enabling PVC support Procedure 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. 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. 3.3.2. Additional resources for OpenShift Container Platform Understanding persistent storage 3.4. Init containers Init containers are specialized containers that are run before application containers in a pod. They are generally used to implement initialization logic for an application, which may include running setup scripts or downloading required configurations. You can enable the use of init containers for Knative services by modifying the KnativeServing custom resource (CR). Note Init containers may cause longer application start-up times and should be used with caution for serverless applications, which are expected to scale up and down frequently. 3.4.1. Enabling init containers Prerequisites You have installed OpenShift Serverless Operator and Knative Serving on your cluster. You have cluster administrator permissions on OpenShift Container Platform, or you have cluster or dedicated administrator permissions on Red Hat OpenShift Service on AWS or OpenShift Dedicated. Procedure Enable the use of init containers by adding the kubernetes.podspec-init-containers flag to the KnativeServing CR: Example KnativeServing CR apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving spec: config: features: kubernetes.podspec-init-containers: enabled ... 3.5. Resolving image tags to digests If the Knative Serving controller has access to the container registry, Knative Serving resolves image tags to a digest when you create a revision of a service. This is known as tag-to-digest resolution , and helps to provide consistency for deployments. 3.5.1. Tag-to-digest resolution To give the controller access to the container registry on OpenShift Container Platform, you must create a secret and then configure controller custom certificates. You can configure controller custom certificates by modifying the controller-custom-certs spec in the KnativeServing custom resource (CR). The secret must reside in the same namespace as the KnativeServing CR. If a secret is not included in the KnativeServing CR, this setting defaults to using public key infrastructure (PKI). When using PKI, the cluster-wide certificates are automatically injected into the Knative Serving controller by using the config-service-sa config map. The OpenShift Serverless Operator populates the config-service-sa config map with cluster-wide certificates and mounts the config map as a volume to the controller. 3.5.1.1. Configuring tag-to-digest resolution by using a secret If the controller-custom-certs spec uses the Secret type, the secret is mounted as a secret volume. Knative components consume the secret directly, assuming that the secret has the required certificates. Prerequisites You have cluster administrator permissions on OpenShift Container Platform, or you have cluster or dedicated administrator permissions on Red Hat OpenShift Service on AWS or OpenShift Dedicated. You have installed the OpenShift Serverless Operator and Knative Serving on your cluster. Procedure Create a secret: Example command USD oc -n knative-serving create secret generic custom-secret --from-file=<secret_name>.crt=<path_to_certificate> Configure the controller-custom-certs spec in the KnativeServing custom resource (CR) to use the Secret type: Example KnativeServing CR apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving namespace: knative-serving spec: controller-custom-certs: name: custom-secret type: Secret 3.6. Configuring TLS authentication You can use Transport Layer Security (TLS) to encrypt Knative traffic and for authentication. TLS is the only supported method of traffic encryption for Knative Kafka. Red Hat recommends using both SASL and TLS together for Knative broker for Apache Kafka resources. Note If you want to enable internal TLS with a Red Hat OpenShift Service Mesh integration, you must enable Service Mesh with mTLS instead of the internal encryption explained in the following procedure. For OpenShift Container Platform and Red Hat OpenShift Service on AWS, see the documentation for Enabling Knative Serving metrics when using Service Mesh with mTLS . 3.6.1. Enabling TLS authentication for internal traffic OpenShift Serverless supports TLS edge termination by default, so that HTTPS traffic from end users is encrypted. However, internal traffic behind the OpenShift route is forwarded to applications by using plain data. By enabling TLS for internal traffic, the traffic sent between components is encrypted, which makes this traffic more secure. Note If you want to enable internal TLS with a Red Hat OpenShift Service Mesh integration, you must enable Service Mesh with mTLS instead of the internal encryption explained in the following procedure. Important Internal TLS encryption support is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope . Prerequisites You have installed the OpenShift Serverless Operator and Knative Serving. You have installed the OpenShift ( oc ) CLI. Procedure Create or update your KnativeServing resource and make sure that it includes the internal-encryption: "true" field in the spec: ... spec: config: network: internal-encryption: "true" ... Restart the activator pods in the knative-serving namespace to load the certificates: USD oc delete pod -n knative-serving --selector app=activator Additional resources Configuring TLS authentication for the Knative broker for Apache Kafka Configuring TLS authentication for channels for Apache Kafka Enabling Knative Serving metrics when using Service Mesh with mTLS 3.7. Configuring Kourier Kourier is a lightweight Kubernetes-native Ingress for Knative Serving. Kourier acts as a gateway for Knative, routing HTTP traffic to Knative services. 3.7.1. Customizing kourier-bootstrap for Kourier getaways The Envoy proxy component in Kourier handles inbound and outbound HTTP traffic for the Knative services. By default, Kourier contains an Envoy bootstrap configuration in the kourier-bootstrap configuration map in the knative-serving-ingress namespace. You can change this configuration. Prerequisites You have installed the OpenShift Serverless Operator and Knative Serving. You have cluster administrator permissions on OpenShift Container Platform, or you have cluster or dedicated administrator permissions on Red Hat OpenShift Service on AWS or OpenShift Dedicated. Procedure Specify a custom bootstrapping configuration map by changing the spec.ingress.kourier.bootstrap-configmap field in the KnativeServing custom resource (CR): Example KnativeServing CR apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving namespace: knative-serving spec: config: network: ingress-class: kourier.ingress.networking.knative.dev ingress: kourier: bootstrap-configmap: my-configmap enabled: true # ... 3.8. Restrictive network policies 3.8.1. Clusters with restrictive network policies If you are using a cluster that multiple users have access to, your cluster might use network policies to control which pods, services, and namespaces can communicate with each other over the network. If your cluster uses restrictive network policies, it is possible that Knative system pods are not able to access your Knative application. For example, if your namespace has the following network policy, which denies all requests, Knative system pods cannot access your Knative application: Example NetworkPolicy object that denies all requests to the namespace kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: deny-by-default namespace: example-namespace spec: podSelector: ingress: [] 3.8.2. Enabling communication with Knative applications on a cluster with restrictive network policies To allow access to your applications from Knative system pods, you must add a label to each of the Knative system namespaces, and then create a NetworkPolicy object in your application namespace that allows access to the namespace for other namespaces that have this label. Important A network policy that denies requests to non-Knative services on your cluster still prevents access to these services. However, by allowing access from Knative system namespaces to your Knative application, you are allowing access to your Knative application from all namespaces in the cluster. If you do not want to allow access to your Knative application from all namespaces on the cluster, you might want to use JSON Web Token authentication for Knative services instead. JSON Web Token authentication for Knative services requires Service Mesh. Prerequisites Install the OpenShift CLI ( oc ). OpenShift Serverless Operator and Knative Serving are installed on your cluster. Procedure Add the knative.openshift.io/system-namespace=true label to each Knative system namespace that requires access to your application: Label the knative-serving namespace: USD oc label namespace knative-serving knative.openshift.io/system-namespace=true Label the knative-serving-ingress namespace: USD oc label namespace knative-serving-ingress knative.openshift.io/system-namespace=true Label the knative-eventing namespace: USD oc label namespace knative-eventing knative.openshift.io/system-namespace=true Label the knative-kafka namespace: USD oc label namespace knative-kafka knative.openshift.io/system-namespace=true 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.
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 apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving spec: config: features: kubernetes.podspec-volumes-emptydir: enabled spec: config: features: "kubernetes.podspec-persistent-volume-claim": enabled "kubernetes.podspec-persistent-volume-write": enabled apiVersion: v1 kind: PersistentVolumeClaim metadata: name: example-pv-claim namespace: my-ns spec: accessModes: - ReadWriteMany storageClassName: ocs-storagecluster-cephfs resources: requests: storage: 1Gi 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 apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving spec: config: features: kubernetes.podspec-init-containers: enabled oc -n knative-serving create secret generic custom-secret --from-file=<secret_name>.crt=<path_to_certificate> apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving namespace: knative-serving spec: controller-custom-certs: name: custom-secret type: Secret spec: config: network: internal-encryption: "true" oc delete pod -n knative-serving --selector app=activator apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving namespace: knative-serving spec: config: network: ingress-class: kourier.ingress.networking.knative.dev ingress: kourier: bootstrap-configmap: my-configmap enabled: true kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: deny-by-default namespace: example-namespace spec: podSelector: ingress: [] oc label namespace knative-serving knative.openshift.io/system-namespace=true oc label namespace knative-serving-ingress knative.openshift.io/system-namespace=true oc label namespace knative-eventing knative.openshift.io/system-namespace=true oc label namespace knative-kafka knative.openshift.io/system-namespace=true 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