Kubernetes HPA VPA 차이와 장단점 총정리 - Pod 자동 확장과 리소스 최적화

Kubernetes HPA VPA 차이와 장단점 총정리

Kubernetes 환경에서 애플리케이션을 운영하다 보면 트래픽 증가나 CPU 및 Memory 사용량 변화에 따라 Pod의 개수를 늘리거나 각 Pod에 할당된 리소스를 조정해야 하는 상황이 발생합니다.

이를 자동화하기 위해 Kubernetes에서는 대표적으로 HPA(Horizontal Pod Autoscaler)와 VPA(Vertical Pod Autoscaler)를 사용할 수 있습니다.

두 기능 모두 Kubernetes의 Autoscaling을 위한 기능이지만 확장 방식에는 큰 차이가 있습니다.

HPA = Pod 개수를 늘리거나 줄인다.

VPA = Pod 하나에 할당되는 CPU / Memory 리소스를 조정한다.

즉 HPA는 Scale Out / Scale In, VPA는 Scale Up / Scale Down 및 Resource Rightsizing 관점에서 이해하면 쉽습니다.

1. Kubernetes Autoscaling이란?

Kubernetes Autoscaling은 워크로드의 부하와 리소스 사용량에 따라 Pod 또는 리소스 크기를 자동으로 조정하는 기능입니다.

대표적인 Autoscaling 방식은 다음과 같이 구분할 수 있습니다.

구분	기능	확장 대상
HPA	Horizontal Pod Autoscaler	Pod 개수
VPA	Vertical Pod Autoscaler	Pod CPU / Memory Request 및 Limit
Node Autoscaling	Node 용량 자동 조절	Worker Node

따라서 Pod 레벨에서는 HPA와 VPA를 이해하는 것이 가장 중요합니다.

2. HPA란?

HPA(Horizontal Pod Autoscaler)는 CPU, Memory 또는 Custom Metric 등의 상태를 기준으로 Deployment나 StatefulSet과 같은 워크로드의 Replica 수를 자동으로 변경하는 기능입니다.

예를 들어 애플리케이션 Pod가 2개 실행되고 있고 CPU 사용률이 증가하면 다음과 같이 확장할 수 있습니다.

정상 상태

Pod 1
Pod 2


CPU 사용량 증가

Pod 1
Pod 2
Pod 3
Pod 4
Pod 5


CPU 사용량 감소

Pod 1
Pod 2

즉 하나의 Pod에 CPU를 더 할당하는 것이 아니라 동일한 역할을 수행하는 Pod를 추가 생성하여 부하를 분산합니다.

3. HPA 동작 구조

                Metrics Server
                      │
                      │ CPU / Memory Metric
                      ▼
              HPA Controller
                      │
                      │ Replica 조정
                      ▼
                 Deployment
                      │
          ┌───────────┼───────────┐
          ▼           ▼           ▼
        Pod 1       Pod 2       Pod 3

HPA Controller는 설정된 Metric과 현재 상태를 비교한 후 필요한 Replica 수를 계산합니다.

Kubernetes의 HPA 제어 루프는 기본적으로 주기적으로 Metric을 확인하며, 기본 동기화 주기는 kube-controller-manager의 --horizontal-pod-autoscaler-sync-period 설정에 의해 결정됩니다. 기본값은 15초입니다.

4. HPA에서 사용할 수 있는 Metric

HPA는 다양한 Metric을 기준으로 Pod를 확장할 수 있습니다.

Metric	설명
CPU	Pod CPU 사용률
Memory	Pod Memory 사용량
Custom Metric	애플리케이션에서 정의한 Metric
External Metric	외부 시스템에서 제공하는 Metric

기본적인 CPU와 Memory 기반 HPA에서는 일반적으로 Metrics Server가 사용됩니다. 보다 복잡한 Autoscaling을 구현하려면 Custom Metrics API 또는 External Metrics API를 사용할 수 있습니다.

5. HPA 설정 예제

다음은 CPU 사용률을 기준으로 Pod 개수를 자동 조정하는 HPA 예제입니다.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app

  minReplicas: 2
  maxReplicas: 10

  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

위 설정은 다음 의미를 가집니다.

최소 Pod : 2개
최대 Pod : 10개
목표 CPU 사용률 : 평균 70%

CPU 사용률이 목표보다 높아지면 HPA가 Replica를 증가시키고, 부하가 감소하면 안정화 정책 등을 고려하여 Replica를 감소시킵니다.

