KEDA

Kubernetes Event-Drived Autoscaling

쿠버네티스에서 지원하는 POD오토 스케일러는 CPU/MEM사용율 기반으로 POD의 개수를 동적으로 스케일링하는 기능을 지원한다.

CPU/MEM사용율외에 외부 지표(예: job queue size, http request rate ..)등에 기반해서 POD개수를 스케일링 하려면 상당히 번거롭고 많은 작업을 해야한다

(지표를 prometheus등의 메트릭스 서버에 수집하고, HPA에서 외부 메트릭스 서버 값 참조 하는 방식 등등...).

이를 쉽게 하기 위해서 KEDA 프로젝트가 오픈 소스로 시작 되었으며, CNCF재단의 인큐베이팅 프로젝트의 하나이다.

Architecture

KEDA는 다양한 소스로 부터 이벤트를 받아 애플리케이션 파드들을 오토 스케일링 하기 위한 목적으로 개발된 경량의 쿠버네티스 컴포넌트이다.

아래의 3가지 역할을 수행한다.

Agent

이벤트가 유무에 따라 애플리케이션 Deployment를 activate/deactivate시키는 역활 수행하는데, keda-operator POD에 의해서 수행 된다.

Metrics

다양한 이벤트를 제공하는 메트릭스 서버 역활을 수행한다(like kubernetes metrics server).

제공하는 지표들은 쿠버네티스 Horizontal Pod Autoscaler에 의해서 참조가 되어 진다.

keda-operator-metrics-apiserver POD에 의해서 수행된다.

Admission Webhooks

KEDA관련 자원들의 변경시 Validate를 자동으로 수행하는 역활을 한다(ex: 하나의 Scaled Target에 대해서 복수의 ScaledObject자원 허용 불가 등등..).

keda-admission-webhooks POD에 의해서 수행 된다.

동작 방식 및 특징

사용자가 KEDA에 관리를 요청하기 위한 ScaledObject자원을 생성하면, admission에 의해서 검수 되고,

유효한 자원일 경우 SclaedObject와 KEDA가 관리하는 HPA자원이 자동으로 생성된다.

자동으로 생성된 HPA자원의 지표 참조는 쿠베의 메트릭스 서버가 아닌 keda-metrics-apiserver를 참조 하도록 되어 있다.

즉 KEDA는 애플리케이션 POD들의 개수를 조절하 는스케링 작업을 직접 수행하지 않는다

(KEDA는 쿠버네티스 Horiontal POD Autoscaler를 대체할 목적이 아닌 확장/보조를 목표로 개발되었다)

아래 그림은 위의 설명을 이해를 돕기 위해 Kuberntes Addon형태로 제공되는 metrics server를 이용한 HPA구성과 KEDA를 사용한 HPA구성에 대한 그림이다.

KEDA는 쿠버네티스 Horizontal POD Autoscaler를 대체하거나, 대안(alternative)을 위해서 개발된게 아니라 확장 하기 위해서 개발 되었다.

KEDA와 연동 가능한 외부 스케일링 이벤트 소스 타입은 60개 이상 지원된다.

• CPU/MEM

• cron

• ActiveMQ

• RabbitMQ

• MySQL DB

• AWS DynamoDB

• AWS CloudWatch

• Prometheus

• Redis Lists

• 등등

  지원되는 전체 스케일러 목록은 공식 싸이트 참조

패키지 설치 및 스케일러 설정(Cron Scaler)

쿠버네티스 클러스터에 KEDA패키지를 설치하고, 특정 시간에 POD의 개수를 스케쥴링 하는 용도로 사용되는 Cron scaler를 사용해서 테스트를 진행해 보도록 한다.

KEDA 설치

• helm

• operator

• yaml manifest

위와 같이 3개의 방식으로 컴포넌트 설치가 가능하다.

이 글에서는 helm 차트를 이용해서 설치 한다.

(다른 방법이 궁금하신 분들은 공식 싸이트의 설치 가이드 페이지를 참고)

1.헬름 레포 추가 및 업데이트

> helm repo add kedacore https://kedacore.github.io/charts
> helm repo update

2.네임스페이스 생성하기

> kubectl create namespace keda

3.keda패키지 설치 하기

> helm install keda kedacore/keda --namespace keda

4.설치된 KEDA관련 자원들 확인

> kubectl get all -n keda

Cron Scaler 설정하기

KEDA가 인식하는 스케일링 명세 자원인 scaled-object자원을 아래 처럼 작성한다

(예시로든 관리 대상 MSA서비스는 point-admin이다)

Scaled Object자원 명세 파일 작성하기

point-admin-deploy-scaled-obj.yaml 파일

주요 설정 값 설명

spec.scaleTargetRef.name

Scaled Object에 의해서 관리되어져야할 POD Deployment자원의 이름

spec.minReplicaCount

최소 POD개수 명세(HPA와는 달리 0을 설정 할수 있다.)

spec.triggers.type

스케일러 타입(위에서 언급한 것처럼 약 60가지의 타입이 지원 된다)

spec.triggers[0].metadata.start/end

desiredReplicas값을 “1”로 제공하기 시작할 시작 시간과 중단할 시간 주기(unix cron잡 주기 설정과 같은 포맷이다.)

spec.triggers[0].metadata.timszone

아래 start/end시간 설정시 사용할 타임 zone 정보(Asia/Seoul로 설정해 주면, +9를 하지 않고 편하게 서울 시간으로 설정 가능 하다)

Scaled Object자원 생성하기

타겟이 되는 Deployment/point-admin-deployment와 추가하는 point-admin-scaled-obj scaledobject는 같은 네임 스페이스에 있어야 한다.

> kubectl create -f point-admin-deploy-scaled-obj.yaml -n mps

생성된 point-admin-scaled-obj자원 확인하기

> kubectl get scaledobject point-admin-scaled-obj -n mps

생성된 HPA자원명 확인하기

> echo `kubectl get scaledobject point-admin-scaled-obj -n mps -o jsonpath='{.status.hpaName}'`

생성된 HPA자원 확인

> kubectl get hpa keda-hpa-point-admin-scaledobj -n mps

Kube클러스터의 HPA를 이용해서 KEDA는 스케일링을 한다. 위의 그림을 보면 scaledobject를 생성한 결과 keda가 자동으로 HPA자원을 생성한 것을 확인 할수 있다.

KEDA scaledobject를 사용하면 따로 파드의 HPA자원을 생성하지 말아야 한다(경합이 발생해서 원하지 않는 결과가 발생 할수 있다. 주의 필요!!!)

스케쥴링 결과 확인

매 시간 마다 4번씩 실행되는걸 확인 할수 있다.

참고 사항:

scaled-object생성시 자동으로 생성된 keda-hpa-point-admin-scaled-obj HPA자원 살펴 보기

HPA자원에 metrics항목이 KEDA가 제공하는 metrics서버를 참조하도록 external로 정의 되어 있다.

개발/운영 환경 클러스터가 야간에 운영될 필요가 없다면,

애플리케이션 POD들의 실행 개수를 0으로 스케쥴링하여, 클러스터 노드 그룹이 자연 스럽게 Scale-in되도록 하면 운용 비용 절감을 기대 할수 있다

(NodeGroup에 대해서도 오토스케일링이 적용되어 있어야 한다)