Chapter 4. Configuring OpenShift Serverless applications

4.1. Multi-container support for Serving
Copiar enlace

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.

4.1.1. Configuring a multi-container service
Copiar enlace

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 
          image: gcr.io/knative-samples/helloworld-go
          ports:
            - containerPort: 8080 
        - name: second-container 
          image: gcr.io/knative-samples/helloworld-java

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

Copy to Clipboard

Toggle word wrap

1: First container configuration.
2: Port specification for the first container.
3: Second container configuration.

4.1.2. Probing a multi-container service
Copiar enlace

You can specify readiness and liveness probes for multiple containers. This feature is not enabled by default and you must configure it using the KnativeServing custom resource (CR).

Procedure

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 
...
```
```
...
spec:
  config:
    features:
      "multi-container-probing": enabled 
```
1
```
...
```
Copy to Clipboard Toggle word wrap
1
Enabled multi-container-probing feature
Apply the updated KnativeServing CR.
```
oc apply -f <filename>
```
```
$ oc apply -f <filename>
```
Copy to Clipboard Toggle word wrap

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: 
           httpGet:
             port: 8080
       - name: second-container
         image: gcr.io/knative-samples/helloworld-java
         readinessProbe: 
           httpGet:
             port: 8090

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

Copy to Clipboard

Toggle word wrap

1: Readiness probe of the first container
2: Readiness probe of the second container

4.1.2.1. Additional resources
Copiar enlace

General understanding of Knative Probing

4.2. EmptyDir volumes
Copiar enlace

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.

4.2.1. Configuring the EmptyDir extension
Copiar enlace

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

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
spec:
  config:
    features:
      kubernetes.podspec-volumes-emptydir: enabled
...

Copy to Clipboard

Toggle word wrap

4.3. Persistent Volume Claims for Serving
Copiar enlace

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.

4.3.1. Enabling PVC support
Copiar enlace

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
...
```
```
...
spec:
  config:
    features:
      "kubernetes.podspec-persistent-volume-claim": enabled
      "kubernetes.podspec-persistent-volume-write": enabled
...
```
Copy to Clipboard Toggle word wrap
- 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

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

Copy to Clipboard

Toggle word wrap

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: 
           - mountPath: /data
             name: mydata
             readOnly: false
     volumes:
       - name: mydata
         persistentVolumeClaim: 
           claimName: example-pv-claim
           readOnly: false

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

Copy to Clipboard

Toggle word wrap

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.

4.4. Init containers
Copiar enlace

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.

4.4.1. Enabling init containers
Copiar enlace

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

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
spec:
  config:
    features:
      kubernetes.podspec-init-containers: enabled
...

Copy to Clipboard

Toggle word wrap

4.5. Startup probes
Copiar enlace

Startup probes verify whether a service has started successfully, helping to reduce cold start times for containers with slow startup processes. Startup probes run only during the container’s initialization phase and do not execute periodically. If a startup probe fails, the container adheres to the defined restartPolicy.

4.5.1. Progress deadline
Copiar enlace

By default, services have a progress deadline that defines the time limit for a service to complete its initial startup. When using startup probes, ensure that the progress deadline is set to exceed the maximum time required by the startup probes. If the progress deadline is set too low, the startup probes might not finish before the deadline is reached, which can prevent the service from starting.

Consider increasing the progress deadline if you encounter any of these conditions in your deployment:

The service image takes a long time to pull due to its size.
The service takes a long time to become READY because of initial cache priming.
The cluster relies on autoscaling to allocate resources for new pods.

4.5.2. Configuring startup probing
Copiar enlace

For OpenShift Serverless Serving, startup probes are not defined by default. You can define startup probes for your containers in your deployment configuration.

Procedure

Define startup probes for your service by modifying your deployment configuration. The following example shows a configuration with two containers:

Example of defined starup probes

apiVersion: serving.knative.dev/v1
kind: Service
# ...
spec:
  template:
    spec:
       containers:
        - name: first-container
          image: <image>
          ports:
            - containerPort: 8080
          # ...
          startupProbe: 
          httpGet:
            port: 8080
            path: "/"
        - name: second-container
          image: <image>
          # ...
          startupProbe: 
          httpGet:
            port: 8081
            path: "/"

apiVersion: serving.knative.dev/v1
kind: Service
# ...
spec:
  template:
    spec:
       containers:
        - name: first-container
          image: <image>
          ports:
            - containerPort: 8080
          # ...
          startupProbe:

1


          httpGet:
            port: 8080
            path: "/"
        - name: second-container
          image: <image>
          # ...
          startupProbe:

2


          httpGet:
            port: 8081
            path: "/"

Copy to Clipboard

Toggle word wrap

1: Startup probe of the first-container.
2: Startup probe of the second-container.

4.5.3. Configuring the progress deadline
Copiar enlace

You can configure progress deadline settings to specify the maximum time allowed for your deployment to progress before the system reports a failure for the Knative Revision. This time limit can be specified in seconds or minutes.

To configure the progress deadline effectively, consider the following parameters:

initialDelaySeconds
failureThreshold
periodSeconds
timeoutSeconds

If the initial scale is not achieved within the specified time limit, the Knative Autoscaler component scales the revision to 0, and the Knative service enters a terminal Failed state.

By default, the progress deadline is set to 600 seconds. This value is specified as a Golang time.Duration string and must be rounded to the nearest second.

Procedure

