3.4. 사용자 정의 메트릭 자동 스케일러 트리거 이해
scalers라고도 하는 트리거는 Custom Metrics Autoscaler Operator가 Pod를 스케일링하는 데 사용하는 메트릭을 제공합니다.
사용자 정의 메트릭 자동 스케일러는 현재 Prometheus, CPU, 메모리 및 Apache Kafka 트리거만 지원합니다.
ScaledObject
또는 ScaledJob
사용자 정의 리소스를 사용하여 다음 섹션에 설명된 대로 특정 개체에 대한 트리거를 구성합니다.
확장된 오브젝트 또는 클러스터의 모든 확장기와 함께 사용할 인증 기관을 구성할 수 있습니다.
3.4.1. Prometheus 트리거 이해
설치된 OpenShift Container Platform 모니터링을 사용하거나 외부 Prometheus 서버를 메트릭 소스로 사용할 수 있는 Prometheus 메트릭을 기반으로 Pod를 확장할 수 있습니다. 메트릭의 소스로 OpenShift Container Platform 모니터링을 사용하는 데 필요한 구성에 대한 정보는 "사용자 정의 메트릭 자동 스케일러 구성"을 참조하십시오.
Prometheus가 사용자 정의 지표 자동 스케일러가 스케일링하는 애플리케이션에서 지표를 수집하는 경우 사용자 정의 리소스에서 최소 복제본을 0
으로 설정하지 마십시오. 애플리케이션 Pod가 없는 경우 사용자 정의 지표 자동 스케일러에는 스케일링할 메트릭이 없습니다.
Prometheus 대상이 있는 스케일링 오브젝트의 예
apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prom-scaledobject namespace: my-namespace spec: # ... triggers: - type: prometheus 1 metadata: serverAddress: https://thanos-querier.openshift-monitoring.svc.cluster.local:9092 2 namespace: kedatest 3 metricName: http_requests_total 4 threshold: '5' 5 query: sum(rate(http_requests_total{job="test-app"}[1m])) 6 authModes: basic 7 cortexOrgID: my-org 8 ignoreNullValues: false 9 unsafeSsl: false 10
- 1
- Prometheus를 트리거 유형으로 지정합니다.
- 2
- Prometheus 서버의 주소를 지정합니다. 이 예에서는 OpenShift Container Platform 모니터링을 사용합니다.
- 3
- 선택 사항: 스케일링할 오브젝트의 네임스페이스를 지정합니다. OpenShift Container Platform 모니터링을 메트릭 소스로 사용하는 경우 이 매개변수가 필요합니다.
- 4
external.metrics.k8s.io
API에서 메트릭을 식별하는 이름을 지정합니다. 둘 이상의 트리거를 사용하는 경우 모든 메트릭 이름을 고유해야 합니다.- 5
- 스케일링을 트리거하는 값을 지정합니다. 따옴표로 묶은 문자열 값으로 지정해야 합니다.
- 6
- 사용할 Prometheus 쿼리를 지정합니다.
- 7
- 사용할 인증 방법을 지정합니다. Prometheus 스케일러는 전달자 인증( 베어러 인증), 기본 인증(
기본
인증) 또는 TLS 인증(tls
)을 지원합니다.다음 섹션에서 설명하는 대로 트리거 인증에 특정 인증 매개변수를 구성합니다. 필요한 경우 시크릿을 사용할 수도 있습니다.
- 8
- 9
- 선택 사항: Prometheus 대상이 손실되는 경우 트리거를 진행하는 방법을 지정합니다.
-
true
인 경우 Prometheus 대상이 손실되면 트리거가 계속 작동합니다. 이는 기본 동작입니다. -
false
인 경우 Prometheus 대상이 손실되면 트리거에서 오류를 반환합니다.
-
- 10
- 선택 사항: 인증서 검사를 건너뛰어야 하는지 여부를 지정합니다. 예를 들어 테스트 환경에서 실행 중이고 Prometheus 끝점에서 자체 서명된 인증서를 사용하는 경우 검사를 건너뛸 수 있습니다.
-
false
인 경우 인증서 검사가 수행됩니다. 이는 기본 동작입니다. true
인 경우 인증서 검사가 수행되지 않습니다.중요검사를 건너뛰는 것은 권장되지 않습니다.
-
3.4.1.1. OpenShift Container Platform 모니터링을 사용하도록 사용자 정의 메트릭 자동 스케일러 구성
설치된 OpenShift Container Platform Prometheus 모니터링을 사용자 정의 메트릭 자동 스케일러에서 사용하는 메트릭의 소스로 사용할 수 있습니다. 그러나 수행해야 하는 몇 가지 추가 구성이 있습니다.
이러한 단계는 외부 Prometheus 소스에 필요하지 않습니다.
이 섹션에 설명된 대로 다음 작업을 수행해야 합니다.
- 서비스 계정을 생성하여 토큰을 가져옵니다.
- 역할을 생성합니다.
- 해당 역할을 서비스 계정에 추가합니다.
- Prometheus에서 사용하는 트리거 인증 오브젝트에서 토큰을 참조합니다.
사전 요구 사항
- OpenShift Container Platform 모니터링이 설치되어 있어야 합니다.
- 사용자 정의 워크로드 모니터링 구성 맵 생성 섹션에 설명된 대로 OpenShift Container Platform 모니터링에서 사용자 정의 워크로드 모니터링 이 활성화되어야 합니다.
- Custom Metrics Autoscaler Operator가 설치되어 있어야 합니다.
절차
스케일링할 오브젝트를 사용하여 프로젝트로 변경합니다.
$ oc project my-project
클러스터에 없는 경우 다음 명령을 사용하여 서비스 계정을 생성합니다.
$ oc create serviceaccount <service_account>
다음과 같습니다.
- <service_account>
- 서비스 계정의 이름을 지정합니다.
다음 명령을 사용하여 서비스 계정에 할당된 토큰을 찾습니다.
$ oc describe serviceaccount <service_account>
다음과 같습니다.
- <service_account>
- 서비스 계정의 이름을 지정합니다.
출력 예
Name: thanos Namespace: my-project Labels: <none> Annotations: <none> Image pull secrets: thanos-dockercfg-nnwgj Mountable secrets: thanos-dockercfg-nnwgj Tokens: thanos-token-9g4n5 1 Events: <none>
- 1
- 트리거 인증에 이 토큰을 사용합니다.
서비스 계정 토큰을 사용하여 트리거 인증을 생성합니다.
다음과 유사한 YAML 파일을 생성합니다.
apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-prometheus spec: secretTargetRef: 1 - parameter: bearerToken 2 name: thanos-token-9g4n5 3 key: token 4 - parameter: ca name: thanos-token-9g4n5 key: ca.crt
CR 오브젝트를 생성합니다.
$ oc create -f <file-name>.yaml
Thanos 메트릭을 읽는 역할을 생성합니다.
다음 매개변수를 사용하여 YAML 파일을 생성합니다.
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: thanos-metrics-reader rules: - apiGroups: - "" resources: - pods verbs: - get - apiGroups: - metrics.k8s.io resources: - pods - nodes verbs: - get - list - watch
CR 오브젝트를 생성합니다.
$ oc create -f <file-name>.yaml
Thanos 메트릭을 읽기 위한 역할 바인딩을 생성합니다.
다음과 유사한 YAML 파일을 생성합니다.
apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: thanos-metrics-reader 1 namespace: my-project 2 roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: thanos-metrics-reader subjects: - kind: ServiceAccount name: thanos 3 namespace: my-project 4
CR 오브젝트를 생성합니다.
$ oc create -f <file-name>.yaml
"사용자 정의 메트릭 자동 스케일러를 추가하는 방법 이해"에 설명된 대로 확장 오브젝트 또는 확장 작업을 배포하여 애플리케이션에 대한 자동 스케일링을 활성화할 수 있습니다. OpenShift Container Platform 모니터링을 소스, 트리거 또는 scaler로 사용하려면 다음 매개변수를 포함해야 합니다.
-
triggers.type
은prometheus
여야 합니다 -
triggers.metadata.serverAddress
는https://thanos-querier.openshift-monitoring.svc.cluster.local:9092
이어야 합니다 -
triggers.metadata.authModes
는베어러
여야 합니다. -
Trigger.metadata.namespace
는 스케일링할 오브젝트의 네임스페이스로 설정해야 합니다. -
triggers.authenticationRef
는 이전 단계에서 지정된 트리거 인증 리소스를 가리켜야 합니다.
3.4.2. CPU 트리거 이해
CPU 메트릭을 기반으로 Pod를 확장할 수 있습니다. 이 트리거는 클러스터 지표를 메트릭의 소스로 사용합니다.
사용자 정의 메트릭 자동 스케일러는 지정한 CPU 사용량을 유지하도록 오브젝트와 연결된 Pod를 스케일링합니다. 자동 스케일러는 최소 및 최대 개수 사이에서 복제본 수를 늘리거나 줄여 모든 Pod에서 지정된 CPU 사용률을 유지합니다. 메모리 트리거는 전체 Pod의 메모리 사용률을 고려합니다. Pod에 컨테이너가 여러 개 있는 경우 메모리 트리거는 Pod에 있는 모든 컨테이너의 총 메모리 사용률을 고려합니다.
-
이 트리거는
ScaledJob
사용자 정의 리소스와 함께 사용할 수 없습니다. -
메모리 트리거를 사용하여 오브젝트를 스케일링할 때 여러 트리거를 사용하는 경우에도 개체는
0
으로 스케일링되지 않습니다.
CPU 대상이 있는 확장된 오브젝트의 예
apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cpu-scaledobject namespace: my-namespace spec: # ... triggers: - type: cpu 1 metricType: Utilization 2 metadata: value: '60' 3 minReplicaCount: 1 4
- 1
- CPU를 트리거 유형으로 지정합니다.
- 2
- 사용할 메트릭의 유형(
Utilization
또는AverageValue
)을 지정합니다. - 3
- 스케일링을 트리거하는 값을 지정합니다. 따옴표로 묶은 문자열 값으로 지정해야 합니다.
-
Utilization
을 사용하는 경우 target 값은 Pod에 대해 요청된 리소스의 백분율로 표시되는 모든 관련 Pod에서 리소스 지표의 평균값입니다. -
AverageValue
를 사용하는 경우 target 값은 모든 관련 Pod의 평균 지표입니다.
-
- 4
- 축소 시 최소 복제본 수를 지정합니다. CPU 트리거의 경우 CPU 지표만 사용하는 경우 HPA를 0으로 확장할 수 없기 때문에 CPU 트리거의 값을
1
이상 입력합니다.
3.4.3. 메모리 트리거 이해
메모리 메트릭을 기반으로 Pod를 확장할 수 있습니다. 이 트리거는 클러스터 지표를 메트릭의 소스로 사용합니다.
사용자 정의 메트릭 자동 스케일러는 오브젝트와 연결된 Pod를 스케일링하여 지정한 평균 메모리 사용량을 유지합니다. 자동 스케일러는 최소 및 최대 개수 사이에서 복제본 수를 늘리거나 줄여 모든 Pod에서 지정된 메모리 사용률을 유지합니다. 메모리 트리거는 전체 Pod의 메모리 사용률을 고려합니다. Pod에 컨테이너가 여러 개 있는 경우 메모리 사용률은 모든 컨테이너의 합계입니다.
-
이 트리거는
ScaledJob
사용자 정의 리소스와 함께 사용할 수 없습니다. -
메모리 트리거를 사용하여 오브젝트를 스케일링할 때 여러 트리거를 사용하는 경우에도 개체는
0
으로 스케일링되지 않습니다.
메모리 대상이 있는 확장된 오브젝트의 예
apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: memory-scaledobject namespace: my-namespace spec: # ... triggers: - type: memory 1 metricType: Utilization 2 metadata: value: '60' 3 containerName: api 4
- 1
- memory를 트리거 유형으로 지정합니다.
- 2
- 사용할 메트릭의 유형(
Utilization
또는AverageValue
)을 지정합니다. - 3
- 스케일링을 트리거하는 값을 지정합니다. 따옴표로 묶은 문자열 값으로 지정해야 합니다.
-
Utilization
을 사용하는 경우 target 값은 Pod에 대해 요청된 리소스의 백분율로 표시되는 모든 관련 Pod에서 리소스 지표의 평균값입니다. -
AverageValue
를 사용하는 경우 target 값은 모든 관련 Pod의 평균 지표입니다.
-
- 4
- 선택 사항: 전체 Pod가 아닌 해당 컨테이너의 메모리 사용률에 따라 스케일링할 개별 컨테이너를 지정합니다. 이 예제에서는
api
라는 컨테이너만 스케일링할 수 있습니다.
3.4.4. Kafka 트리거 이해
Apache Kafka 주제 또는 Kafka 프로토콜을 지원하는 기타 서비스를 기반으로 Pod를 확장할 수 있습니다. 사용자 정의 메트릭 자동 스케일러는 스케일링된 오브젝트 또는 스케일링 작업에서 allowIdleConsumers
매개변수를 true
로 설정하지 않는 한 Kafka 파티션 수보다 크게 확장되지 않습니다.
소비자 그룹의 수가 주제의 파티션 수를 초과하면 추가 소비자 그룹은 유휴 상태로 유지됩니다. 이 문제를 방지하려면 기본적으로 복제본 수는 다음을 초과하지 않습니다.
- 주제가 지정된 경우 주제의 파티션 수
- 주제가 지정되지 않은 경우 소비자 그룹에 있는 모든 항목의 파티션 수
-
확장 오브젝트 또는 확장 작업 CR에 지정된
maxReplicaCount
allowIdleConsumers
매개변수를 사용하여 이러한 기본 동작을 비활성화할 수 있습니다.
Kafka 대상이 있는 확장된 오브젝트의 예
apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: my-namespace spec: # ... triggers: - type: kafka 1 metadata: topic: my-topic 2 bootstrapServers: my-cluster-kafka-bootstrap.openshift-operators.svc:9092 3 consumerGroup: my-group 4 lagThreshold: '10' 5 activationLagThreshold: '5' 6 offsetResetPolicy: latest 7 allowIdleConsumers: true 8 scaleToZeroOnInvalidOffset: false 9 excludePersistentLag: false 10 version: '1.0.0' 11 partitionLimitation: '1,2,10-20,31' 12 tls: enable 13
- 1
- Kafka를 트리거 유형으로 지정합니다.
- 2
- Kafka가 오프셋 지연을 처리하는 Kafka 항목의 이름을 지정합니다.
- 3
- 연결할 Kafka 브로커의 쉼표로 구분된 목록을 지정합니다.
- 4
- 주제에서 오프셋을 확인하고 관련 지연을 처리하는 데 사용되는 Kafka 소비자 그룹의 이름을 지정합니다.
- 5
- 선택 사항: 스케일링을 트리거하는 평균 대상 값을 지정합니다. 따옴표로 묶은 문자열 값으로 지정해야 합니다. 기본값은
5
입니다. - 6
- 선택 사항: 활성화 단계의 대상 값을 지정합니다. 따옴표로 묶은 문자열 값으로 지정해야 합니다.
- 7
- 선택 사항: Kafka 소비자에 대한 Kafka 오프셋 재설정 정책을 지정합니다. 사용 가능한 값은
latest
및earliest
입니다. 기본값은latest
입니다. - 8
- 선택 사항: Kafka 복제본 수가 주제의 파티션 수를 초과할 수 있는지 여부를 지정합니다.
-
true
인 경우 Kafka 복제본 수는 주제의 파티션 수를 초과할 수 있습니다. 이를 통해 유휴 상태의 Kafka 소비자를 사용할 수 있습니다. -
false
인 경우 Kafka 복제본 수는 주제의 파티션 수를 초과할 수 없습니다. 이는 기본값입니다.
-
- 9
- Kafka 파티션에 유효한 오프셋이 없을 때 트리거가 작동하는 방법을 지정합니다.
-
true
인 경우 소비자는 해당 파티션에 대해 0으로 확장됩니다. -
false
인 경우 scaler는 해당 파티션에 대한 단일 소비자를 유지합니다. 이는 기본값입니다.
-
- 10
- 선택 사항: 현재 오프셋이 이전 폴링 사이클의 현재 오프셋과 동일한 파티션에 대해 트리거에 파티션 지연을 포함하거나 제외하는지 여부를 지정합니다.
-
true
인 경우 scaler는 이러한 파티션에서 파티션 지연을 제외합니다. -
false
인 경우 트리거는 모든 파티션에 모든 소비자 지연을 포함합니다. 이는 기본값입니다.
-
- 11
- 선택 사항: Kafka 브로커의 버전을 지정합니다. 따옴표로 묶은 문자열 값으로 지정해야 합니다. 기본값은
1.0.0
입니다. - 12
- 선택 사항: 스케일링 범위를 지정할 쉼표로 구분된 파티션 ID 목록을 지정합니다. 설정된 경우 지연을 계산할 때 나열된 ID만 고려합니다. 따옴표로 묶은 문자열 값으로 지정해야 합니다. 기본값은 모든 파티션을 고려하는 것입니다.
- 13
- 선택 사항: Kafka에 TSL 클라이언트 인증을 사용할지 여부를 지정합니다. 기본값은
disable
입니다. TLS 구성에 대한 자세한 내용은 "사용자 정의 메트릭 자동 스케일러 트리거 인증 이해"를 참조하십시오.
3.4.5. Cron 트리거 이해
시간 범위를 기반으로 Pod를 확장할 수 있습니다.
시간 범위가 시작되면 사용자 정의 지표 자동 스케일러는 구성된 최소 Pod 수에서 지정된 Pod 수로 오브젝트와 연결된 Pod를 스케일링합니다. 시간 범위가 끝나면 Pod가 구성된 최소로 다시 확장됩니다. 시간 기간은 cron 형식으로 구성해야 합니다.
다음 예제에서는 이 확장 오브젝트와 연결된 Pod를 오전 6시부터 오후 6 시
30분에서 오후 6시 30분으로 스케일링합니다.
Cron 트리거가 있는 확장 오브젝트의 예
apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 1 maxReplicaCount: 100 2 cooldownPeriod: 300 triggers: - type: cron 3 metadata: timezone: Asia/Kolkata 4 start: "0 6 * * *" 5 end: "30 18 * * *" 6 desiredReplicas: "100" 7