Application Lifecycle Management - VPA

이 글에서는 “파드의 수직 스케일링”을 시험 관점에서 정리합니다. 흐름은 다음과 같습니다.

파드 리소스 변경의 기본 동작(재생성)
파드 리소스의 In-place(제자리) 크기 조정 개념과 제약
VPA(Vertical Pod Autoscaler): 수동 수직 확장 → VPA 자동화, 구성 요소, 동작 방식, 모드
HPA vs VPA 비교와 언제 무엇을 선택할지

1) 기본 동작: 파드 리소스(requests/limits) 변경은 “제자리 업데이트”가 아니다

Deployment에서 컨테이너 resources.requests/limits를 바꾸면, 쿠버네티스는 기본적으로 기존 파드를 삭제하고 새 파드를 만들어 적용합니다.

즉, 리소스 정의(CPU/메모리) 변경이 in-place로 적용되지 않고,
파드를 죽여야(new pod) 새로운 리소스 정의가 반영됩니다.

특히 Stateful workload(상태 저장 워크로드)에서는 이 “재생성”이 부담이 될 수 있습니다.

2) In-place Pod Vertical Scaling(제자리 파드 수직 스케일링) 개요

이 문제를 해결하기 위한 개선이 파드 리소스의 in-place 업데이트(in-place pod vertical scaling) 입니다.

녹화 시점 기준으로 이 기능은 알파(Alpha)로 제공되며, 기본 활성화가 아닙니다.
사용하려면 기능 플래그(Feature Gate)를 켜야 합니다(예: InPlacePodVerticalScaling=true).

2-1) 무엇이 달라지나?

이 기능이 활성화되면 “리소스 변경 시 재시작 필요 여부”를 리소스별로 정책화할 수 있습니다.

예를 들어:

CPU 리소스 변경은 파드 재시작 없이(in-place) 가능
메모리 리소스 변경은 재시작이 필요하다고 정책으로 지정

이렇게 되면 CPU를 1로 올린다 같은 변경은 파드를 죽이지 않고도 적용 가능한 형태를 목표로 합니다.

핵심: “항상 재생성”이던 리소스 변경을, 상황에 따라 재생성 없이 반영할 수 있게 하는 방향입니다.

2-2) In-place 리사이징 제약 사항(강의에서 강조한 제한)

다음은 “명심해야 할 제한”입니다.

CPU/메모리 리소스에 대해서만 동작
Pod의 QoS 클래스 등은 이 방식으로 변경할 수 없음
Init container, ephemeral container는 대상이 아님
리소스 requests/limits는 한 번 설정하면 ‘이동’할 수 없다(강의 표현상: 제약 존재)
메모리 limit은 현재 사용량보다 낮게 줄일 수 없음
- 줄이려는 시점에 사용량이 더 높으면, “가능해질 때까지” 리사이즈가 진행 중 상태로 남을 수 있음
Windows Pod는(현재로선) 불가

3) VPA로 가기 전: 수동 수직 확장(Manual Vertical Scaling)

이제 “자동”이 아닌, 사람이 직접 수직 확장하는 흐름부터 짚습니다.

가정:

Deployment의 파드가
- requests.cpu = 250m
- limits.cpu = 500m
운영자는 메트릭을 보고 “리소스가 부족하면 리소스 값을 올려야 한다”고 판단합니다.

3-1) 모니터링(메트릭 서버 전제)

kubectl top pod

이 명령이 동작하려면 Metrics Server가 클러스터에 있어야 합니다.

3-2) 임계값 도달 시, Deployment의 리소스 수정

kubectl edit deploy myapp

그리고 Pod 템플릿의 컨테이너 resources.requests/limits를 변경합니다.

예시:

spec:
  template:
    spec:
      containers:
      - name: app
        image: my-org/app:1.0
        resources:
          requests:
            cpu: "500m"
            memory: "512Mi"
          limits:
            cpu: "1000m"
            memory: "1Gi"

기본 동작에서는 저장 후:

기존 파드가 내려가고
새 리소스 정의를 가진 새 파드가 올라옵니다.

문제:

사람이 계속 보고 있어야 하고
수직 확장을 수동으로 해야 하며
변경 시 파드 재생성(재시작)이 끼어들기 쉽습니다.

이 자동화를 담당하는 게 VPA입니다.

4) VPA(Vertical Pod Autoscaler): 개념과 “왜 HPA처럼 바로 안 되나?”

4-1) HPA와 달리 VPA는 기본 내장 컴포넌트가 아니다

강의에서 강조하는 포인트:

HPA는 기본 제공
VPA는 기본 제공이 아니라 배포해야 함