To configure the progress deadline setting, use an annotation in your deployment configuration.

Example of progress deadline set to 60 seconds

apiVersion: serving.knative.dev/v1
kind: Service
...
spec:
  template:
    metadata:
       annotations:
            serving.knative.dev/progress-deadline: "60s"
    spec:
        containers:
            - image: ghcr.io/knative/helloworld-go:latest

apiVersion: serving.knative.dev/v1
kind: Service
...
spec:
  template:
    metadata:
       annotations:
            serving.knative.dev/progress-deadline: "60s"
    spec:
        containers:
            - image: ghcr.io/knative/helloworld-go:latest

Copy to Clipboard

Toggle word wrap

4.6. Resolving image tags to digests
Copiar enlace

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.

4.6.1. Tag-to-digest resolution
Copiar enlace

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.

4.6.1.1. Configuring tag-to-digest resolution by using a secret
Copiar enlace

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

$ oc -n knative-serving create secret generic custom-secret --from-file=<secret_name>.crt=<path_to_certificate>

$ oc -n knative-serving create secret generic custom-secret --from-file=<secret_name>.crt=<path_to_certificate>

Copy to Clipboard

Toggle word wrap

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

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  controller-custom-certs:
    name: custom-secret
    type: Secret

Copy to Clipboard

Toggle word wrap

4.7. Configuring deployment resources
Copiar enlace

In Knative Serving, the config-deployment config map contains settings that determine how Kubernetes Deployment resources are configured for Knative services. In OpenShift Serverless Serving, you can configure these settings in the deployment section of your KnativeServing custom resource (CR).

You can use the deployment section to configure the following:

Tag resolution
Runtime environments
Progress deadlines

4.7.1. Skipping tag resolution
Copiar enlace

Skipping tag resolution in OpenShift Serverless Serving can speed up deployments by avoiding unnecessary queries to the container registry, reducing latency and dependency on registry availability.

You can configure Serving to skip tag resolution by modifying the registriesSkippingTagResolving setting in your KnativeServing custom resource (CR).

Procedure

In your KnativeServing CR, modify the registriesSkippingTagResolving setting with the list of registries for which tag resoution will be skipped:

Example of configured tag resolution skipping

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
spec:
  config:
    deployment:
      registriesSkippingTagResolving: "registry.example.com, another.registry.com"

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
spec:
  config:
    deployment:
      registriesSkippingTagResolving: "registry.example.com, another.registry.com"

Copy to Clipboard

Toggle word wrap

4.7.2. Configuring selectable RuntimeClassName
Copiar enlace

You can configure OpenShift Serverless Serving to set a specific RuntimeClassName resource for Deployments by updating the runtime-class-name setting in your KnativeServing custom resource (CR).

This setting interacts with service labels, applying either the default RuntimeClassName or the one that matches the most labels associated with the service.

Procedure

In your KnativeServing CR, configure the runtime-class-name setting:

Example of configured runtime-class-name setting

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
spec:
  config:
    deployment:
      runtime-class-name: |
        kata: {}
        gvisor:
          selector:
            my-label: selector

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
spec:
  config:
    deployment:
      runtime-class-name: |
        kata: {}
        gvisor:
          selector:
            my-label: selector

Copy to Clipboard

Toggle word wrap

4.7.3. Progress deadline
Copiar enlace

By default, services have a progress deadline that defines the time limit for a service to complete its initial startup.

Consider increasing the progress deadline if you encounter any of these conditions in your deployment:

The service image takes a long time to pull due to its size.
The service takes a long time to become READY because of initial cache priming.
The cluster relies on autoscaling to allocate resources for new pods.

If the initial scale is not achieved within the specified time limit, the Knative Autoscaler component scales the revision to 0, and the service enters a terminal Failed state.

4.7.3.1. Configuring the progress deadline
Copiar enlace

Configure progress deadline settings to set the maximum time allowed in seconds or minutes for deployment progress before the system reports a Knative Revision failure.

By default, the progress deadline is set to 600 seconds. This value is specified as a Go time.Duration string and must be rounded to the nearest second.

Procedure

Configure progress deadline by modifying your KnativeServing custom resource (CR).

In your KnativeServing CR, set the value of progressDeadline:

Example of progress deadline set to 60 seconds

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
spec:
  config:
    deployment:
      progressDeadline: "60s"

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
spec:
  config:
    deployment:
      progressDeadline: "60s"

Copy to Clipboard

Toggle word wrap

4.8. Configuring Kourier
Copiar enlace

Kourier is a lightweight Kubernetes-native Ingress for Knative Serving. Kourier acts as a gateway for Knative, routing HTTP traffic to Knative services.

4.8.1. Accessing the current Envoy bootstrap configuration
Copiar enlace

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.

Procedure

To get the current Envoy bootstrap configuration, run the following command:

Example command

oc get cm kourier-bootstrap -n knative-serving-ingress -o yaml

$ oc get cm kourier-bootstrap -n knative-serving-ingress -o yaml

Copy to Clipboard

Toggle word wrap

For example, with the default configuration, the example command produces the output that contains the following excerpts:

Example output

Name:         kourier-bootstrap
Namespace:    knative-serving-ingress
Labels:       app.kubernetes.io/component=net-kourier
              app.kubernetes.io/name=knative-serving
              app.kubernetes.io/version=release-v1.10
              networking.knative.dev/ingress-provider=kourier
              serving.knative.openshift.io/ownerName=knative-serving
              serving.knative.openshift.io/ownerNamespace=knative-serving
