4.10. 버전 제한 시간 구성


버전에 대한 시간 초과 기간을 전역적으로 또는 개별적으로 구성하여 요청에 소요되는 시간을 제어할 수 있습니다.

4.10.1. 버전 제한 시간 구성

요청에 따라 버전 시간 초과에 대한 기본 시간(초)을 구성할 수 있습니다.

사전 요구 사항

  • OpenShift Serverless Operator 및 Knative Serving이 설치되어 있습니다.
  • 클러스터에 필요한 권한이 있습니다.

    • OpenShift Container Platform에 대한 클러스터 관리자 권한
    • AWS의 Red Hat OpenShift Service에 대한 클러스터 관리자 또는 전용 관리자 권한
    • OpenShift Dedicated에 대한 클러스터 관리자 또는 전용 관리자 권한

프로세스

  • 버전 시간 초과를 구성하는 적절한 방법을 선택합니다.

    • 버전 시간 초과를 전역적으로 구성하려면 KnativeServing 사용자 정의 리소스(CR)에서 revision-timeout-seconds 필드를 설정합니다.

      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
    • 서비스 정의에서 timeoutSeconds 필드를 설정하여 버전당 시간 제한을 구성하려면 다음을 수행합니다.

      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
    참고

    버전 시간 초과를 600초(10분)의 값으로 설정하려면 기본 OpenShift Container Platform 경로 제한 시간 및 최대 버전 시간 제한을 늘려야 합니다.

    기본 600초(10분)를 초과하는 요청에 대한 시간 초과를 구성하는 방법에 대한 지침은 "Long-running requests"를 참조하십시오.

4.10.2. 최대 버전 제한 시간 구성

최대 버전 제한 시간을 설정하면 버전이 특정 제한을 초과할 수 없도록 할 수 있습니다. 진행 중 요청이 중단되지 않도록 최대 버전 시간 초과 값은 활성화 프로그램의 terminationGracePeriodSeconds 값을 초과해서는 안 됩니다.

사전 요구 사항

  • OpenShift Serverless Operator 및 Knative Serving이 설치되어 있습니다.
  • 클러스터에 필요한 권한이 있습니다.

    • OpenShift Container Platform에 대한 클러스터 관리자 권한
    • AWS의 Red Hat OpenShift Service에 대한 클러스터 관리자 또는 전용 관리자 권한
    • OpenShift Dedicated에 대한 클러스터 관리자 또는 전용 관리자 권한

프로세스

  • 최대 버전 시간 제한을 구성하려면 KnativeServing CR(사용자 정의 리소스)에서 max-revision-timeout-seconds 필드를 설정합니다.

    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
    참고

    최대 버전 타임아웃을 600초(10분)의 값으로 설정하려면 기본 OpenShift Container Platform 경로 시간 제한을 늘려야 합니다.

    기본 600초(10분)를 초과하는 요청에 대한 시간 초과를 구성하는 방법에 대한 지침은 "Long-running requests"를 참조하십시오.

4.10.3. 버전 응답 시작 시간 초과 구성

버전 응답 시작 타임아웃을 설정하여 요청이 라우팅된 후 네트워크 트래픽 전송을 시작할 때까지 Serving이 대기하는 최대 기간(초)을 지정할 수 있습니다. 버전 응답 시작 시간 초과는 버전 제한 시간을 초과할 수 없습니다. 기본 기간은 300초(5분)입니다.

사전 요구 사항

  • OpenShift Serverless Operator 및 Knative Serving이 설치되어 있습니다.
  • 클러스터에 필요한 권한이 있습니다.

    • OpenShift Container Platform에 대한 클러스터 관리자 권한
    • AWS의 Red Hat OpenShift Service에 대한 클러스터 관리자 또는 전용 관리자 권한
    • OpenShift Dedicated에 대한 클러스터 관리자 또는 전용 관리자 권한

프로세스

  • 버전 응답 시작 시간 초과를 구성하는 적절한 방법을 선택합니다.

    • 시간 제한을 전역적으로 구성하려면 KnativeServing 사용자 정의 리소스(CR)에서 revision-response-start-timeout-seconds 필드를 설정합니다. 필요한 응답 시작 시간 초과가 버전 타임아웃을 초과하는 경우 그에 따라 revision-timeout-seconds 필드도 조정합니다.

      전역적으로 300 초로 설정된 버전 응답 시작 시간 제한의 예(5분)

      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

    • 버전별로 타임아웃을 구성하려면 서비스 정의에서 responseStartTimeoutSeconds 필드를 설정합니다. 필요한 응답 시작 시간 초과가 버전 타임아웃을 초과하는 경우 그에 따라 timeoutSeconds 필드를 조정합니다.

      버전 응답 시간 제한이 300초(5분)로 설정된 서비스 정의의 예

      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

    참고

    버전 응답 시작 시간 초과와 버전 시간 초과를 600초(10분) 값으로 설정하려면 기본 OpenShift Container Platform 경로 제한 시간 및 최대 버전 제한 시간을 늘려야 합니다.

    기본 600초(10분)를 초과하는 요청에 대한 시간 초과를 구성하는 방법에 대한 지침은 "Long-running requests"를 참조하십시오.