즉, VPA를 쓰려면 먼저 VPA 구성 요소들을 클러스터에 설치해야 합니다.

4-2) VPA 설치(개요)

GitHub 저장소의 VPA 매니페스트(정의 파일)들을 적용
설치 후 kube-system 네임스페이스에서 VPA 관련 파드가 뜨는지 확인

kubectl -n kube-system get pods | grep vpa

강의 기준으로 다음 구성 요소들이 떠 있어야 합니다.

Recommender(추천기)
Updater(업데이터)
Admission Controller(어드미션 컨트롤러)

5) VPA는 어떻게 동작하나? (Recommender / Updater / Admission Controller)

VPA는 “파드 리소스를 자동으로 바꾸는” 일을 3개 컴포넌트로 나눠 처리합니다.

5-1) Recommender(추천기)

Kubernetes Metrics API에서 리소스 사용량을 지속적으로 수집
과거/실시간 사용량 데이터를 기반으로
최적의 CPU/메모리 requests/limits(또는 권장치) 를 계산해 추천(Recommendation) 을 생성
단, 직접 파드를 수정하진 않음(“제안”만 함)

5-2) Updater(업데이터)

“현재 리소스가 최적이 아닌 파드”를 감지
필요 시 Recommender의 추천을 조회
정책에 따라 파드를 Evict(퇴출) / 재생성 유도 같은 액션을 수행할 수 있음

5-3) Admission Controller(어드미션 컨트롤러)

파드 생성 과정에 개입
Recommender의 추천을 적용해 파드 스펙의 리소스 값을 조정
결과적으로 “새로 생성되는 파드가 추천 리소스로 시작”하게 만듦

정리하면:

추천기는 “추천”을 만들고,
업데이터는 “업데이트가 필요하면 파드 재생성을 유도”하고,
어드미션 컨트롤러는 “새 파드가 뜰 때 추천값을 주입”합니다.

6) VPA 오브젝트(YAML) 만들기: 무엇을 모니터링하고, 어디까지 조정할지

VPA는 HPA처럼 kubectl autoscale ... 한 방으로 끝나는 느낌이 아니라, VPA 리소스 오브젝트를 정의해서 사용합니다.

예시 구조:

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

  resourcePolicy:
    containerPolicies:
    - containerName: "*"
      minAllowed:
        cpu: "250m"
        memory: "256Mi"
      maxAllowed:
        cpu: "1500m"
        memory: "2Gi"

  updatePolicy:
    updateMode: "Auto"

targetRef: 어떤 워크로드를 대상으로 할지
resourcePolicy.containerPolicies: 리소스 조정 범위(최소/최대)
updatePolicy.updateMode: 실제 적용 방식(중요)

7) VPA Update Mode 4가지(강의 기준)

VPA는 모드에 따라 “추천만” 하거나 “재시작을 동반해 적용”합니다.

7-1) Off

추천만 하고 아무 것도 바꾸지 않음
사실상 Recommender만 동작

7-2) Initial

파드 생성 시점에만 추천을 적용
파드가 다른 이유로 새로 생성될 때(스케일아웃/롤링업데이트 등) 어드미션 컨트롤러가 개입해 추천값을 반영
업데이터가 “죽여서 바꾸는 동작”은 하지 않음

7-3) Recreate

리소스 소비가 범위를 벗어나면 업데이터가 개입
파드를 퇴출/재생성 시켜 추천 리소스로 뜨게 함
(기본 동작이 재생성이라는 현실과 맞물림)

7-4) Auto

“기존 파드를 권장 수치로 업데이트”하는 자동 모드
다만 강의에서는, 현 시점에서는 in-place 리사이징이 완전히 안정화되지 않아 Auto가 Recreate와 유사하게 동작한다고 설명합니다.
장기적으로는 in-place 업데이트가 안정화되면 Auto가 “재생성 없이” 선호되는 형태가 될 수 있다는 뉘앙스입니다.

8) VPA 추천값 확인

VPA가 충분히 메트릭을 모으고 나면 추천이 생성됩니다.

kubectl describe vpa myapp-vpa

출력에서 CPU/메모리에 대한 추천값(예: CPU를 1.5로 올리자 같은 형태)을 확인할 수 있습니다.

9) HPA vs VPA: 언제 무엇을 쓰나?

강의의 결론은 “둘 중 하나만 정답”이 아니라, 워크로드 특성과 목표에 따라 선택입니다.

9-1) 스케일링 방식

VPA: 파드(컨테이너) 1개의 CPU/메모리를 키우거나(또는 재생성으로 반영) “개별 파드 성능” 최적화
HPA: 파드 수를 늘려 “부하를 여러 인스턴스에 분산”