Annotations:  manifestival: new

Name:         kourier-bootstrap
Namespace:    knative-serving-ingress
Labels:       app.kubernetes.io/component=net-kourier
              app.kubernetes.io/name=knative-serving
              app.kubernetes.io/version=release-v1.10
              networking.knative.dev/ingress-provider=kourier
              serving.knative.openshift.io/ownerName=knative-serving
              serving.knative.openshift.io/ownerNamespace=knative-serving
Annotations:  manifestival: new

Copy to Clipboard

Toggle word wrap

Example Data output

dynamic_resources:
  ads_config:
    transport_api_version: V3
    api_type: GRPC
    rate_limit_settings: {}
    grpc_services:
    - envoy_grpc: {cluster_name: xds_cluster}
  cds_config:
    resource_api_version: V3
    ads: {}
  lds_config:
    resource_api_version: V3
    ads: {}
node:
  cluster: kourier-knative
  id: 3scale-kourier-gateway
static_resources:
  listeners:
    - name: stats_listener
      address:
        socket_address:
          address: 0.0.0.0
          port_value: 9000
      filter_chains:
        - filters:
            - name: envoy.filters.network.http_connection_manager
              typed_config:
                "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
                stat_prefix: stats_server
                http_filters:
                  - name: envoy.filters.http.router
                    typed_config:
                      "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
                route_config:
                  virtual_hosts:
                    - name: admin_interface
                      domains:
                        - "*"
                      routes:
                        - match:
                            safe_regex:
                              regex: '/(certs|stats(/prometheus)?|server_info|clusters|listeners|ready)?'
                            headers:
                              - name: ':method'
                                string_match:
                                  exact: GET
                          route:
                            cluster: service_stats
  clusters:
    - name: service_stats
      connect_timeout: 0.250s
      type: static
      load_assignment:
        cluster_name: service_stats
        endpoints:
          lb_endpoints:
            endpoint:
              address:
                pipe:
                  path: /tmp/envoy.admin
    - name: xds_cluster
      # This keepalive is recommended by envoy docs.
      # https://www.envoyproxy.io/docs/envoy/latest/api-docs/xds_protocol
      typed_extension_protocol_options:
        envoy.extensions.upstreams.http.v3.HttpProtocolOptions:
          "@type": type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions
          explicit_http_config:
            http2_protocol_options:
              connection_keepalive:
                interval: 30s
                timeout: 5s
      connect_timeout: 1s
      load_assignment:
        cluster_name: xds_cluster
        endpoints:
          lb_endpoints:
            endpoint:
              address:
                socket_address:
                  address: "net-kourier-controller.knative-serving-ingress.svc.cluster.local."
                  port_value: 18000
      type: STRICT_DNS
admin:
  access_log:
  - name: envoy.access_loggers.stdout
    typed_config:
      "@type": type.googleapis.com/envoy.extensions.access_loggers.stream.v3.StdoutAccessLog
  address:
    pipe:
      path: /tmp/envoy.admin
layered_runtime:
  layers:
    - name: static-layer
      static_layer:
        envoy.reloadable_features.override_request_timeout_by_gateway_timeout: false

dynamic_resources:
  ads_config:
    transport_api_version: V3
    api_type: GRPC
    rate_limit_settings: {}
    grpc_services:
    - envoy_grpc: {cluster_name: xds_cluster}
  cds_config:
    resource_api_version: V3
    ads: {}
  lds_config:
    resource_api_version: V3
    ads: {}
node:
  cluster: kourier-knative
  id: 3scale-kourier-gateway
static_resources:
  listeners:
    - name: stats_listener
      address:
        socket_address:
          address: 0.0.0.0
          port_value: 9000
      filter_chains:
        - filters:
            - name: envoy.filters.network.http_connection_manager
              typed_config:
                "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
                stat_prefix: stats_server
                http_filters:
                  - name: envoy.filters.http.router
                    typed_config:
                      "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
                route_config:
                  virtual_hosts:
                    - name: admin_interface
                      domains:
                        - "*"
                      routes:
                        - match:
                            safe_regex:
                              regex: '/(certs|stats(/prometheus)?|server_info|clusters|listeners|ready)?'
                            headers:
                              - name: ':method'
                                string_match:
                                  exact: GET
                          route:
                            cluster: service_stats
  clusters:
    - name: service_stats
      connect_timeout: 0.250s
      type: static
      load_assignment:
        cluster_name: service_stats
        endpoints:
          lb_endpoints:
            endpoint:
              address:
                pipe:
                  path: /tmp/envoy.admin
    - name: xds_cluster
      # This keepalive is recommended by envoy docs.
      # https://www.envoyproxy.io/docs/envoy/latest/api-docs/xds_protocol
      typed_extension_protocol_options:
        envoy.extensions.upstreams.http.v3.HttpProtocolOptions:
          "@type": type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions
          explicit_http_config:
            http2_protocol_options:
              connection_keepalive:
                interval: 30s
                timeout: 5s
      connect_timeout: 1s
      load_assignment:
        cluster_name: xds_cluster
        endpoints:
          lb_endpoints:
            endpoint:
              address:
                socket_address:
                  address: "net-kourier-controller.knative-serving-ingress.svc.cluster.local."
                  port_value: 18000
      type: STRICT_DNS