6. HPA에서 Resource Request가 중요한 이유

CPU 사용률을 Percentage 방식으로 사용하는 HPA에서는 Pod의 resources.requests.cpu 설정이 매우 중요합니다.

예를 들어 다음과 같이 설정했다고 가정합니다.

resources:
  requests:
    cpu: 500m
    memory: 1Gi
  limits:
    cpu: 1000m
    memory: 2Gi

HPA CPU Utilization은 단순히 Node 전체 CPU 대비 사용률을 계산하는 것이 아니라, 해당 Container에 설정된 CPU Request 대비 실제 CPU 사용량을 기준으로 계산합니다.

예를 들어 CPU Request가 500m이고 실제 CPU 사용량이 350m라면:

350m / 500m × 100

= 70%

따라서 CPU Request 값이 실제 워크로드 특성과 지나치게 다르면 HPA가 예상과 다르게 Scale Out 또는 Scale In할 수 있습니다.

중요: CPU Utilization 기반 HPA를 사용하는 경우 관련 Container에 CPU Request가 정의되어 있어야 합니다. Request가 없으면 해당 Pod의 CPU Utilization을 정상적으로 계산하지 못해 해당 Metric을 이용한 Scaling이 동작하지 않을 수 있습니다.

7. HPA 장점

트래픽 증가 대응

사용자가 증가하거나 요청량이 급격하게 증가할 경우 자동으로 Pod를 추가할 수 있습니다.

고가용성 구성에 유리

여러 Pod로 서비스를 분산할 수 있기 때문에 하나의 Pod에 장애가 발생하더라도 다른 Pod를 통해 서비스를 유지하기 쉽습니다.

자동 Scale In

부하가 감소하면 필요 없는 Pod를 제거하여 리소스 낭비를 줄일 수 있습니다.

다양한 Metric 사용 가능

CPU와 Memory뿐 아니라 Custom Metric 및 External Metric을 활용하면 요청량, Queue 길이 등 워크로드 특성에 맞는 확장 정책을 구성할 수 있습니다.

8. HPA 단점

Pod 시작 시간이 필요하다

Scale Out이 결정된 이후에도 Pod 생성, Image Pull, Container 시작, Readiness Probe 통과 등의 과정이 필요합니다.

부하 증가
   ↓
HPA 감지
   ↓
Replica 증가
   ↓
Pod 생성
   ↓
Image Pull
   ↓
Application 시작
   ↓
Readiness 성공
   ↓
실제 트래픽 처리

따라서 시작 시간이 긴 Java, WildFly 등의 애플리케이션에서는 급격한 트래픽 증가에 대한 대응이 늦어질 수 있습니다.

Node 리소스가 부족하면 Pod가 생성되지 않는다

HPA가 Replica를 증가시키더라도 Worker Node에 CPU 또는 Memory 여유가 없다면 신규 Pod가 Scheduling되지 못하고 Pending 상태가 될 수 있습니다.

HPA

Pod 3개 → Pod 6개 요청

하지만 Worker Node 리소스 부족

Pod 1 Running
Pod 2 Running
Pod 3 Running
Pod 4 Pending
Pod 5 Pending
Pod 6 Pending

중요: HPA는 Worker Node 자체의 CPU나 Memory를 증가시키는 기능이 아닙니다. Worker Node 증설이 불가능한 환경에서는 HPA의 maxReplicas를 높인다고 해서 무조건 처리 용량이 증가하는 것은 아닙니다.

9. VPA란?

VPA(Vertical Pod Autoscaler)는 Pod의 CPU와 Memory 사용 패턴을 분석하여 적절한 Resource Request 및 Limit 값을 추천하거나 자동으로 적용하는 기능입니다.

예를 들어 기존 Pod가 다음과 같이 설정되어 있다고 가정합니다.

CPU Request    : 500m
Memory Request : 512Mi

실제 사용량을 분석한 결과 리소스가 부족하다고 판단되면 VPA는 다음과 같은 값을 추천할 수 있습니다.

CPU Request    : 1000m
Memory Request : 2Gi

즉 Pod 개수를 늘리는 것이 아니라 Pod 하나의 Resource Size를 조정합니다.