9-2) 가용성과 다운타임 관점

VPA: 새 리소스 적용을 위해 파드 재시작/재생성이 개입할 수 있음 → 다운타임/지연 가능성
HPA: 기존 파드는 유지한 채 새 파드를 추가로 띄움 → 가용성에 유리

9-3) 트래픽 스파이크 대응

HPA가 유리: 급격한 트래픽 증가에 빠르게 파드 수를 늘릴 수 있음
VPA는 불리: 재시작/재생성이 끼면 반응이 느려질 수 있음

9-4) 비용 최적화

VPA: 실제 사용량에 맞춰 requests/limits를 조정해 과도한 오버프로비저닝 방지
HPA: 유휴 파드를 줄여 불필요한 인스턴스 유지 비용 감소

9-5) 언제 VPA가 특히 유리한가?

강의에서 언급한 방향성:

상태 저장 워크로드, 데이터베이스, JVM 기반 앱, CPU/메모리 사용량이 큰 워크로드
또는 “초기 시작 시 CPU가 많이 필요하고, 이후엔 줄여도 되는” 유형
- 초기엔 크게 할당해 빠르게 스타트
- 초기화가 끝나면 할당량을 줄여 효율화

9-6) 언제 HPA가 특히 유리한가?

웹 애플리케이션, 마이크로서비스, 웹 서버, 메시지 큐, API 기반 서비스처럼
트래픽 변동이 크고 빠른 scale-out이 필요한 stateless 서비스

10) 요약

기본적으로 Deployment의 리소스(requests/limits) 변경은 파드 재생성을 유발한다.
이를 개선하려는 기능이 In-place Pod Vertical Scaling이며, 알파 단계에서 기능 플래그로 활성화하는 형태로 소개됐다.
VPA는 기본 내장 기능이 아니며 설치가 필요하고,
- Recommender(추천),
- Updater(퇴출/재생성 유도),
- Admission Controller(생성 시 추천값 주입)
  로 구성된다.
HPA는 파드 수, VPA는 파드 리소스를 조정한다.
빠른 트래픽 스파이크 대응은 HPA가 유리하고, 개별 파드 리소스 최적화/오버프로비저닝 방지는 VPA가 유리하다.

Practice Test Link: https://learn.kodekloud.com/user/courses/udemy-labs-certified-kubernetes-administrator-with-practice-tests/module/54a703bb-467f-40a5-90ee-c4fcf479501c/lesson/b4aa0137-fe1f-4470-9b74-865b45266131

'CKA' 카테고리의 다른 글

Cluster Maintenance - Cordon/Drain/Uncordon (1)	2025.12.31
Application Lifecycle Management - 총 정리 (0)	2025.12.31
Application Lifecycle Management - 오토스케일링과 HPA (0)	2025.12.30
Application Lifecycle Management - 멀티 컨테이터 파드 (1)	2025.12.30
Application Lifecycle Management - etcd에 저장되는 secret 암호화하기 (0)	2025.12.30

1) 기본 동작: 파드 리소스(requests/limits) 변경은 “제자리 업데이트”가 아니다

2) In-place Pod Vertical Scaling(제자리 파드 수직 스케일링) 개요

2-1) 무엇이 달라지나?

2-2) In-place 리사이징 제약 사항(강의에서 강조한 제한)

3) VPA로 가기 전: 수동 수직 확장(Manual Vertical Scaling)

3-1) 모니터링(메트릭 서버 전제)

3-2) 임계값 도달 시, Deployment의 리소스 수정

4) VPA(Vertical Pod Autoscaler): 개념과 “왜 HPA처럼 바로 안 되나?”

4-1) HPA와 달리 VPA는 기본 내장 컴포넌트가 아니다

4-2) VPA 설치(개요)

5) VPA는 어떻게 동작하나? (Recommender / Updater / Admission Controller)

5-1) Recommender(추천기)

5-2) Updater(업데이터)

5-3) Admission Controller(어드미션 컨트롤러)

6) VPA 오브젝트(YAML) 만들기: 무엇을 모니터링하고, 어디까지 조정할지

7) VPA Update Mode 4가지(강의 기준)

7-1) Off

7-2) Initial

7-3) Recreate

7-4) Auto

8) VPA 추천값 확인

9) HPA vs VPA: 언제 무엇을 쓰나?

9-1) 스케일링 방식

9-2) 가용성과 다운타임 관점

9-3) 트래픽 스파이크 대응

9-4) 비용 최적화

9-5) 언제 VPA가 특히 유리한가?

9-6) 언제 HPA가 특히 유리한가?

10) 요약

'CKA' 카테고리의 다른 글

티스토리툴바