admin:
  access_log:
  - name: envoy.access_loggers.stdout
    typed_config:
      "@type": type.googleapis.com/envoy.extensions.access_loggers.stream.v3.StdoutAccessLog
  address:
    pipe:
      path: /tmp/envoy.admin
layered_runtime:
  layers:
    - name: static-layer
      static_layer:
        envoy.reloadable_features.override_request_timeout_by_gateway_timeout: false

Copy to Clipboard

Toggle word wrap

Example BinaryData output

Events:  <none>

Events:  <none>

Copy to Clipboard

Toggle word wrap

4.8.2. Customizing kourier-bootstrap for Kourier getaways
Copiar enlace

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 map to a custom one.

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
# ...

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
# ...

Copy to Clipboard

Toggle word wrap

4.8.3. Enabling administrator interface access
Copiar enlace

You can change the envoy bootstrap configuration to enable access to the administrator interface.

Important

This procedure assumes sufficient knowledge of Knative, as changing envoy bootstrap configuration might result in Knative failure. Red Hat does not support custom configurations that are not tested or shipped with the product.

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

To enable administrator interface access, locate this configuration in your bootstrapping configuration map:
```
pipe:
  path: /tmp/envoy.admin
```
```
pipe:
  path: /tmp/envoy.admin
```
Copy to Clipboard Toggle word wrap
Substitute it with the following configuration:
```
socket_address: 
  address: 127.0.0.1
  port_value: 9901
```
```
socket_address: 
```
1
```
  address: 127.0.0.1
  port_value: 9901
```
Copy to Clipboard Toggle word wrap
1
This configuration enables access to the Envoy admin interface on the loopback address (127.0.0.1) and port 9901.

Apply the socket_address configuration in the service_stats cluster configuration and in the admin configuration:

The first is in the service_stats cluster configuration:

clusters:
  - name: service_stats
    connect_timeout: 0.250s
    type: static
    load_assignment:
      cluster_name: service_stats
      endpoints:
        lb_endpoints:
          endpoint:
            address:
              socket_address:
                address: 127.0.0.1
                port_value: 9901

clusters:
  - name: service_stats
    connect_timeout: 0.250s
    type: static
    load_assignment:
      cluster_name: service_stats
      endpoints:
        lb_endpoints:
          endpoint:
            address:
              socket_address:
                address: 127.0.0.1
                port_value: 9901

Copy to Clipboard

Toggle word wrap

The second is in the admin configuration:

admin:
  access_log:
    - name: envoy.access_loggers.stdout
      typed_config:
        "@type": type.googleapis.com/envoy.extensions.access_loggers.stream.v3.StdoutAccessLog
  address:
    socket_address:
      address: 127.0.0.1
      port_value: 9901

admin:
  access_log:
    - name: envoy.access_loggers.stdout
      typed_config:
        "@type": type.googleapis.com/envoy.extensions.access_loggers.stream.v3.StdoutAccessLog
  address:
    socket_address:
      address: 127.0.0.1
      port_value: 9901

Copy to Clipboard

Toggle word wrap

4.9. Restrictive network policies
Copiar enlace

4.9.1. Clusters with restrictive network policies
Copiar enlace

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: []

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: deny-by-default
  namespace: example-namespace
spec:
  podSelector:
  ingress: []

Copy to Clipboard

Toggle word wrap

4.9.2. Enabling communication with Knative applications on a cluster with restrictive network policies
Copiar enlace

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:

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

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

Copy to Clipboard

Toggle word wrap

Label the knative-serving-ingress namespace:

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

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

Copy to Clipboard

Toggle word wrap

Label the knative-eventing namespace:

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

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

Copy to Clipboard

Toggle word wrap

Label the knative-kafka namespace:

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

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

Copy to Clipboard

Toggle word wrap

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> 
  namespace: <namespace> 
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          knative.openshift.io/system-namespace: "true"
  podSelector: {}
  policyTypes:
  - Ingress

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

Copy to Clipboard

Toggle word wrap

1: Provide a name for your network policy.
2: The namespace where your application exists.

4.10. Configuring revision timeouts
Copiar enlace

You can configure timeout durations for revisions globally or individually to control the time spent on requests.

4.10.1. Configuring revision timeout
Copiar enlace

You can configure the default number of seconds for the revision timeout based on the request.

Prerequisites

You have installed the OpenShift Serverless Operator and Knative Serving.
You have the required permissions for your cluster:
- Cluster administrator permissions on OpenShift Container Platform
- Cluster administrator or dedicated administrator permissions on Red Hat OpenShift Service on AWS
- Cluster administrator or dedicated administrator permissions on OpenShift Dedicated

Procedure

Choose the appropriate method to configure the revision timeout:

To configure the revision timeout globally, set the revision-timeout-seconds field in the KnativeServing custom resource (CR):

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  config:
    defaults:
      revision-timeout-seconds: "300"

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  config:
    defaults:
      revision-timeout-seconds: "300"

Copy to Clipboard

Toggle word wrap

To configure the timeout per revision by setting the timeoutSeconds field in your service definition:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  namespace: my-ns
spec:
  template:
    spec:
      timeoutSeconds: 300
      containers:
      - image: ghcr.io/knative/helloworld-go:latest

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  namespace: my-ns
spec:
  template:
    spec:
      timeoutSeconds: 300
      containers:
      - image: ghcr.io/knative/helloworld-go:latest

Copy to Clipboard

Toggle word wrap

Note

