Application Lifecycle Management - 오토스케일링과 HPA

이번 섹션은 시험 관점에서 쿠버네티스 자동 스케일링을 “전체 지도” 수준으로 정리하고, 그중 HPA(Horizontal Pod Autoscaler) 를 조금 더 구체적으로 다룹니다. 자동 스케일링은 방대한 주제지만, 아래 개념만 잡아도 HPA/VPA/Cluster Autoscaler가 어디에 붙는지 헷갈리지 않습니다.

---

1) 스케일링의 원형: 수직 vs 수평

쿠버네티스 이전의 “서버 스케일링” 개념을 먼저 떠올리면 쉽습니다.

수직 확장(Vertical Scaling, Scale Up)

• 기존 서버(인스턴스) 1대의 CPU/메모리 리소스를 키우는 것
• 전통적으로는 서버 교체/증설로 다운타임이 생기기 쉬움

수평 확장(Horizontal Scaling, Scale Out)

• 서버(인스턴스) 대수를 늘려 부하를 분산하는 것
• 무중단 확장에 유리(로드밸런싱 전제)

---

2) 쿠버네티스에서는 스케일링 “대상”이 2개다: 워크로드 vs 클러스터

쿠버네티스에서 스케일링은 1개 축이 아니라 2개 축입니다.

• 워크로드 스케일링: 파드(Pod) 개수 또는 파드에 할당된 리소스 조정
• 클러스터(인프라) 스케일링: 노드(Node) 개수 또는 노드 스펙 조정

이를 합치면 아래처럼 4가지 조합이 됩니다.

                | 수평(Horizontal)                 | 수직(Vertical)
----------------+----------------------------------+------------------------------
워크로드         | 파드 수 늘림/줄임               | 파드 requests/limits 늘림/줄임
클러스터(인프라) | 노드 수 늘림/줄임               | 노드 스펙 키움/줄임(덜 흔함)

---

3) 수동 스케일링 vs 자동 스케일링

수동(Manual)

운영자가 직접 조정합니다.

워크로드 수평(파드 수)

kubectl scale deploy my-app --replicas=5

워크로드 수직(파드 리소스)

보통 배포(Deployment) 리소스 요청/제한을 수정합니다.

resources:
  requests:
    cpu: "250m"
    memory: "256Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"

클러스터 수평(노드 추가)

kubeadm 환경이면 새 노드를 프로비저닝하고 kubeadm join으로 합류시키는 방식이 “수동”입니다.

---

4) 자동(Autoscaling) 스케일링의 3종 세트

자동화 도구를 “대상/방향”에 매핑하면 한 번에 정리됩니다.

• 워크로드 수평: HPA (Horizontal Pod Autoscaler)
• 워크로드 수직: VPA (Vertical Pod Autoscaler)
• 클러스터 수평: Cluster Autoscaler

특히 실전에서는 다음 흐름이 자주 함께 움직입니다.

• HPA가 파드를 늘림 → 노드가 부족하면 파드가 Pending → Cluster Autoscaler가 노드를 늘림

---

5) HPA(수평 포드 오토스케일러) 자세히 보기

이제 HPA를 시험 관점에서 “필수만” 잡아봅니다.

5-1) 먼저: 워크로드를 수동으로 수평 확장하면 어떻게 되나?

운영자(관리자)가 직접 컴퓨터 앞에서 모니터링한다고 가정해봅시다.

• 이 배포(Deployment)의 파드는
  • requests.cpu = 250m
  • limits.cpu = 500m
• 즉, 파드 1개는 최대 500m까지 CPU를 사용할 수 있고(그 이상은 제한),
  운영자는 대략 “파드 1개가 감당 가능한 용량”을 500m로 본다고 합시다.

운영자는 수동으로 이렇게 합니다.

1. 파드 리소스 사용량을 모니터링

kubectl top pod

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

2. CPU가 임계값(예: 450m 근처 또는 자신이 정한 기준)에 도달하면 파드 수를 늘림

kubectl scale deploy myapp --replicas=3

문제는 명확합니다.

• 사람이 계속 지켜보고 있어야 하고
• 트래픽이 급증하면 대응이 늦을 수 있고
• 스케일 업/다운을 모두 수동으로 해야 합니다.

이걸 자동화하는 게 HPA입니다.

