Horizontal Pod Autoscaler はどう動き、Cluster Autoscaler とどう関係しますか？

Question

IT Interview Practice · Accepted Answer

**Horizontal Pod Autoscaler（HPA）**は、観測されたメトリクス（CPU、メモリ、またはカスタム）に基づいて **Pod の replica** を増減します。**Cluster Autoscaler（CA）**は、Pod がスケジュールできないときやノードが使われていないときに **ノード**を増減します。両者は異なる層で動作し、協調します。

## 2 つの autoscaler、2 つの層

```text
HPA  → scales PODS  (more/fewer replicas of a Deployment)     — reacts to LOAD
CA   → scales NODES (grows/shrinks the cluster's machines)     — reacts to PENDING Pods
VPA  → (bonus) adjusts a Pod's requests/limits                 — reacts to right-sizing

Typical flow: load rises → HPA adds Pods → Pods can't fit → CA adds a node →
              Pods schedule. Load drops → HPA removes Pods → node idle → CA removes it.
```

## HPA の control loop はどう動くか

```text
Every ~15s the HPA controller:
  1. reads current metric (e.g. avg CPU across Pods) from metrics-server / custom API
  2. computes:  desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)
  3. scales the Deployment toward that (bounded by minReplicas/maxReplicas)
Example: 4 Pods at 80% CPU, target 50% → 4 * 80/50 = 6.4 → 7 replicas.
Stabilization windows dampen flapping (esp. on 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
• HPA on CPU/memory REQUIRES metrics-server installed; utilization is relative to REQUESTS
  → if requests are unset/wrong, HPA math is meaningless. Set requests correctly.
• Custom/external metrics (RPS, queue depth) need an adapter (Prometheus Adapter, KEDA).
• HPA and manual `replicas` conflict — let the HPA own the replica count.
• Cluster Autoscaler needs correct requests too: it looks at Pending Pods' REQUESTS to
  decide node scaling. Node scale-up takes minutes (provisioning), so keep headroom.
```

## なぜ重要なのか

autoscaling は Kubernetes が容量を需要に自動で合わせる手段であり、2 つの層を理解することは、コスト効率が良く回復力のある cluster を、過剰または過少にプロビジョニングされた cluster から分ける senior レベルの知識です。鍵となる思考モデルは、**HPA が Pod をスケールする**（観測された CPU・メモリ・カスタムメトリクスから replica 数を調整して負荷に反応する）一方、**Cluster Autoscaler がノードをスケールする**（Pod が Pending のときにマシンを追加し、ノードが遊休のとき取り除いてスケジューリング圧に反応する）ことです — 両者は異なる層で動作し協調します。HPA は空きがあるときにしか Pod を追加できず、CA がその空きを提供します。HPA の control loop — `desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)` の式、周期的な reconciliation、フラッピングを防ぐ stabilization window — を理解すれば、それを魔法として扱うのではなく設定しデバッグできます。注意点は senior の判断が表れる所です。CPU/メモリの HPA は **metrics-server が必要**で、utilization を **requests に対して相対的に**計算するため、requests が誤っていたり欠けていたりすると計算が無意味になります。カスタムメトリクス（秒あたりリクエスト数、キューの深さ）には Prometheus Adapter や KEDA のようなアダプタが必要で、ノードの scale-up には数分かかるため headroom が重要です。容量の適正化はトラフィックのスパイク下での信頼性と、閑散期のクラウド費用に直接影響し、両方の autoscaler が正しく設定された resource requests に依存するため、HPA と Cluster Autoscaler の習熟は、production の Kubernetes を効率的かつ信頼性高く運用するための基礎です。

2 つの autoscaler、2 つの層

HPA の control loop はどう動くか

HPA の manifest

重要な依存関係と注意点

なぜ重要なのか

関連する質問