To set the revision timeout to a value over 600 seconds (10 minutes), you must increase the default OpenShift Container Platform route timeout and the maximum revision timeout.

For instructions on how to configure timeouts for requests exceeding the default 600 seconds (10 minutes), see "Long-running requests".

4.10.2. Configuring maximum revision timeout
Copiar enlace

By seting the maximum revision timeout, you can ensure that no revision can exceed a specific limit. The value of your maximum revision timeout must not exceed the terminationGracePeriodSeconds value of the activator to prevent in-flight requests being disrupted.

Prerequisites

You have installed the OpenShift Serverless Operator and Knative Serving.
You have the required permissions for your cluster:
- Cluster administrator permissions on OpenShift Container Platform
- Cluster administrator or dedicated administrator permissions on Red Hat OpenShift Service on AWS
- Cluster administrator or dedicated administrator permissions on OpenShift Dedicated

Procedure

To configure the maximum revision timeout, set the max-revision-timeout-seconds field in the KnativeServing custom resource (CR):
```
apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  config:
    defaults:
      max-revision-timeout-seconds: "600"
```
```
apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  config:
    defaults:
      max-revision-timeout-seconds: "600"
```
Copy to Clipboard Toggle word wrap
Note
To set the maximum revision timeout to a value over 600 seconds (10 minutes), you must increase the default OpenShift Container Platform route timeout.
For instructions on how to configure timeouts for requests exceeding the default 600 seconds (10 minutes), see "Long-running requests".

4.10.3. Configuring revision response start timeout
Copiar enlace

By setting the revision response start timeout, you can specify the maximum duration in seconds that Serving waits for a revision to start sending network traffic after a request has been routed to it. The revision response start timeout must not exceed the revision timeout. The default duration is 300 seconds (5 minutes).

Prerequisites

You have installed the OpenShift Serverless Operator and Knative Serving.
You have the required permissions for your cluster:
- Cluster administrator permissions on OpenShift Container Platform
- Cluster administrator or dedicated administrator permissions on Red Hat OpenShift Service on AWS
- Cluster administrator or dedicated administrator permissions on OpenShift Dedicated

Procedure

Choose the appropriate method to configure the revision response start timeout:
- To configure the timeout globally, set the revision-response-start-timeout-seconds field in your KnativeServing custom resource (CR). If your required response start timeout exceeds the revision timeout, also adjust the revision-timeout-seconds field accordingly:
  Example of revision response start timeout globally set to 300 seconds (5 minutes)
  apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving namespace: knative-serving spec: config: defaults: revision-timeout-seconds: "600" revision-response-start-timeout-seconds: "300"
  
  Copy to Clipboard Toggle word wrap
- To configure the timeout per revision, set the responseStartTimeoutSeconds field in your service definition. If your required response start timeout exceeds the revision timeout, also adjust the timeoutSeconds field accordingly:
  Example of a service definition with revision response start timeout set to 300 seconds (5 minutes)
  apiVersion: serving.knative.dev/v1 kind: Service metadata: namespace: my-ns spec: template: spec: timeoutSeconds: 600 responseStartTimeoutSeconds: 300 containers: # ...
  
  Copy to Clipboard Toggle word wrap
Note
To set the revision response start timeout and the revision timeout to a value over 600 seconds (10 minutes), you must increase the default OpenShift Container Platform route timeout and the maximum revision timeout.
For instructions on how to configure timeouts for requests exceeding the default 600 seconds (10 minutes), see "Long-running requests".

4.10.4. Configuring revision idle timeout
Copiar enlace

By setting the revision idle timeout, you can specify the maximum duration in seconds a request is allowed to stay open without receiving data from the application. The default duration is 0 (infinite).

Prerequisites

You have installed the OpenShift Serverless Operator and Knative Serving.
You have the required permissions for your cluster:
- Cluster administrator permissions on OpenShift Container Platform
- Cluster administrator or dedicated administrator permissions on Red Hat OpenShift Service on AWS
- Cluster administrator or dedicated administrator permissions on OpenShift Dedicated

Procedure

Choose the appropriate method to configure the revision idle timeout:

To configure the timeout globally, set the revision-idle-timeout-seconds field in your KnativeServing custom resource (CR):

Example of revision idle timeout globally set to 300 seconds (5 minutes)

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  config:
    defaults:
      revision-idle-timeout-seconds: "300"

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  config:
    defaults:
      revision-idle-timeout-seconds: "300"

Copy to Clipboard

Toggle word wrap

To configure the timeout per revision, set the idleTimeoutSeconds field in your service definition:

Example of a service definition with revision idle timeout set to 300 seconds (5 minutes)

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  namespace: my-ns
spec:
  template:
    spec:
      idleTimeoutSeconds: 300
      containers:
# ...

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  namespace: my-ns
spec:
  template:
    spec:
      idleTimeoutSeconds: 300
      containers:
# ...

Copy to Clipboard

Toggle word wrap

4.10.5. Long-running requests
Copiar enlace

To ensure that requests exceeding the default 600 second timeout set by Knative are not prematurely terminated, you need to adjust the timeouts in the following components:

OpenShift Container Platform route
OpenShift Serverless Serving
Load balancer, depending on the cloud provider

You can configure the timeouts globally or per revision. You can configure the timeouts globally if you have requests across all Knative services that need extended durations, or per revision for specific workloads that require different timeout values, such as AI deployments.