10. VPA 동작 구조

              Metrics Server
                    │
                    ▼
             VPA Recommender
                    │
             사용량 분석
                    │
                    ▼
          CPU / Memory 권장값
                    │
          ┌─────────┴─────────┐
          │                   │
          ▼                   ▼
     Recommendation        Updater
                              │
                              ▼
                         Pod Resource
                           조정

VPA는 주요하게 다음 구성요소를 이용합니다.

구성요소	역할
Recommender	현재 및 과거 리소스 사용량을 분석하고 적정 Resource 값을 계산
Updater	현재 Pod Resource와 권장값을 비교하고 정책에 따라 변경 수행
Admission Controller	새롭게 생성되는 Pod에 VPA 권장 Resource 값을 적용

11. HPA와 VPA의 설치 방식 차이

HPA는 Kubernetes API와 Controller에 포함되어 있지만, VPA는 기본 Kubernetes Core 기능으로 자동 설치되는 구성요소가 아닙니다.

VPA를 사용하려면 VPA 관련 CRD와 Controller 구성요소를 별도로 설치해야 합니다. 현재 VPA API에서는 autoscaling.k8s.io/v1을 사용합니다.

HPA
 └─ Kubernetes 기본 API / Controller

VPA
 ├─ CRD
 ├─ Recommender
 ├─ Updater
 └─ Admission Controller

12. VPA Update Mode

VPA에서는 리소스 추천값을 어떻게 적용할 것인지 Update Mode를 지정할 수 있습니다.

Mode	동작	특징
Off	추천값만 계산	기존 Pod 변경 없음
Initial	Pod 생성 시 적용	실행 중인 Pod에는 자동 변경하지 않음
Recreate	필요 시 Pod를 Eviction 후 재생성	재생성된 Pod에 새로운 Resource 적용
InPlaceOrRecreate	가능하면 In-place 변경, 불가능하면 재생성	클러스터 및 VPA 버전 지원 여부 확인 필요
InPlace	Eviction 없이 In-place 변경 시도	지원 버전 및 Feature 상태 확인 필요

주의: VPA의 In-place 관련 지원 상태는 Kubernetes 버전과 VPA 버전에 따라 달라질 수 있습니다. 운영 환경에 적용하기 전 현재 사용 중인 Kubernetes와 VPA 버전의 공식 문서를 확인해야 합니다.

13. VPA 설정 예제

처음 VPA를 적용하는 운영 환경에서는 자동 변경보다 Off 모드로 Recommendation을 확인하는 방식이 유용합니다.

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: web-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app

  updatePolicy:
    updateMode: "Off"

이 경우 VPA는 리소스를 직접 변경하지 않고 Recommendation만 계산합니다.

다음 명령으로 확인할 수 있습니다.

kubectl describe vpa web-vpa

VPA에서는 일반적으로 다음과 같은 값을 확인할 수 있습니다.

Lower Bound
Target
Upper Bound

Target은 일반적인 사용 패턴을 고려한 권장값이며, Lower Bound와 Upper Bound는 각각 적정 Resource 범위의 하한과 상한을 의미합니다.

14. VPA Resource 범위 제한

VPA가 지나치게 높거나 낮은 값을 설정하지 않도록 최소 및 최대 Resource 범위를 지정할 수 있습니다.

resourcePolicy:
  containerPolicies:
  - containerName: application

    minAllowed:
      cpu: 500m
      memory: 1Gi

    maxAllowed:
      cpu: 4
      memory: 8Gi

이를 통해 VPA Recommendation이 설정한 범위를 벗어나지 않도록 제한할 수 있습니다.

15. VPA 장점

Resource Request 최적화

실제 사용량을 기반으로 CPU와 Memory Request를 조정할 수 있어 과도한 Resource Request 설정으로 인한 낭비를 줄일 수 있습니다.

Resource 부족 문제 분석

CPU 또는 Memory Request가 지나치게 낮은 애플리케이션을 찾아내고 적절한 Resource 크기를 판단하는 데 유용합니다.

운영 초기 Resource 산정에 유용

신규 애플리케이션의 적정 CPU와 Memory를 알기 어려운 경우 VPA Recommendation을 일정 기간 수집하면 Resource 산정 자료로 활용할 수 있습니다.

16. VPA 단점

Pod 재생성이 발생할 수 있다

VPA의 Update Mode와 클러스터 기능에 따라 Resource를 변경하기 위해 기존 Pod를 Eviction하고 새로운 Pod를 생성해야 할 수 있습니다.

기존 Pod
CPU 500m / Memory 1Gi
        │
        │ VPA 변경 필요 판단
        ▼
