4.2. 자동 확장

4.2.1. 자동 확장

Knative Serving은 들어오는 수요와 일치하도록 애플리케이션에서 자동 스케일링 또는 자동 스케일링 을 제공합니다. 예를 들어 애플리케이션에서 트래픽을 수신하고 0으로 스케일링하는 경우 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 주석에 따라 결정됩니다. 스케일을 0으로 설정하지 않으면 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. 동시성

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

소프트 제한은 엄격하게 적용된 바인딩이 아닌 대상 요청 제한입니다. 예를 들어 트래픽이 갑작스러운 버스트가 있는 경우 소프트 제한 대상을 초과할 수 있습니다.
하드 제한은 엄격하게 적용된 상위 바인딩된 요청 제한입니다. 동시성이 하드 제한에 도달하면 초과 요청이 버퍼링되고 요청을 실행하기에 충분한 여유 용량이 있을 때까지 기다려야 합니다.
중요
하드 제한 구성을 사용하는 것은 애플리케이션과 함께 명확한 사용 사례가 있는 경우에만 권장됩니다. 낮은 하드 제한을 지정하면 애플리케이션의 처리량 및 대기 시간에 부정적인 영향을 줄 수 있으며 콜드 시작이 발생할 수 있습니다.

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

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

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. 하드 동시성 제한 구성

하드 동시성 제한은 엄격하게 적용된 상위 바인딩된 요청 제한입니다. 동시성이 하드 제한에 도달하면 초과 요청이 버퍼링되고 요청을 실행하기에 충분한 여유 용량이 있을 때까지 기다려야 합니다. 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를 사용하는 경우 scale-to-zero 기능을 사용할 수 없습니다.

절차

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초입니다.

4.2. 자동 확장

4.2.1. 자동 확장

4.2.2. scale bounds

4.2.2.1. 최소 스케일 경계

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

4.2.2.2. 최대 스케일링 바인딩

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

4.2.3. 동시성

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

4.2.3.2. 하드 동시성 제한 구성

4.2.3.3. 동시성 대상 사용률

4.2.4. Scale-to-zero

4.2.4.1. scale-to-zero 활성화

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

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

Red Hat 소개

Red Hat legal and privacy links

Red Hat legal and privacy links