4.10.5.1. Configuring the default route timeouts globally
Copiar enlace

By configuring the route timeouts globally, you can ensure consistent timeout settings across all services, simplifying management for workloads that have similar timeout needs and reducing the need for individual adjustments.

You can configure the route timeouts globally by updating the ROUTE_HAPROXY_TIMEOUT environment value in your serverless-operator subscription and updating the max-revision-timeout-seconds field in your KnativeServing custom resource (CR). This applies the timeout changes across all Knative services, and you can deploy services with specific timeouts up to the maximum value set.

ROUTE_HAPROXY_TIMEOUT is an environment variable managed by the Serverless Operator and by default is set to 600.

Procedure

Set the value of ROUTE_HAPROXY_TIMEOUT in your subscription to your required timeout in seconds by running the following command. Note that this causes pods in the openshift-serverless namespace to be redeployed.

Setting the ROUTE_HAPROXY_TIMEOUT value to 900 seconds

oc patch subscription.operators.coreos.com serverless-operator -n openshift-serverless --type='merge' -p '{"spec": {"config": {"env": [{"name": "ROUTE_HAPROXY_TIMEOUT", "value": "900"}]}}}'

$ oc patch subscription.operators.coreos.com serverless-operator -n openshift-serverless --type='merge' -p '{"spec": {"config": {"env": [{"name": "ROUTE_HAPROXY_TIMEOUT", "value": "900"}]}}}'

Copy to Clipboard

Toggle word wrap

Alternatively, you can set the value of ROUTE_HAPROXY_TIMEOUT in your subscription directly:

A subscription definition with ROUTE_HAPROXY_TIMEOUT set to 900 seconds

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
#...
spec:
  channel: stable
  config:
    env:
      - name: ROUTE_HAPROXY_TIMEOUT
        value: '900'
#...

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
#...
spec:
  channel: stable
  config:
    env:
      - name: ROUTE_HAPROXY_TIMEOUT
        value: '900'
#...

Copy to Clipboard

Toggle word wrap

Note

If you created your routes manually and disabled auto-generation with the serving.knative.openshift.io/disableRoute annotation, you can configure the timeouts directly in the route definitions.

Set the maximum revision timeout in your KnativeServing CR:
KnativeServing CR with max-revision-timeout-seconds set to 900 seconds
```
apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
spec:
  config:
    defaults:
      max-revision-timeout-seconds: "900"
#...
```
```
apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
spec:
  config:
    defaults:
      max-revision-timeout-seconds: "900"
#...
```
Copy to Clipboard Toggle word wrap
The Serverless Operator automatically adjusts the terminationGracePeriod value of the activator to the set maximum revision timeout value to avoid request termination in cases where activator pods are being terminated themselves.

Optional: Verify that the timeout has been set by running the following command:

oc get deployment activator -n knative-serving -o jsonpath="{.spec.template.spec.terminationGracePeriodSeconds}"

$ oc get deployment activator -n knative-serving -o jsonpath="{.spec.template.spec.terminationGracePeriodSeconds}"

Copy to Clipboard

Toggle word wrap

If necessary for your cloud provider, adjust the load balancer timeout by running the following command:

Load balancer timeout adjustment for AWS Classic LB

oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge --patch=' \
  {"spec":{"endpointPublishingStrategy":  \
  {"type":"LoadBalancerService", "loadBalancer":  \
  {"scope":"External", "providerParameters":{"type":"AWS", "aws":  \
  {"type":"Classic", "classicLoadBalancer":  \
  {"connectionIdleTimeout":"20m"}}}}}}}'

$ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge --patch=' \
  {"spec":{"endpointPublishingStrategy":  \
  {"type":"LoadBalancerService", "loadBalancer":  \
  {"scope":"External", "providerParameters":{"type":"AWS", "aws":  \
  {"type":"Classic", "classicLoadBalancer":  \
  {"connectionIdleTimeout":"20m"}}}}}}}'

Copy to Clipboard

Toggle word wrap

Deploy a Knative service with the desired timeouts less or equal to the max-revision-timeout-seconds variable:

A Service definition with timeouts set to 800 seconds

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service-name
spec:
  template:
    spec:
      timeoutSeconds: 800
      responseStartTimeoutSeconds: 800

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service-name
spec:
  template:
    spec:
      timeoutSeconds: 800
      responseStartTimeoutSeconds: 800

Copy to Clipboard

Toggle word wrap

Important

When using Service Mesh, if the activator pod is stopped while a long-running request is in-flight, the request is interrupted. To avoid request interruptions, you must adjust the value of the terminationDrainDuration field in the ServiceMeshControlPlane CR:

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
#...
spec:
  techPreview:
      meshConfig:
        defaultConfig:
          terminationDrainDuration: 1000s 
#...

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
#...
spec:
  techPreview:
      meshConfig:
        defaultConfig:
          terminationDrainDuration: 1000s

1


#...

Copy to Clipboard

Toggle word wrap

1: Ensure that the value exceeds the request duration to avoid the Istio proxy shutdown, which would interrupt the request.

Verification

If you are using Kourier, you can verify the current value of the timeout at the OpenShift Container Platform route by running the following command:

oc get route <route_name> -n knative-serving-ingress ess -o jsonpath="{.metadata.annotations.haproxy\.router\.openshift\.io/timeout}"

$ oc get route <route_name> -n knative-serving-ingress ess -o jsonpath="{.metadata.annotations.haproxy\.router\.openshift\.io/timeout}"
800s

