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

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

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

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

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

Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 문서 정보

Legal Notice

Theme

© 2026 Red Hat
맨 위로 이동