[EKS] HPA(Horizontal Pod Autoscaler)와 VPA(Vertical Pod Autoscaler) + 예제

vinca·2024년 3월 5일

Introduction

kubernetes 환경에서의 파드를 AutoScaling하는 방법에는 HPA, VPA 그리고 노드 단위인 CA가 존재한다.
여기서 HPA와 VPA에 대해서 알아보고, 예제를 통해 실습해 보자.

HPA

HPA(Horizontal Pod Autoscaler)로 즉, Horizontal : 수평방향으로 스케일링 하는 것을 의미한다.
수평 방향으로 늘리는 것을 Scale Out이라고 하며, 수평 방향으로 축소하는 것을 Scale In이라고 한다.

💡 수평적으로 동일한 파드가 복제되는 것으로 즉, 수량 자체가 늘어난다.

HPA의 구조

쿠버네티스의 Control-plane의 구성요소 중 API 서버에 HPA가 구성되고, controller-manager에는 HPA Controller가 구성된다.

이들은 서로 변경사항을 감시하고 있기에 서로의 정보를 알 수 있으며, 이는 Deployment와 ReplicaSet 또한 마찬가지이다.

HPA 동작 과정

HPA는 다음과 같이 동작한다.

HPA Controller가 메트릭 쿼리를 통해 메트릭 서버로부터 정보를 수집한다.
API 서버의 HPA는 HPA Controller에 수집된 정보를 바탕으로 적절한 Replicas 개수를 계산한다.
HPA Controller가 적절한 Replicas 개수가 되도록 Deployment를 업데이트 한다.
Deployment Controller가 ReplicaSet에게 적절한 개수가 되도록 업데이트한다.

+5. 이후 스케쥴러 및 kubelet을 통해 실제 파드의 수량이 조절된다.

📊 Metrics Server
HPA는 동적 스케일링이 수행되므로, 이러한 판단 기준이 되는 지표가 필요하다.
이러한 지표는 Metric Server가 kubelet을 통해서 메트릭을 수집해서 생성된다.

VPA

VPA(Vertical Pod Autoscaler)로 즉, Vertical : 수직방향으로 스케일링 하는 것을 의미한다.
수직 방향으로 파드의 CPU, Memory등의 스펙을 증가시키는 것을 Scale Up이라 하며, 반대로 감소 시키는 것은 Scale Down이라고 한다.

💡 파드는 그대로 있고, 해당 파드의 크기(스펙)가 커지거나, 작아지는 것을 의미한다.

VPA의 구조

VPA의 구조는 다음과 같다.

동일하게 메트릭 서버가 필요하며 메트릭 서버는 파드로부터 필요한 메트릭을 수집한다.

VPA의 동작과정

1. VPA Recommender가 VPA 정보를 읽어오고, 메트릭 서버로 부터 파드 자원 사용량을 수집한다.
이를 바탕으로 권장되는 파드 권장 사용량(Pod Recommender)을 정의한다.

2. 이러한 파드 권장 사용량을 VPA에게 전달한다.

3. VPA Updater가 VPA로부터 파드 권장 사용량(Pod Recommender) 정보를 가져온다.
현재 구성된 파드와 이 정보를 비교하여 업데이트할지 말지를 결정한다.

4. 파드의 수직 스케일링이 필요하다고 판단되면, 파드를 종료시키고, 5. Deployment를 통해 파드 재생성 프로세스로 진입한다.

6. VPA Admission Controller가 파드 권장 사용량(Pod Recommender) 정보를 가져와 7. 파드에게 전달한다.

즉, VPA는 파드 자원 사용량 메트릭을 메트릭 서버를 통해서 수집하고, 내부 알고리즘을 통해 권장 사양을 정의하여 필요에 따라 새로운 파드를 생성하게 된다.

HPA / VAP 예제

💡 다음과 같은 사전 작업이 완료된 상태로 수행합니다.

HPA 예제

테스트용 php-apache 설치

// 테스트용 php-apache 다운로드 및 확인
curl -s -O https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/application/php-apache.yaml
cat php-apache.yaml | yh

다음과 같이 cpu를 기준으로 최댓값 500m 최솟값 200m을 기준으로 설정된 deploymen를 배포해 보자.

// 테스트용 php-apache 배포
kubectl apply -f php-apache.yaml

// php-apache 동작 확인
kubectl exec -it deploy/php-apache -- cat /var/www/html/index.php

registry.k8s.io/hpa-example 이미지의 경우 어떻게 동작할까?
index.php 파일로 접근 시(접속 시), 단순 제곱근 연산을 통해서 컨테이너의 CPU에 부하를 주도록 설정되어 있다.

모니터링 - 신규 터미널

신규 터미널을 열고 모니터링을 수행해 보자.

// 모니터링 - 신규 터미널 (hpa, 파드 메트릭, 노드 메트릭)
watch -d 'kubectl get hpa,pod;echo;kubectl top pod;echo;kubectl top node'

접속 확인

해당 모니터링이 수행되는 상태로 접속을 수행해 보자.
실제로 과연 sqrt(루트)연산 작업에 의해서 파드의 CPU 부하가 증가할까?