Copy to Clipboard

Toggle word wrap

4.10.5.2. Configuring the default route timeouts per revision
Copiar enlace

By configuring the route timeouts per revision, you can fine-tune timeouts for workloads with unique requirements, such as AI or data processing applications, without impacting the global timeout settings for other services. You can configure the timeouts of a specific revision by updating your KnativeServing custom resource (CR), the Service definition, and using the serving.knative.openshift.io/setRouteTimeout annotation to adjust the OpenShift Container Platform route timeout.

Procedure

Set the max-revision-timeout annotation in your KnativeServing CR as you require:

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
spec:
  config:
    defaults:
      max-revision-timeout-seconds: "900"

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
spec:
  config:
    defaults:
      max-revision-timeout-seconds: "900"

Copy to Clipboard

Toggle word wrap

Optional: Verify the termination grace period of an activator by running the following command:

oc get deployment activator -n knative-serving -o jsonpath="{.spec.template.spec.terminationGracePeriodSeconds}"

$ oc get deployment activator -n knative-serving -o jsonpath="{.spec.template.spec.terminationGracePeriodSeconds}"

900

Copy to Clipboard

Toggle word wrap

If necessary for your cloud provider, adjust the load balancer timeout by running the following command:

Load balancer timeout adjustment for AWS Classic LB

oc -n openshift-ingress-operator patch ingresscontroller/default \
  --type=merge --patch='{"spec":{"endpointPublishingStrategy":  \
  {"type":"LoadBalancerService", "loadBalancer":  \
  {"scope":"External", "providerParameters":{"type":"AWS", "aws":  \
  {"type":"Classic", "classicLoadBalancer":  \
  {"connectionIdleTimeout":"20m"}}}}}}}'

$ oc -n openshift-ingress-operator patch ingresscontroller/default \
  --type=merge --patch='{"spec":{"endpointPublishingStrategy":  \
  {"type":"LoadBalancerService", "loadBalancer":  \
  {"scope":"External", "providerParameters":{"type":"AWS", "aws":  \
  {"type":"Classic", "classicLoadBalancer":  \
  {"connectionIdleTimeout":"20m"}}}}}}}'

Copy to Clipboard

Toggle word wrap

Set the timeout for your specific service:

apiVersion: serving.knative.dev/v1f
kind: Service
metadata:
  name: <your_service_name>
  annotations:
    serving.knative.openshift.io/setRouteTimeout: "800" 
spec:
  template:
    metadata:
      annotations:
#...
    spec:
      timeoutSeconds: 800 
      responseStartTimeoutSeconds: 800

apiVersion: serving.knative.dev/v1f
kind: Service
metadata:
  name: <your_service_name>
  annotations:
    serving.knative.openshift.io/setRouteTimeout: "800"

1


spec:
  template:
    metadata:
      annotations:
#...
    spec:
      timeoutSeconds: 800

2


      responseStartTimeoutSeconds: 800

3

Copy to Clipboard

Toggle word wrap

1: This annotation sets the timeout for the OpenShift Container Platform route. You can fine-tune this for each service instead of setting a global maximum.
2: This ensures that the request does not exceed the specific value.
3: This ensures that the response start timeout does not trigger before the max threshold is reached. The default value is 300.

Important

When using Service Mesh, if the activator pod is stopped while a long-running request is in-flight, the request is interrupted. To avoid request interruptions, you must adjust the value of the terminationDrainDuration field in the ServiceMeshControlPlane CR:

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
#...
spec:
  techPreview:
      meshConfig:
        defaultConfig:
          terminationDrainDuration: 1000s 
#...

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
#...
spec:
  techPreview:
      meshConfig:
        defaultConfig:
          terminationDrainDuration: 1000s

1


#...

Copy to Clipboard

Toggle word wrap

1: Ensure that the value exceeds the request duration to avoid the Istio proxy shutdown, which would interrupt the request.

Verification

If you are using Kourier, you can verify the current value of the timeout at the OpenShift Container Platform route by running the following command:

oc get route <route-name> -n knative-serving-ingress ess -o jsonpath="{.metadata.annotations.haproxy\.router\.openshift\.io/timeout}"

$ oc get route <route-name> -n knative-serving-ingress ess -o jsonpath="{.metadata.annotations.haproxy\.router\.openshift\.io/timeout}"
800s

Copy to Clipboard

Toggle word wrap

Este contenido no está disponible en el idioma seleccionado.

4.1. Multi-container support for ServingCopiar enlaceEnlace copiado en el portapapeles!

4.1.1. Configuring a multi-container serviceCopiar enlaceEnlace copiado en el portapapeles!

4.1.2. Probing a multi-container serviceCopiar enlaceEnlace copiado en el portapapeles!

4.1.2.1. Additional resourcesCopiar enlaceEnlace copiado en el portapapeles!

4.2. EmptyDir volumesCopiar enlaceEnlace copiado en el portapapeles!

4.2.1. Configuring the EmptyDir extensionCopiar enlaceEnlace copiado en el portapapeles!

4.3. Persistent Volume Claims for ServingCopiar enlaceEnlace copiado en el portapapeles!

4.3.1. Enabling PVC supportCopiar enlaceEnlace copiado en el portapapeles!

4.4. Init containersCopiar enlaceEnlace copiado en el portapapeles!

4.4.1. Enabling init containersCopiar enlaceEnlace copiado en el portapapeles!