4.10.4. 버전 유휴 타임아웃 구성

개정 유휴 타임아웃을 설정하면 애플리케이션에서 데이터를 수신하지 않고도 요청이 열린 상태로 유지할 수 있는 최대 기간을 초 단위로 지정할 수 있습니다. 기본 기간은 0 (초기)입니다.

사전 요구 사항

  • OpenShift Serverless Operator 및 Knative Serving이 설치되어 있습니다.
  • 클러스터에 필요한 권한이 있습니다.

    • OpenShift Container Platform에 대한 클러스터 관리자 권한
    • AWS의 Red Hat OpenShift Service에 대한 클러스터 관리자 또는 전용 관리자 권한
    • OpenShift Dedicated에 대한 클러스터 관리자 또는 전용 관리자 권한

프로세스

  • 버전 유휴 시간 초과를 구성하려면 적절한 방법을 선택합니다.

    • 시간 초과를 전역적으로 구성하려면 KnativeServing CR(사용자 정의 리소스)에서 revision-idle-timeout-seconds 필드를 설정합니다.

      전역적으로 300 초(5분)로 설정된 버전 유휴 시간 제한 예

      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

    • 버전별로 타임아웃을 구성하려면 서비스 정의에서 idleTimeoutSeconds 필드를 설정합니다.

      버전 유휴 시간 제한이 300초(5분)로 설정된 서비스 정의의 예

      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. 장기 실행 요청

Knative에서 설정된 기본 600초 타임아웃을 초과하는 요청이 조기 종료되지 않도록 하려면 다음 구성 요소의 시간 초과를 조정해야 합니다.

  • OpenShift Container Platform 경로
  • OpenShift Serverless Serving
  • 클라우드 공급자에 따라 로드 밸런서

전역 또는 버전별로 시간 초과를 구성할 수 있습니다. 연장된 기간이 필요한 모든 Knative 서비스에 대한 요청이 있거나 AI 배포와 같은 다른 시간 초과 값이 필요한 특정 워크로드에 대한 버전당 타임아웃을 전역적으로 구성할 수 있습니다.

4.10.5.1. 기본 경로 시간 초과 구성 전역

경로 시간 초과를 전역적으로 구성하면 모든 서비스에서 일관된 시간 초과 설정을 보장하여 시간 초과 요구 사항이 유사한 워크로드에 대한 관리를 단순화하고 개별 조정의 필요성을 줄일 수 있습니다.

서버리스-operator 서브스크립션의 ROUTE_HAPROXY_TIMEOUT 환경 값을 업데이트하고 KnativeServing 사용자 정의 리소스(CR)의 max-revision-timeout-seconds 필드를 업데이트하여 경로 타임아웃을 전역적으로 구성할 수 있습니다. 이렇게 하면 모든 Knative 서비스에서 시간 초과 변경 사항이 적용되고 최대 값이 설정된 특정 시간 초과를 사용하여 서비스를 배포할 수 있습니다.

ROUTE_HAPROXY_TIMEOUT 은 Serverless Operator에서 관리하는 환경 변수이며 기본적으로 600 으로 설정됩니다.

