지원콘솔개발자평가판 시작연락처

4.2. 자동 확장

4.2.1. 자동 확장

Knative Serving은 들어오는 수요와 일치시킬 수 있도록 애플리케이션이 자동 스케일링 또는 자동 스케일링 을 제공합니다. 예를 들어 애플리케이션에 트래픽이 없고 scale-to-zero가 활성화된 경우 Knative Serving은 애플리케이션을 복제본 0으로 축소합니다. scale-to-zero이 비활성화된 경우 애플리케이션은 클러스터의 애플리케이션에 대해 구성된 최소 복제본 수로 축소됩니다. 애플리케이션 트래픽이 증가하는 경우 요구에 맞게 복제본을 확장할 수도 있습니다.

Knative 서비스의 자동 스케일링 설정은 클러스터 관리자가 구성하거나 개별 서비스에 대해 구성된 설정별로 구성하는 전역 설정일 수 있습니다.

서비스의 YAML 파일을 수정하거나 Knative(kn) CLI를 사용하여 OpenShift Container Platform 웹 콘솔을 사용하여 서비스 단위 설정을 수정할 수 있습니다.

참고

서비스에 설정된 모든 제한 또는 대상은 애플리케이션의 단일 인스턴스에 대해 측정됩니다. 예를 들어 target 주석을 50 으로 설정하면 자동 스케일러가 애플리케이션을 스케일링하여 각 버전이 한 번에 50개의 요청을 처리하도록 구성됩니다.

4.2.2. scale bounds

scale bounds는 언제든지 애플리케이션을 제공할 수 있는 최소 및 최대 복제본 수를 결정합니다. 애플리케이션에 대한 스케일 경계를 설정하여 콜드 시작 방지 또는 컴퓨팅 비용을 제어할 수 있습니다.

4.2.2.1. 최소 스케일링 범위

애플리케이션을 제공할 수 있는 최소 복제본 수는 min-scale 주석에 따라 결정됩니다. scale to zero가 활성화되어 있지 않으면 min-scale 값이 1 로 설정됩니다.

다음 조건이 충족되는 경우 min-scale 값은 기본적으로 0 개의 복제본으로 설정됩니다.

  • min-scale 주석이 설정되지 않음
  • 스케일링을 0으로 활성화
  • KPA 클래스가 사용됩니다.

min-scale 주석이 있는 서비스 사양의 예

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/min-scale: "0"
...

4.2.2.1.1. Knative CLI를 사용하여 min-scale 주석 설정

Knative(kn) CLI를 사용하여 min-scale 주석을 설정하면 YAML 파일을 직접 수정하는 동안 보다 간소화되고 직관적인 사용자 인터페이스를 제공합니다. kn service 명령을 --scale-min 플래그와 함께 사용하여 서비스의 min-scale 값을 생성하거나 수정할 수 있습니다.

사전 요구 사항

  • Knative Serving이 클러스터에 설치되어 있습니다.
  • Knative(kn) CLI가 설치되어 있습니다.

절차

  • --scale-min 플래그를 사용하여 서비스의 최소 복제본 수를 설정합니다. 

    $ kn service create <service_name> --image <image_uri> --scale-min <integer>

    명령 예

    $ kn service create example-service --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest --scale-min 2

4.2.2.2. 최대 스케일링 범위

애플리케이션을 제공할 수 있는 최대 복제본 수는 max-scale 주석에 따라 결정됩니다. max-scale 주석이 설정되지 않은 경우 생성된 복제본 수에 대한 상한이 없습니다.

max-scale 주석이 있는 서비스 사양의 예

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/max-scale: "10"
...

4.2.2.2.1. Knative CLI를 사용하여 max-scale 주석 설정

Knative(kn) CLI를 사용하여 max-scale 주석을 설정하면 YAML 파일을 직접 수정하여 보다 간소화되고 직관적인 사용자 인터페이스를 제공합니다. kn service 명령을 --scale-max 플래그와 함께 사용하여 서비스의 max-scale 값을 생성하거나 수정할 수 있습니다.