4.5. Startup probesCopiar enlaceEnlace copiado en el portapapeles!

4.5.1. Progress deadlineCopiar enlaceEnlace copiado en el portapapeles!

4.5.2. Configuring startup probingCopiar enlaceEnlace copiado en el portapapeles!

4.5.3. Configuring the progress deadlineCopiar enlaceEnlace copiado en el portapapeles!

4.6. Resolving image tags to digestsCopiar enlaceEnlace copiado en el portapapeles!

4.6.1. Tag-to-digest resolutionCopiar enlaceEnlace copiado en el portapapeles!

4.6.1.1. Configuring tag-to-digest resolution by using a secretCopiar enlaceEnlace copiado en el portapapeles!

4.7. Configuring deployment resourcesCopiar enlaceEnlace copiado en el portapapeles!

4.7.1. Skipping tag resolutionCopiar enlaceEnlace copiado en el portapapeles!

4.7.2. Configuring selectable RuntimeClassNameCopiar enlaceEnlace copiado en el portapapeles!

4.7.3. Progress deadlineCopiar enlaceEnlace copiado en el portapapeles!

4.7.3.1. Configuring the progress deadlineCopiar enlaceEnlace copiado en el portapapeles!

4.8. Configuring KourierCopiar enlaceEnlace copiado en el portapapeles!

4.8.1. Accessing the current Envoy bootstrap configurationCopiar enlaceEnlace copiado en el portapapeles!

4.8.2. Customizing kourier-bootstrap for Kourier getawaysCopiar enlaceEnlace copiado en el portapapeles!

4.8.3. Enabling administrator interface accessCopiar enlaceEnlace copiado en el portapapeles!

4.9. Restrictive network policiesCopiar enlaceEnlace copiado en el portapapeles!

4.9.1. Clusters with restrictive network policiesCopiar enlaceEnlace copiado en el portapapeles!

4.9.2. Enabling communication with Knative applications on a cluster with restrictive network policiesCopiar enlaceEnlace copiado en el portapapeles!

4.10. Configuring revision timeoutsCopiar enlaceEnlace copiado en el portapapeles!

4.10.1. Configuring revision timeoutCopiar enlaceEnlace copiado en el portapapeles!

4.10.2. Configuring maximum revision timeoutCopiar enlaceEnlace copiado en el portapapeles!

4.10.3. Configuring revision response start timeoutCopiar enlaceEnlace copiado en el portapapeles!

4.10.4. Configuring revision idle timeoutCopiar enlaceEnlace copiado en el portapapeles!

4.10.5. Long-running requestsCopiar enlaceEnlace copiado en el portapapeles!

4.10.5.1. Configuring the default route timeouts globallyCopiar enlaceEnlace copiado en el portapapeles!

4.10.5.2. Configuring the default route timeouts per revisionCopiar enlaceEnlace copiado en el portapapeles!

Aprender

Pruebe, compre y venda

Comunidades

Acerca de la documentación de Red Hat

Hacer que el código abierto sea más inclusivo

Acerca de Red Hat

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

4.1. Multi-container support for Serving
Copiar enlace

4.1.1. Configuring a multi-container service
Copiar enlace

4.1.2. Probing a multi-container service
Copiar enlace

4.1.2.1. Additional resources
Copiar enlace

4.2. EmptyDir volumes
Copiar enlace

4.2.1. Configuring the EmptyDir extension
Copiar enlace

4.3. Persistent Volume Claims for Serving
Copiar enlace

4.3.1. Enabling PVC support
Copiar enlace

4.4. Init containers
Copiar enlace

4.4.1. Enabling init containers
Copiar enlace

4.5. Startup probes
Copiar enlace

4.5.1. Progress deadline
Copiar enlace

4.5.2. Configuring startup probing
Copiar enlace

4.5.3. Configuring the progress deadline
Copiar enlace

4.6. Resolving image tags to digests
Copiar enlace

4.6.1. Tag-to-digest resolution
Copiar enlace

4.6.1.1. Configuring tag-to-digest resolution by using a secret
Copiar enlace

4.7. Configuring deployment resources
Copiar enlace

4.7.1. Skipping tag resolution
Copiar enlace

4.7.2. Configuring selectable RuntimeClassName
Copiar enlace

4.7.3. Progress deadline
Copiar enlace

4.7.3.1. Configuring the progress deadline
Copiar enlace

4.8. Configuring Kourier
Copiar enlace

4.8.1. Accessing the current Envoy bootstrap configuration
Copiar enlace

4.8.2. Customizing kourier-bootstrap for Kourier getaways
Copiar enlace

4.8.3. Enabling administrator interface access
Copiar enlace

4.9. Restrictive network policies
Copiar enlace

4.9.1. Clusters with restrictive network policies
Copiar enlace

4.9.2. Enabling communication with Knative applications on a cluster with restrictive network policies
Copiar enlace

4.10. Configuring revision timeouts
Copiar enlace

4.10.1. Configuring revision timeout
Copiar enlace

4.10.2. Configuring maximum revision timeout
Copiar enlace

4.10.3. Configuring revision response start timeout
Copiar enlace

4.10.4. Configuring revision idle timeout
Copiar enlace

4.10.5. Long-running requests
Copiar enlace

4.10.5.1. Configuring the default route timeouts globally
Copiar enlace

4.10.5.2. Configuring the default route timeouts per revision
Copiar enlace