---

5-2) HPA는 무엇을 자동으로 하나?

HPA는 운영자가 하던 일을 그대로 자동화합니다.

• Metrics Server(또는 다른 메트릭 소스)에서 지속적으로 메트릭을 수집
• CPU / 메모리 / 사용자 정의 메트릭 등을 기준으로
• Deployment / ReplicaSet / StatefulSet 등의 replicas(파드 수) 를 자동으로 늘리거나 줄입니다.

즉,

• 사용량이 높으면 파드를 늘리고(Scale Out)
• 사용량이 낮으면 파드를 줄여 리소스를 아낍니다(Scale In)
• 단, minReplicas ~ maxReplicas 범위를 넘지 않습니다.

---

5-3) HPA 만들기: 명령형(Imperative) kubectl autoscale

예를 들어 nginx 배포 myapp에 대해:

• 최소 1개, 최대 10개
• CPU 임계값 50%

kubectl autoscale deployment myapp --min=1 --max=10 --cpu-percent=50

이 명령을 실행하면 HPA 오브젝트가 만들어지고, HPA는 다음처럼 동작합니다.

• 대상 리소스(여기서는 Deployment myapp)의 파드들 CPU 사용량을 모니터링
• CPU 사용률이 50%를 넘으면 replicas를 늘리고, 내려가면 줄임

HPA 상태 확인:

kubectl get hpa

출력에서 보통 아래를 확인합니다.

• TARGETS: 현재 CPU 사용량 / 목표치(예: 45%/50%)
• MINPODS, MAXPODS
• REPLICAS: 현재 파드 수

더 이상 필요 없으면 삭제:

kubectl delete hpa myapp

---

5-4) HPA 만들기: 선언형(Declarative) YAML

시험/실무 모두에서 “YAML로 만든다”가 더 일반적이므로 형태를 익혀두면 좋습니다.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  minReplicas: 1
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 50

적용:

kubectl apply -f myapp-hpa.yaml
kubectl get hpa

핵심 포인트:

• scaleTargetRef: “무엇을 스케일할지” (Deployment/StatefulSet 등)
• minReplicas, maxReplicas
• metrics: 무엇을 보고 스케일할지(여기서는 CPU 사용률 50%)

---

5-5) HPA의 전제조건: Metrics Server(또는 메트릭 소스)

HPA는 메트릭이 있어야 동작합니다.

• 기본적으로는 클러스터 내부 메트릭 수집을 위해 Metrics Server가 필요합니다.
• 더 나아가면:
  • 내부 커스텀 메트릭(예: Prometheus Adapter 같은 커스텀 메트릭 어댑터)
  • 외부 메트릭(예: Datadog, Dynatrace 등 외부 모니터링 시스템 + 어댑터)
    도 가능하지만, 이건 과정 범위를 벗어나는 고급 영역입니다.

시험 관점에서는 보통 여기까지만 잡아도 충분합니다.

• “HPA는 기본 제공된다(별도 설치 X)”
• “단, 메트릭을 위해 Metrics Server가 필요하다(전제조건)”

---

6) 정리: 이 글에서 가져가야 할 것

1. 쿠버네티스 스케일링은 워크로드 vs 클러스터로 나뉜다.
2. 각각 수평 vs 수직이 있다.
3. 자동화 도구 매핑은 이렇게 기억하면 된다.

• 워크로드 수평: HPA
• 워크로드 수직: VPA
• 클러스터 수평: Cluster Autoscaler

4. HPA는 운영자가 kubectl top pod로 보던 걸 자동화해 replicas를 조절한다.
5. HPA는 Metrics Server(또는 다른 메트릭 소스) 가 있어야 제대로 동작한다.

 

Practice Test Link: https://learn.kodekloud.com/user/courses/udemy-labs-certified-kubernetes-administrator-with-practice-tests/module/54a703bb-467f-40a5-90ee-c4fcf479501c/lesson/a84abc2e-7511-4685-8dcc-73e3f80045bf

Practice Test Link:https://learn.kodekloud.com/user/courses/udemy-labs-certified-kubernetes-administrator-with-practice-tests/module/54a703bb-467f-40a5-90ee-c4fcf479501c/lesson/87c707b6-eda8-443a-9cac-03116ee3966f