사전 요구 사항

  • Knative Serving이 클러스터에 설치되어 있습니다.
  • Knative(kn) CLI가 설치되어 있습니다.

절차

  • --scale-max 플래그를 사용하여 서비스의 최대 복제본 수를 설정합니다. 

    $ kn service create <service_name> --image <image_uri> --scale-max <integer>

    명령 예

    $ kn service create example-service --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest --scale-max 10

4.2.3. 동시성

동시성은 언제든지 애플리케이션의 각 복제본에서 처리할 수 있는 동시 요청 수를 결정합니다. 동시성은 소프트 제한 또는 하드 제한 으로 구성할 수 있습니다.

  • 소프트 제한은 엄격하게 적용되는 바인딩된 것이 아니라 대상 요청 제한입니다. 예를 들어, 트래픽 버스트가 급증하는 경우 소프트 제한 대상을 초과할 수 있습니다.

  • 하드 제한은 엄격한 강제 적용된 상한 요청 제한입니다. 동시성이 하드 제한에 도달하면 요청을 버퍼링하고 요청을 실행하기에 충분한 여유 용량이 있을 때까지 기다려야 합니다.If concurrency reaches the hard limit, surplus requests are buffered and must wait until there is enough free capacity to execute the requests.

    중요

    애플리케이션에 대한 명확한 사용 사례가 있는 경우에만 하드 제한 구성을 사용하는 것이 좋습니다. 지정된 하드 제한이 낮으면 애플리케이션의 처리량 및 대기 시간에 부정적인 영향을 미칠 수 있으며 콜드 시작이 발생할 수 있습니다.

소프트 대상과 하드 제한을 추가하면 자동 스케일러가 동시 요청의 소프트 대상 수를 대상으로하지만 최대 요청 수에 하드 제한 값을 강제 적용합니다.

하드 제한 값이 소프트 제한 값보다 작으면 실제로 처리할 수 있는 수보다 더 많은 요청을 대상으로 할 필요가 없기 때문에 소프트 제한 값이 축소됩니다.

4.2.3.1. 소프트 동시성 대상 구성

소프트 제한은 엄격하게 적용되는 바인딩된 것이 아니라 대상 요청 제한입니다. 예를 들어, 트래픽 버스트가 급증하는 경우 소프트 제한 대상을 초과할 수 있습니다. 사양에 autoscaling.knative.dev/target 주석을 설정하거나 올바른 플래그와 함께 kn service 명령을 사용하여 Knative 서비스의 소프트 동시성 대상을 지정할 수 있습니다.

절차

  • 선택 사항: Service 사용자 정의 리소스의 사양에서 Knative 서비스에 대한 autoscaling.knative.dev/target 주석을 설정합니다.

    서비스 사양의 예

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/target: "200"

  • 선택 사항: kn service 명령을 사용하여 --concurrency-target 플래그를 지정합니다. 

    $ kn service create <service_name> --image <image_uri> --concurrency-target <integer>

    동시성 대상이 50개의 요청인 서비스를 생성하는 명령의 예

    $ kn service create example-service --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest --concurrency-target 50

4.2.3.2. 하드 동시성 제한 구성

하드 동시성 제한은 엄격히 적용되는 상한 상한 요청 제한입니다. 동시성이 하드 제한에 도달하면 요청을 버퍼링하고 요청을 실행하기에 충분한 여유 용량이 있을 때까지 기다려야 합니다.If concurrency reaches the hard limit, surplus requests are buffered and must wait until there is enough free capacity to execute the requests. containerConcurrency 사양을 수정하거나 올바른 플래그와 함께 kn service 명령을 사용하여 Knative 서비스의 하드 동시성 제한을 지정할 수 있습니다.

