【AKS実践】HPAとCluster Autoscalerで自動スケールを理解する

Azure

AKSでアプリを動かしていると、いつか必ずぶつかるのが「アクセスが増えたときどうするの？」という問題です。キャンペーンで急にアクセスが3倍になったとき、手動でPodを増やして…なんてやっていられません。

そこで登場するのがオートスケール（自動スケール）です。AKSには「負荷に応じて自動で増減させる」仕組みが用意されていて、これを理解すると運用がぐっと楽になります。

この記事では、AKSの自動スケールを支える2つの仕組み——HPA（Podを増やす）とCluster Autoscaler（ノードを増やす）——を、手を動かしながら理解していきます。

まだAKSの基本があやふやな方は、先に 【図解】AKSとは？ を読んでおくとスムーズです。

まず結論：スケールには「2階建て」がある

AKSの自動スケールでいちばん大事なのは、スケールには2つの階層があると理解することです。ここを混同すると必ず迷子になります。

  • HPA（Horizontal Pod Autoscaler）：Pod（アプリの実体）の数を増減させる。「1階」の話。
  • Cluster Autoscaler：ノード（Podを載せるVM）の数を増減させる。「2階」の話。

レストランで例えると分かりやすいです。

  • Pod＝店員さん。忙しくなったら店員を増やす（＝HPA）。
  • ノード＝店舗の広さ。店員を増やしたくても席や厨房が足りなければ、店舗そのものを広げる（＝Cluster Autoscaler）。

つまり、まずHPAがPodを増やそうとし、載せる場所（ノード）が足りなくなったらCluster Autoscalerがノードを増やす。この2つは連携して働きます。順番に見ていきましょう。

HPA：Podを自動で増やす

HPAの仕組み

HPAは、「CPU使用率が○%を超えたらPodを増やす」というルールを決めておくと、あとは自動でPod数を調整してくれる仕組みです。

たとえば「CPU使用率の目標を50%」に設定すると、負荷が上がって平均CPUが50%を超えたらPodを増やし、下がったら減らします。常に50%あたりで安定するように、Kubernetesが自動で台数を調整してくれるイメージです。

前提：resources.requests が必須

ここが初心者の最大のつまずきポイントです。HPAは「CPU使用率」で判断しますが、その”率”を計算するには、そもそも1PodあたりのCPU基準値（requests）が必要です。

基準がなければ「率」は出せません。なので、DeploymentのマニフェストにCPUの requests を書いておく必要があります。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: acrdemo0303.azurecr.io/myapp:v1
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 100m
          limits:
            cpu: 200m

cpu: 100m の m は「ミリコア」で、1000m = 1コアです。100m は「0.1コア分を基準にする」という意味になります。requests が書かれていないと、HPAは <unknown> と表示されて機能しないので注意しましょう。

HPAを作成する

いちばん簡単なのは kubectl autoscale コマンドです。

kubectl autoscale deployment myapp \
  --cpu-percent=50 \
  --min=1 \
  --max=10
  • --cpu-percent=50：CPU使用率の目標50%。これを超えたら増やす。
  • --min=1：最小Pod数。暇でもこれ以下には減らさない。
  • --max=10：最大Pod数。どれだけ混んでもこれ以上は増やさない（暴走・課金の歯止め）。

状態を確認します。

kubectl get hpa

TARGETS の欄に 10%/50% のように「現在の使用率 / 目標」が表示されます。ここが <unknown>/50% になっていたら、さきほどの requests の書き忘れが原因です。

YAMLで管理したい場合

コマンドで作れますが、実務ではGit管理のためYAMLで書くのが基本です。同じ内容をマニフェストにするとこうなります。

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

コマンド版とやっていることは同じですが、こちらはファイルとして残るのでレビューやGitOpsに向いています。

Cluster Autoscaler：ノードを自動で増やす

なぜノードのスケールも必要なのか

HPAでPodを増やそうとしても、載せるノード（VM）に空きがなければPodは起動できません。この状態のPodは Pending（保留中）のまま止まってしまいます。

そこで「Podが載りきらなくなったら、ノードそのものを自動で増やす」のがCluster Autoscalerです。逆に、Podが減ってノードがガラガラになれば、余ったノードを減らしてコストも自動で節約してくれます。

Cluster Autoscalerを有効化する

これはノードプールに対する設定なので、az aks コマンドで有効にします。既存のクラスターなら az aks update です。

az aks update \
  --resource-group rg-aks-demo \
  --name aks-demo \
  --enable-cluster-autoscaler \
  --min-count 1 \
  --max-count 5
  • --min-count 1：ノードの最小数。
  • --max-count 5：ノードの最大数。ここが課金の上限になるので、予算に合わせて設定します。

クラスター新規作成時なら、az aks create に同じ --enable-cluster-autoscaler --min-count --max-count を付けるだけでOKです。

2つが連携する流れ

ここまでの内容を、実際に負荷がかかったときの流れとして並べると、こうなります。

  1. アクセス増加でPodのCPU使用率が上がる。
  2. HPAが反応してPodを増やそうとする（例：2個→8個）。
  3. ノードに空きがなく、増えたPodの一部が Pending になる。
  4. Cluster Autoscalerがそれを検知してノードを増やす（例：2台→4台）。
  5. 新しいノードに Pending だったPodが載って、無事に起動する。
  6. アクセスが落ち着くと、逆の順番でPod→ノードの順に減っていく。

HPAが「店員」を、Cluster Autoscalerが「店舗」を調整する——この役割分担さえ押さえておけば、AKSのスケールで迷うことはなくなります。

動作を試すときのコツ

実際にHPAが動くか試したいときは、負荷をかけてPodのCPUを上げてみます。負荷生成用のPodを立てて、対象アプリにアクセスし続ける方法が定番です。

kubectl run -it load-generator --rm --image=busybox:1.28 --restart=Never \
  -- /bin/sh -c "while true; do wget -q -O- http://myapp; done"

別のターミナルで kubectl get hpa や kubectl get pods を繰り返し実行すると、CPU使用率が上がってPodが増えていく様子が観察できます。Ctrl+C で負荷を止めれば、数分後にPodが減っていくのも確認できます。

なお、Podが減るときは急に減らすと不安定になるため、Kubernetesは少し時間を置いてから慎重に減らす挙動になっています。「止めたのにすぐ減らない」のは正常な動作なので、慌てず待ちましょう。

まとめ

この記事では、AKSの自動スケールを2つの階層で整理しました。

  • HPA：Pod（店員）を増減させる。CPU使用率で判断するので、resources.requests の設定が必須。
  • Cluster Autoscaler：ノード（店舗）を増減させる。az aks update --enable-cluster-autoscaler で有効化。
  • 2つは連携し、Podが載りきらなくなったらノードが増えるという流れで動く。
  • --max 系の上限設定が課金の歯止めになる。必ず設定する。

これで「負荷に強いAKS」が作れるようになりました。次回は、アプリを止めずに新バージョンへ入れ替えるローリングアップデートとロールバックを見ていきます。

あわせて読みたい：

タイトルとURLをコピーしました