프로세스

  1. 다음 명령을 실행하여 서브스크립션의 ROUTE_HAPROXY_TIMEOUT 값을 필요한 시간(초)으로 설정합니다. 이로 인해 openshift-serverless 네임스페이스의 Pod가 재배포됩니다.

    ROUTE_HAPROXY_TIMEOUT 값을 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

    또는 서브스크립션에서 ROUTE_HAPROXY_TIMEOUT 값을 직접 설정할 수 있습니다.

    ROUTE_HAPROXY_TIMEOUT 이 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

    참고

    serving.knative.openshift.io/disableRoute 주석을 사용하여 경로를 수동으로 생성하고 자동 생성을 비활성화한 경우 경로 정의에서 직접 시간 초과를 구성할 수 있습니다.

  2. KnativeServing CR에서 최대 버전 타임아웃을 설정합니다.

    max-revision-timeout-seconds 가 900초로 설정된 KnativeServing CR

    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

    Serverless Operator는 활성 상태의 Pod가 자체적으로 종료되는 경우 요청 종료를 방지하기 위해 활성화기의 terminationGracePeriod 값을 설정된 최대 버전 시간 초과 값으로 자동으로 조정합니다.

  3. 선택 사항: 다음 명령을 실행하여 시간 초과가 설정되었는지 확인합니다.

    $ oc get deployment activator -n knative-serving -o jsonpath="{.spec.template.spec.terminationGracePeriodSeconds}"
    Copy to Clipboard Toggle word wrap
  4. 클라우드 공급자에 필요한 경우 다음 명령을 실행하여 로드 밸런서 시간 초과를 조정합니다.

    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"}}}}}}}'
    Copy to Clipboard Toggle word wrap

  5. max-revision-timeout-seconds 변수와 같거나 원하는 시간 초과를 사용하여 Knative 서비스를 배포합니다.

    시간 초과가 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

    중요

    서비스 메시를 사용하는 경우 장기 실행 요청이 진행 중이면 요청이 중단됩니다. 요청 중단을 방지하려면 ServiceMeshControlPlane CR의 terminationDrainDuration 필드 값을 조정해야 합니다.

    apiVersion: maistra.io/v2
    kind: ServiceMeshControlPlane
    #...
    spec:
      techPreview:
          meshConfig:
            defaultConfig:
              terminationDrainDuration: 1000s 
    1
    
    #...
    Copy to Clipboard Toggle word wrap
    1
    요청을 중단하는 Istio 프록시 종료를 방지하기 위해 값이 요청 기간을 초과했는지 확인합니다.

검증

  • Kourier를 사용하는 경우 다음 명령을 실행하여 OpenShift Container Platform 경로에서 현재 시간 초과 값을 확인할 수 있습니다.

    $ 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. 버전당 기본 경로 시간 초과 구성

버전당 경로 시간 초과를 구성하면 다른 서비스의 글로벌 시간 초과 설정에 영향을 주지 않고 AI 또는 데이터 처리 애플리케이션과 같은 고유한 요구 사항을 사용하여 워크로드에 대한 시간 제한을 미세 조정할 수 있습니다. KnativeServing 사용자 정의 리소스(CR), 서비스 정의 및 serving.knative.openshift.io/setRouteTimeout 주석을 사용하여 OpenShift Container Platform 경로 제한 시간을 조정하여 특정 버전의 타임아웃을 구성할 수 있습니다.

프로세스

  1. 필요에 따라 KnativeServing CR에서 max-revision-timeout 주석을 설정합니다.

    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
  2. 선택 사항: 다음 명령을 실행하여 활성화 프로그램의 종료 유예 기간을 확인합니다.

    $ oc get deployment activator -n knative-serving -o jsonpath="{.spec.template.spec.terminationGracePeriodSeconds}"
    
    900
    Copy to Clipboard Toggle word wrap
  3. 클라우드 공급자에 필요한 경우 다음 명령을 실행하여 로드 밸런서 시간 초과를 조정합니다.

    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"}}}}}}}'
    Copy to Clipboard Toggle word wrap

  4. 특정 서비스의 타임아웃을 설정합니다.

    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
    이 주석은 OpenShift Container Platform 경로에 대한 타임아웃을 설정합니다. 글로벌 최대값을 설정하는 대신 각 서비스에 대해 이를 미세 조정할 수 있습니다.
    2
    이렇게 하면 요청이 특정 값을 초과하지 않습니다.
    3
    이렇게 하면 max 임계값에 도달하기 전에 응답 시작 시간 초과가 트리거되지 않습니다. 기본값은 300 입니다.
    중요

    서비스 메시를 사용하는 경우 장기 실행 요청이 진행 중이면 요청이 중단됩니다. 요청 중단을 방지하려면 ServiceMeshControlPlane CR의 terminationDrainDuration 필드 값을 조정해야 합니다.

    apiVersion: maistra.io/v2
    kind: ServiceMeshControlPlane
    #...
    spec:
      techPreview:
          meshConfig:
            defaultConfig:
              terminationDrainDuration: 1000s 
    1
    
    #...
    Copy to Clipboard Toggle word wrap
    1
    요청을 중단하는 Istio 프록시 종료를 방지하기 위해 값이 요청 기간을 초과했는지 확인합니다.

검증

  • Kourier를 사용하는 경우 다음 명령을 실행하여 OpenShift Container Platform 경로에서 현재 시간 초과 값을 확인할 수 있습니다.

    $ 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
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

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

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

Red Hat 소개

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

Theme

© 2025 Red Hat