curl -s $PODIP; echo
...반복 수행...

기존 1m CPU를 사용하던 파드가 무려 128m까지 CPU 사용량이 증가한 것을 확인할 수 있다.

HPA 생성

이제 이러한 접속에 따라서, HPA🧊가 동작하도록 해보자.

// HPA 생성 - 파드의 요청 CPU의 50% 이상일 경우 스케일링 수행
kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10

// HPA 확인
kubectl get pods
kubectl describe hpa

앞서 파드를 배포할 때, 기본 요청 CPU 값이 200m이였으므로, 50%로 설정하는 경우 100m 값이 기준이 된다.

💡 즉, 아까와 같이 128m(100m 이상의 값)까지 증가한다면 파드의 개수가 늘어나게 된다.

만약 여러대의 파드가 있다면 전체 파드의 CPU사용률의 평균을 기준으로 50%가 넘는 경우 HPA가 발생한다.

HPA 동작 확인

실제로 그렇게 HPA🧊가 동작하는 지 확인해 보도록 하자.

그라파나 대시보드 생성

Kubernetes / Horizontal Pod Autoscaler ID : 17125
Absolute time range : Last 15 minutes

php-apache에 부하 발생 🌊

// 부하 발생 - scale-out 확인
kubectl run -i --tty load-generator --rm --image=busybox:1.28 --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"

Kubernetes 클러스터에서 임시적으로 load-generator라는 이름의 Pod를 실행하고, 부하 테스트를 위해 busybox:1.28 이미지를 사용하여 0.01초마다 http://php-apache에 HTTP 요청을 보내는 작업을 수행한다.

Kubernetes CLI에서 확인
그라파나에서 확인

다음과 같이 파드 수량이 13개로 증가한 것을 확인할 수 있다.

php-apache에 부하 중지

Ctrl + C를 통해 부하 중지 후 scale-in 되는 과정을 확인해보자.
부하가 감소함에 따라 빠르게 파드의 개수가 감소하는 것을 확인할 수 있다.

VPA 환경 구성 및 동작 확인

이제 VPA에 대해서 알아보자.

VPA는 수직적으로 파드의 스케일을 조정할 수 있지만 파드가 삭제되고 재 생성되는 것은 어쩔 수 없다. 🥲

또한 VPA는 자동으로 작동하며,♻️ 사용자가 직접 지정하는 것은 지원하지 않는다. 🙅🏻‍♂️
즉, VPA 자체적으로 파드의 리소스 사용 패턴과 요구 사항을 지속적으로 모니터링하고, 이에 기반하여 파드의 CPU와 메모리 요청량을 자동으로 조절한다.

네임 스페이스 추가 및 모니터링

// 네임 스페이스 추가
kubectl create ns vpa

// 모니터링 - 신규터미널 (VPA 생성 자원 확인)
watch -d 'kubectl get pod -n vpa'

VPA는 HPA와 다르게 3개의 파드가 생성된다.
(이미 생성하고 난 뒤에 캡쳐했다. 😏)

VPA Recommender는 파드의 권장 사양을 결정하는 역할을 하고,

VPA Updater는 업데이트 할지를 결정한다. 만약, 업데이트가 필요하다면 기존 Pod를 종료시킨다.

이후 Admission Cotroller는 Recommender로 부터 생성된 권장 사양(Pod 스펙)을 신규 파드에게 전달한다.

VPA 설치

헬름차트를 통해서 설치하도록 하자.

// helm chart repository 추가
helm repo add fairwinds-stable https://charts.fairwinds.com/stable

// VPA 설치 
helm install vpa fairwinds-stable/vpa --namespace vpa

// vpa crd 정보 확인
kubectl get crd | grep autoscaling

VPA 동작 확인

모니터링을 위해 신규 터미널을 생성해서 파드의 CPU 및 Memory 상태를 체크하도록 하자.

// 모니터링 - 신규 터미널 (파드 메트릭 수집)
watch -d kubectl top pod

테스트용 자원 설치

// 테스트용 hamster 다운로드 및 확인
curl -s -O https://raw.githubusercontent.com/cloudneta/cnaeblab/master/_data/hamster.yaml

cat hamster.yaml | yh

// 테스트용 hamster 설치
kubectl apply -f hamster.yaml && kubectl get vpa -w

VerticalPodAutoscaler (VPA) 설정을 위한 리소스와, 이러한 VPA가 될 대상 파드 리소스의 정보가 있다.

컨테이너의 실행 명령을 보면 무한 루프를 통해 0.5초 동안 CPU에 부하를 주고, 다음 0.5초 동안은 휴식을 취하는 패턴을 무한히 반복하며 CPU 리소스를 지속적으로 사용하게 된다.

VPA 동작 정보 확인

// 파드 리소스 요구 사항 확인
kubectl describe pod | grep Requests: -A2

// VPA에 의해 파드 삭제 및 생성 이벤트 확인
kubectl get events --sort-by=".metadata.creationTimestamp" | grep VPA