Pod Eviction
        │
        ▼
새 Pod 생성
        │
        ▼
CPU 1 / Memory 2Gi

이 과정에서 Replica 수가 적거나 PodDisruptionBudget 등의 보호 설정이 부족하면 서비스 영향 가능성을 고려해야 합니다.

Node에 충분한 Resource가 필요하다

VPA가 CPU 4 Core, Memory 8Gi를 권장하더라도 해당 Pod를 배치할 수 있는 Worker Node가 없다면 Scheduling 문제가 발생할 수 있습니다.

급격한 트래픽 증가 대응 목적과는 다르다

VPA는 Resource Rightsizing에 강점이 있으며, 순간적으로 증가하는 요청을 여러 Pod로 분산하는 HPA와 목적이 다릅니다.

17. HPA와 VPA 핵심 비교

구분	HPA	VPA
정식 명칭	Horizontal Pod Autoscaler	Vertical Pod Autoscaler
확장 방식	수평 확장	수직 확장 / Rightsizing
조정 대상	Pod Replica	CPU / Memory Request 및 정책에 따른 Limit
대표 목적	트래픽 및 부하 대응	Pod Resource 최적화
Pod 개수	변경	기본적으로 변경하지 않음
Pod Resource	변경하지 않음	변경 가능
Metrics Server	CPU/Memory Resource Metric 사용 시 필요	필요
Kubernetes 기본 포함	HPA API/Controller 포함	별도 설치 필요
대표 활용	Web/WAS/API	Resource Rightsizing

18. 그림으로 보는 HPA와 VPA 차이

HPA

부하 증가

Before

┌─────────┐
│  Pod A  │
└─────────┘
┌─────────┐
│  Pod B  │
└─────────┘


After

┌─────────┐
│  Pod A  │
└─────────┘
┌─────────┐
│  Pod B  │
└─────────┘
┌─────────┐
│  Pod C  │
└─────────┘
┌─────────┐
│  Pod D  │
└─────────┘

Pod 개수 증가

VPA

Before

┌────────────────────────┐
│ Pod A                  │
│ CPU    : 500m          │
│ Memory : 1Gi           │
└────────────────────────┘


After

┌────────────────────────┐
│ Pod A                  │
│ CPU    : 1000m         │
│ Memory : 2Gi           │
└────────────────────────┘

Pod Resource 증가

19. HPA와 VPA를 동시에 사용할 수 있을까?

가능하지만 동일한 Resource Metric을 HPA와 VPA가 동시에 제어하도록 구성할 때는 주의가 필요합니다.

예를 들어 다음과 같은 구성입니다.

HPA
CPU 사용률을 기준으로
Pod 개수 조정

+

VPA
CPU Request를 자동 변경

CPU Utilization 기반 HPA는 CPU Request 대비 실제 CPU 사용량을 이용합니다. 그런데 VPA가 CPU Request 값을 계속 변경하면 HPA가 계산하는 CPU Utilization의 기준값도 함께 변할 수 있습니다.

예를 들어:

실제 CPU 사용량 = 500m


CPU Request = 500m

500 / 500 × 100
= 100%


VPA가 CPU Request를 1000m으로 변경

500 / 1000 × 100
= 50%

실제 애플리케이션 CPU 사용량은 동일하지만 Request 변경으로 HPA가 보는 Utilization 값이 달라질 수 있습니다.

따라서 HPA와 VPA를 동시에 사용할 때는 두 Autoscaler가 어떤 Metric과 Resource를 제어하는지 명확하게 설계해야 합니다.

20. HPA + VPA를 함께 사용하는 방법

실무에서는 다음과 같은 방식으로 역할을 분리하는 방법을 고려할 수 있습니다.

VPA
 └─ CPU / Memory 적정 Request 분석
        │
        ▼
Resource Rightsizing

HPA
 └─ 트래픽 / Request / External Metric
        │
        ▼
Pod Replica 조정

예를 들어 VPA는 Off 모드로 Resource Recommendation만 수집하고, HPA는 실제 Autoscaling을 담당하도록 구성할 수 있습니다.

VPA = Recommendation

HPA = 실제 Scale Out / Scale In

이 방식은 운영 환경에서 VPA가 Resource를 직접 변경하면서 발생할 수 있는 영향도를 줄이고, 관리자가 Recommendation을 검토하여 Deployment Resource를 조정할 수 있다는 장점이 있습니다.