절차

  • 선택 사항: Service 사용자 정의 리소스의 사양에서 Knative 서비스의 containerConcurrency 사양을 설정합니다.

    서비스 사양의 예

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
  template:
    spec:
      containerConcurrency: 50

    기본값은 0 이며, 이는 한 번에 하나의 서비스 복제본으로 흐름을 허용하는 동시 요청 수에 제한이 없음을 의미합니다.

    값이 0 보다 크면 한 번에 하나의 서비스 복제본으로 흐름이 허용되는 정확한 요청 수를 지정합니다. 이 예제에서는 50개의 요청의 하드 동시성 제한을 활성화합니다.

  • 선택 사항: kn service 명령을 사용하여 --concurrency-limit 플래그를 지정합니다. 

    $ kn service create <service_name> --image <image_uri> --concurrency-limit <integer>

    동시성 제한이 50개인 서비스를 생성하는 명령의 예

    $ kn service create example-service --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest --concurrency-limit 50

4.2.3.3. 동시성 대상 사용률

이 값은 자동 스케일러가 실제로 대상으로 하는 동시성 제한의 백분율을 지정합니다. 복제가 실행되는 hotness 를 지정하여 정의된 하드 제한에 도달하기 전에 자동 스케일러를 확장할 수도 있습니다.

예를 들어 containerConcurrency 값이 10으로 설정되고 target-utilization-percentage 값이 70%로 설정된 경우 기존 복제본의 평균 수가 7에 도달하면 자동 스케일러에서 새 복제본을 생성합니다. 7에서 10으로 번호가 매겨진 요청은 여전히 기존 복제본으로 전송되지만 containerConcurrency 값에 도달한 후 추가 복제본이 필요합니다.

target-utilization-percentage 주석을 사용하여 구성된 서비스 예

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/target-utilization-percentage: "70"
...

4.2.4. Scale-to-zero

Knative Serving은 들어오는 수요와 일치시킬 수 있도록 애플리케이션이 자동 스케일링 또는 자동 스케일링 을 제공합니다.

4.2.4.1. scale-to-zero 활성화

enable-scale-to-zero 사양을 사용하여 클러스터의 애플리케이션에 대해 전역적으로 스케일링을 활성화하거나 비활성화할 수 있습니다.

사전 요구 사항

  • 클러스터에 OpenShift Serverless Operator 및 Knative Serving을 설치했습니다.
  • 클러스터 관리자 권한이 있어야 합니다.
  • 기본 Knative Pod Autoscaler를 사용하고 있습니다. Kubernetes Horizontal Pod Autoscaler를 사용하는 경우 제로 스케일링 기능을 사용할 수 없습니다.

절차

  • KnativeServing 사용자 정의 리소스(CR)에서 enable-scale-to-zero 사양을 수정합니다.

    KnativeServing CR의 예

    apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
spec:
  config:
    autoscaler:
      enable-scale-to-zero: "false" 1

    1
    enable-scale-to-zero 사양은 "true" 또는 "false" 일 수 있습니다. true로 설정하면 scale-to-zero가 활성화됩니다. false로 설정하면 애플리케이션이 구성된 최소 스케일 바인딩 으로 축소됩니다. 기본값은 "true" 입니다.

4.2.4.2. scale-to-zero 유예 기간 구성

Knative Serving은 애플리케이션에 대해 Pod 0개로 자동 스케일링을 제공합니다. scale-to-zero-grace-period 사양을 사용하여 Knative에서 scale-to-zero machinery가 애플리케이션 마지막 복제본을 제거하기 전에 대기하는 상한 시간 제한을 정의할 수 있습니다.

사전 요구 사항

  • 클러스터에 OpenShift Serverless Operator 및 Knative Serving을 설치했습니다.
  • 클러스터 관리자 권한이 있어야 합니다.
  • 기본 Knative Pod Autoscaler를 사용하고 있습니다. Kubernetes Horizontal Pod Autoscaler를 사용하는 경우 스케일에서 0까지 기능을 사용할 수 없습니다.

절차

  • KnativeServing CR(사용자 정의 리소스)에서 scale-to-grace-period 사양을 수정합니다.

    KnativeServing CR의 예

    apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
spec:
  config:
    autoscaler:
      scale-to-zero-grace-period: "30s" 1

    1
    유예 기간(초)입니다. 기본값은 30초입니다.
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.