Horizontal Pod Autoscaler는 어떻게 동작하며, Cluster Autoscaler와 어떤 관계인가?

Question

IT Interview Practice · Accepted Answer

**Horizontal Pod Autoscaler (HPA)**는 관측된 메트릭(CPU, memory, 또는 커스텀)에 기반해 **Pod replica**를 추가하거나 제거한다. **Cluster Autoscaler (CA)**는 Pod가 스케줄링될 수 없거나 노드가 충분히 활용되지 않을 때 **노드**를 추가하거나 제거한다. 둘은 서로 다른 계층에서 작동하며 함께 작동한다.

## 두 개의 autoscaler, 두 개의 계층

```text
HPA  → PODS를 스케일 (Deployment의 replica 증감)          — LOAD에 반응
CA   → NODES를 스케일 (클러스터의 머신을 늘리고 줄임)      — PENDING Pod에 반응
VPA  → (보너스) Pod의 request/limit을 조정                 — 적정 크기 산정에 반응

전형적 흐름: 부하 상승 → HPA가 Pod 추가 → Pod가 안 들어감 → CA가 노드 추가 →
              Pod 스케줄됨. 부하 하락 → HPA가 Pod 제거 → 노드 유휴 → CA가 제거.
```

## HPA control loop가 동작하는 방식

```text
약 15초마다 HPA controller는:
  1. metrics-server / custom API에서 현재 메트릭(예: Pod 평균 CPU)을 읽음
  2. 계산:  desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)
  3. Deployment를 그쪽으로 스케일 (minReplicas/maxReplicas로 제한)
예: CPU 80%인 4개 Pod, 목표 50% → 4 * 80/50 = 6.4 → 7 replica.
Stabilization window가 flapping을 완화한다 (특히 scale-down 시).
```

## HPA manifest

```yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 3
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60      # 평균 CPU를 REQUEST의 ~60%로 유지
  behavior:                           # 선택: scale up/down 속도 조정
    scaleDown:
      stabilizationWindowSeconds: 300
```

```bash
kubectl get hpa                       # 현재/목표 메트릭, replica 수
kubectl top pods                      # metrics-server 필요
```

## 중요한 의존성 & 주의점

```text
• CPU/memory 기반 HPA는 metrics-server 설치가 필수; 사용률은 REQUEST 대비 상대값
  → request가 미설정/잘못되면 HPA 계산이 무의미하다. request를 올바르게 설정하라.
• 커스텀/외부 메트릭(RPS, queue depth)에는 adapter(Prometheus Adapter, KEDA)가 필요.
• HPA와 수동 `replicas`는 충돌한다 — HPA가 replica 수를 소유하게 하라.
• Cluster Autoscaler도 올바른 request가 필요하다: 노드 스케일링을 결정하려고 Pending
  Pod의 REQUEST를 본다. 노드 scale-up은 몇 분 걸리므로(프로비저닝), 여유를 유지하라.
```

## 왜 중요한가

Autoscaling은 Kubernetes가 용량을 수요에 자동으로 맞추게 하는 것이며, 두 계층을 이해하는 것은 비용 효율적이고 탄력적인 클러스터를 과대·과소 프로비저닝된 것과 구분하는 시니어급 지식이다. 핵심 사고 모델은 **HPA가 부하에 반응해 Pod를 스케일**하고(관측된 CPU, memory, 또는 커스텀 메트릭으로 replica 수 조정) **Cluster Autoscaler가 스케줄링 압박에 반응해 노드를 스케일**한다(Pod가 Pending이면 머신 추가, 노드가 유휴면 제거)는 것이다 — 둘은 서로 다른 계층에서 작동하며 협력한다: HPA는 자리가 있을 때만 Pod를 추가할 수 있고, CA가 그 자리를 제공한다. HPA의 control loop — `desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)` 공식, 주기적 조정, flapping을 막는 stabilization window — 를 이해하면 그것을 마법으로 취급하는 대신 구성하고 디버깅할 수 있다. 주의점에서 시니어의 판단이 드러난다: CPU/memory 기반 HPA는 **metrics-server가 필수**이고 사용률을 **request 대비** 계산하므로, 잘못되거나 없는 request는 그 계산을 무의미하게 만든다; 커스텀 메트릭(초당 요청 수, queue depth)에는 Prometheus Adapter나 KEDA 같은 adapter가 필요하다; 노드 scale-up은 몇 분 걸리므로 여유가 중요하다. 용량 적정화는 트래픽 급증 시의 신뢰성과 한산한 시기의 클라우드 지출에 직접 영향을 주고, 두 autoscaler 모두 올바르게 설정된 리소스 request에 의존하므로, HPA와 Cluster Autoscaler를 숙달하는 것은 프로덕션 Kubernetes를 효율적이고 신뢰성 있게 운영하는 데 기초가 된다.

두 개의 autoscaler, 두 개의 계층

HPA control loop가 동작하는 방식

HPA manifest

중요한 의존성 & 주의점

왜 중요한가

관련 질문