21. HPA가 적합한 환경

다음과 같은 환경은 HPA 적용을 우선 검토할 수 있습니다.

Web Application
API Server
NGINX
Stateless WAS
Microservice
Queue Worker
트래픽 변동이 큰 서비스

특히 여러 Replica로 동시에 실행해도 문제가 없는 Stateless 애플리케이션에 적합합니다.

22. VPA가 적합한 환경

VPA는 다음과 같은 환경에서 유용합니다.

적정 CPU / Memory를 모르는 애플리케이션

Resource Request가 과도하게 설정된 Pod

Memory 부족이 자주 발생하는 Pod

Resource 사용 패턴 분석이 필요한 환경

Pod 수 증가보다 Pod 자체 Resource 조정이 중요한 환경

특히 처음에는 VPA를 자동 적용하지 않고 Off 모드로 사용하여 Resource Recommendation을 확인하는 방식이 운영 환경에서 유용합니다.

23. WildFly / WAS 환경에서는 어떻게 적용할까?

WildFly와 같은 Java WAS는 JVM Heap과 Kubernetes Memory 설정의 관계를 함께 고려해야 합니다.

예를 들어 다음과 같은 구조가 있을 수 있습니다.

Pod Memory Limit
      │
      ▼
JVM Heap
-Xms / -Xmx
      │
      ▼
WildFly Application

VPA가 Memory Limit이나 Request를 변경한다고 해서 JVM의 -Xmx 설정까지 자동으로 적절하게 변경되는 것은 아닙니다.

따라서 Java/WildFly 환경에서 VPA를 자동 적용하려면 JVM Heap 정책과 Container Memory 설정의 관계를 반드시 검토해야 합니다.

반면 HPA는 Pod 자체를 추가하기 때문에 Stateless하게 구성된 WildFly WAS라면 비교적 활용하기 쉽습니다. 다만 Session을 Pod Local Memory에만 저장하는 구조라면 Scale Out 전에 Session 처리 방식을 확인해야 합니다.

24. Worker Node 증설이 불가능한 환경

Worker Node를 추가할 수 없는 환경에서는 HPA와 VPA 모두 현재 Kubernetes Cluster의 총 CPU 및 Memory 용량 안에서만 동작할 수 있습니다.

예를 들어 전체 Worker Node에서 실제 사용할 수 있는 여유가 다음과 같다고 가정합니다.

남은 CPU    : 12 Core
남은 Memory : 32Gi

HPA가 Pod를 계속 추가하거나 VPA가 Pod의 Request를 계속 높이면 결국 이 Resource를 소진하게 됩니다.

Cluster Resource
        │
        ├─ 기존 Pod
        │
        ├─ HPA 신규 Pod
        │
        └─ VPA Resource 증가
                │
                ▼
        Resource 부족
                │
                ▼
            Pod Pending

Worker Node 증설이 불가능한 환경에서는 HPA/VPA 설정 전에 Cluster 전체 Allocatable CPU/Memory와 현재 Requests 사용량을 먼저 확인하는 것이 중요합니다.

25. HPA 적용 전 확인사항

HPA를 적용하기 전에 다음 항목을 확인하는 것이 좋습니다.

1. Metrics Server 정상 동작 여부

2. Pod CPU / Memory Request 설정

3. minReplicas / maxReplicas 설정

4. Worker Node Resource 여유

5. Pod 시작 시간

6. Readiness / Liveness Probe

7. Scale Down 정책

8. Session 공유 구조

9. Application Stateless 여부

10. Pod 증가 시 DB Connection 증가량

특히 WAS Pod를 늘리면 DB Connection Pool도 함께 증가할 수 있으므로 DB의 max_connections와 Connection Pool 설정까지 함께 확인해야 합니다.

26. VPA 적용 전 확인사항

1. Metrics Server 정상 동작 여부

2. VPA 설치 여부

3. 현재 CPU / Memory Request

4. 현재 CPU / Memory Limit

5. VPA Update Mode

6. Pod 재생성 영향

7. PodDisruptionBudget

8. Worker Node Resource 여유

9. JVM Heap 등 Application 내부 Resource 설정

10. HPA 동시 사용 여부

27. 현재 Resource 사용량 확인

Metrics Server가 정상이라면 다음 명령으로 Pod Resource 사용량을 확인할 수 있습니다.

kubectl top pods

