OpenShift docs are moving and will soon only be available at docs.redhat.com, the home of all Red Hat product documentation. Explore the new docs experience today.
  1. Documentation
    2. history bug_report picture_as_pdf
×

Configuring deployment resources

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

Skipping tag resolution

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"

Configuring selectable RuntimeClassName

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

Progress deadline

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.

Configuring the progress deadline

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"