[Kubernetes] VPA를 사용하여 Pod의 Autoscaling 해보자

메린·2023년 5월 26일

Kubernetes

목록 보기

4/8

VPA를 사용하여 Pod의 Autoscaling

앞서 작성한 포스팅에서 확인할 수 있겠지만 흔히 아는 HPA, CA에 관련한 정리를 참고하고 보면 좋다.

VPA (Vertical Pod Autoscaler) 란 무엇인가?

앞서 설명했던 HPA는 => 수평적인 방향으로 새로운 Pod가 생성되는 것이라면, resource (more room for cpu or memory)를 추가하여 수직의 방향으로 커지는 것이 VPA이다.

수평으로 확장되는 HPA

수직 확장되는 VPA

VPA 를 이용한 Pod의 Autoscaling 실습을 진행해보자.

VPA를 설치한다.

Kubernetes version에 따른 VPA version 확인하고 설치하기

VPA git repository에서 소스코드를 직접 다운로드 해야한다.
- VPA는 현재 베타 기능이므로 Kubernetes 클러스터에서 기본적으로 제공되지 않는다. 따라서 VPA를 사용하려면 VPA의 git repository에서 소스코드를 직접 다운로드하고 설치 해야한다.

git clone https://github.com/kubernetes/autoscaler.git

이제 소스를 다운로드 했다면 repository 내에 vertical-pod-autoscaler 디렉토리에서 아래 script를 실행한다.

./hack/vpa-up.sh

설치후 Pod 가 생성된 것을 확인해볼 수 있었다.

kubectl get pod -n kube-system

예제 yaml 파일을 통해 vpa를 생성해보자.

yaml 파일을 이용하여 VPA를 생성한다.

kubectl create -f examples/hamster.yaml

VPA생성 후 VPA 정보를 확인한다.

kubectl describe vpa hamster-vpa

하단의 Recommendation을 보면 VPA가 추천해주는 리소스 크기를 확인할 수 있다.
위의 정보에서 Lower Bound는 리소스 사용량의 하한값, Target은 목표값, Upcapped Target은 제한이 없는 상태에서의 목표값, Upper Bound는 리소스 사용량의 상한값을 나타낸다.

VPA 구조

vpa을 설치하면 VerticalPodAutoscaler라는 custom resource가 설치된다.

다음으로 k8s api안에 admission webhook을 등록합니다.

그리고 나서 특정한 pod가 vpa를 사용하도록 설정하면 앞서말한 hook이 VPA recommender가 추천하는 값에 따라서 pod template의 resource request를 수정합니다.

- VPA admission webhook

K8s API에 들어오는 요청을 가로채서 유효성 검사, 수정 등의 작업을 수행하는 HTTP callback 이다.
VPA의 admission webhook은 Mutating admission webhook과 validating admission webhook으로 구성된다.
- Mutating admission webhook : 요청이 API 서버로 전동되기 전에 오브젝트를 수정하는 역할
- Validatind admission webhook : 수정이 완료된 후에 실행되어 요청의 유효성을 검사하고 실행 여부를 결정하는 역할
VPA를 설치하면 K8s 클러스터에 생성 요청되는 모든 Pod는 VPA admission webhook을 거친다.
webhook은 VerticalPodAutoscaler가 해당 Pod 또는 Pod의 부모 (ReplicaSet, Deployment등)를 참조하고 있는지 확인하고, 그렇다면 CPU와 메모리 크기를 수정한다.
즉, VPA admission webhook은 Pod의 리소스 요청을 조정하는 역할을 수행한다.

- VPA recommender

Metric Server에서 받아온 리소스 사용량 히스토리와 현재 리소스 사용량을 비교하여 각 Pod에 적합한 리소스 크기를 추천한다.

- VPA Updater

VPA updater는 1분에 한번씩 정기적으로 돌면서 실행 중인 Pod의 리소스 상태를 업데이트 한다. 실행되고 있는 Pod의 리소스가 recommender가 추천한 리소스 범위에 있는지 체크한다. 만일 그렇지 않다면 pod를 node에서 제거하여 pod가 재시작 되도록 만든다. 재시작시 VPA admission webhook이 pod가 시작되기 전 cpu와 memory를 새롭게 설정한다.

             +---------------------+
             |      VPA Updater     |
             +---------------------+
                        |
                        | (Regular interval)
                        |
                        V
             +---------------------+
             |     VPA Recommender   |
             +---------------------+
                        |
                        | (Recommendations)
                        |
                        V
             +---------------------+
             | VPA Admission Hook  |
             +---------------------+
                        |
                        | (Pod creation)
                        |
                        V
             +---------------------+
             |     Pod Resource    |
             |    Modification     |
             +---------------------+
                        |
                        | (Resource updates)
                        |
                        V
             +---------------------+
             |   Node Eviction     |
             +---------------------+
                        |
                        | (Pod restart)
                        |
                        V
            +-----------------------+
            |       New Pod         |
            +-----------------------+

되돌아보며

사실 HPA를 사용하면서 가장 크게 고민했던 부분이 Requests 값에 대한 부분이었다. 클러스터 내부에서 운영 중인 어플리케이션 특성에 따라 리소스 사용량이 다를것이며 운영 방식에 따라 설정 방법이 다르기 때문에 이 부분을 자동으로 조절하고 싶었다. 그 부분을 어느정도 해결해줄 수 있는 것이 VPA 라고 생각한다.

VPA는 현재 실행중인 파드의 리소스 사용량을 모니터링하고, 해당 파드의 사용량에 기반하여 적절한 리소스 요청 값을 제안한다.
VPA와 HPA는 같은 Resource metric을 사용하므로 함께 사용하기가 어렵다. 이를 위해 각각의 scope를 분리하여 다른 메트릭의 종류를 사용하는 것이 좋다. VPA는 주로 평균적인 리소스 사용량을 기준으로 하고, HPA는 현재 리소스 사용량을 기준으로 한다.
VPA는 Resource limit이 아니라 Resource Requests를 수정하지만, 초기에 설정한 request 와 limit의 비율을 유지하기 때문에 limit 역시 변경된다.