Node Resource 사용량은 다음과 같이 확인합니다.

kubectl top nodes

Pod의 Request와 Limit은 다음 명령으로 확인할 수 있습니다.

kubectl describe pod POD_NAME

28. HPA 상태 확인

kubectl get hpa

kubectl describe hpa HPA_NAME

예를 들어 다음과 같은 형태로 확인할 수 있습니다.

NAME      REFERENCE          TARGETS   MINPODS   MAXPODS   REPLICAS
web-hpa   Deployment/web     65%/70%   2         10        3

현재 CPU 사용률이 Target에 근접하고 있는지, 현재 Replica가 몇 개인지 등을 확인할 수 있습니다.

29. VPA Recommendation 확인

kubectl get vpa

kubectl describe vpa VPA_NAME

또는 YAML 형태로 전체 상태를 확인할 수 있습니다.

kubectl get vpa VPA_NAME -o yaml

주요 확인 대상은 다음과 같습니다.

status:
  recommendation:
    containerRecommendations:
      target:
      lowerBound:
      upperBound:

30. HPA와 VPA 선택 기준

상황	검토 대상
트래픽 증가에 따라 Pod를 늘리고 싶다	HPA
CPU 사용량에 따라 Replica를 조정하고 싶다	HPA
Pod에 적정 CPU를 모르겠다	VPA Recommendation
Pod에 적정 Memory를 모르겠다	VPA Recommendation
Resource Request를 자동 최적화하고 싶다	VPA
Web/WAS/API의 부하를 여러 Pod로 분산하고 싶다	HPA
운영 중 Resource 설정값을 분석하고 싶다	VPA Off Mode
Pod 개수와 Resource 최적화를 모두 고려해야 한다	HPA + VPA 역할 분리 검토

31. HPA와 VPA 한눈에 정리

              Kubernetes Autoscaling
                       │
          ┌────────────┴────────────┐
          │                         │
          ▼                         ▼
         HPA                       VPA
          │                         │
          ▼                         ▼
     Pod 개수 조정             Pod Resource 조정
          │                         │
     Scale Out/In              CPU / Memory
          │                         │
          ▼                         ▼
     부하 분산                  Resource 최적화


예)

HPA
Pod 2개 → 5개


VPA
CPU 500m → 1000m
Memory 1Gi → 2Gi

32. 결론

Kubernetes의 HPA와 VPA는 모두 Autoscaling 기능이지만 목적과 동작 방식이 다릅니다.

HPA는 Pod 개수를 자동으로 조절하여 트래픽과 부하 변화에 대응하는 기능이고, VPA는 Pod의 CPU 및 Memory Resource를 분석하고 적절한 Request/Limit을 추천하거나 적용하는 기능입니다.

Web, API, NGINX, Stateless WAS처럼 여러 Pod로 부하를 분산할 수 있는 애플리케이션에서는 HPA가 효과적으로 활용될 수 있습니다.

반면 적절한 CPU 및 Memory Request를 알기 어렵거나 현재 Resource 설정이 실제 사용량에 적절한지 분석하려는 환경에서는 VPA가 유용합니다.

두 기능을 함께 사용할 수도 있지만 CPU Utilization 기반 HPA와 CPU Request를 변경하는 VPA를 동시에 사용할 경우 서로의 Scaling 판단에 영향을 줄 수 있으므로 Metric과 Resource 제어 범위를 명확하게 설계해야 합니다.

또한 HPA와 VPA 모두 Worker Node의 물리적인 Resource 한계를 넘어설 수는 없습니다. 따라서 Autoscaling을 적용하기 전에 Node의 Allocatable Resource, 현재 Pod Requests, 최대 Replica 수, Pod 시작 시간, JVM 및 DB Connection 등의 요소를 함께 검토하는 것이 중요합니다.

33. 참고 자료

Kubernetes 공식 문서에서는 HPA를 Deployment 또는 StatefulSet 등의 Replica 수를 Metric에 따라 자동으로 조정하는 기능으로 설명하고 있습니다.

VPA는 Pod의 실제 및 과거 Resource 사용량을 분석하여 CPU와 Memory Request를 적정 수준으로 조정하기 위한 Autoscaling 기능입니다.

공식 Kubernetes 문서:

https://kubernetes.io/docs/concepts/workloads/autoscaling/

https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/

https://kubernetes.io/docs/concepts/workloads/autoscaling/vertical-pod-autoscale/