KubernetesのCluster Autoscalerの設定｜仕組み・EKS/GKE/AKSでの有効化・ノードが増えない／減らないときの調べ方

Cluster Autoscalerは、Podが資源不足で置けない（Pending）ときにノードを増やし、空いたノードを減らすコンポーネントです。判断の基準は実際のCPU使用率ではなく、各Podの resources.requests です。ここを取り違えると「負荷は高いのにノードが増えない」「ほとんど使っていないのに減らない」という状態になります。この記事では、仕組み、HPAとの役割分担、主要なクラウドでの有効化、よく使う設定、ノードが増えない・減らないときの調べ方を説明します。

マネージドサービスの機能や画面、既定値は更新が多いため、内容は執筆時点（2026年10月現在）のものとして、各サービスの公式ドキュメントと合わせて確認してください。

仕組み：何を見て増やし、何を見て減らすか

増やす（スケールアウト）

Cluster Autoscalerは、スケジューラが「どのノードにも置けない」と判断したPodを定期的に探します。見つかると、各ノードグループ（ノードプール）にノードを1台足したと仮定してシミュレーションし、そのPodが置けるようになるグループのノードを増やします。

ここで大事なのは、次の場合は増やさないことです。

• Podが資源不足以外の理由でPendingになっている（taintを許容していない、nodeSelectorに合うグループが無い、PVCのゾーンが合わないなど）
• ノードを足しても置けない（Podのrequestsが、1台のノードの容量より大きいなど）
• ノードグループがすでに上限（最大ノード数）に達している

減らす（スケールイン）

requestsの合計がノードの容量に対して低い状態（既定では50%未満）が一定時間（既定では10分程度）続き、そのノードのPodを他のノードに移せると判断できたときに、ノードを空けて削除します。次のようなPodがあるノードは、既定では削除されません。

• PodDisruptionBudget（PDB）に違反する移動が必要なPod
• Deploymentなどのコントローラに管理されていない単体のPod
• kube-system のPodでPDBが無いもの
• ローカルストレージを使うPod（設定によって扱いが変わります）
• アノテーション cluster-autoscaler.kubernetes.io/safe-to-evict: "false" が付いたPod

減らない原因の多くは、この一覧のどれかに当てはまるPodが各ノードに散らばっていることです。

HPAとの役割分担

HorizontalPodAutoscaler（HPA）はPodの数を増減させ、Cluster Autoscalerはノードの数を増減させます。典型的な流れは次のとおりです。

1. アクセスが増え、HPAがPodを増やす
2. 既存ノードに入りきらないPodがPendingになる
3. Cluster Autoscalerがノードを増やし、Podが置かれる

この連携は、Podにrequestsが正しく設定されていることが前提です。requestsが無いPodは、スケジューラから見ると資源を使わないため、ノードに詰め込まれてもPendingにならず、ノードは増えません。結果として、ノードが過負荷のまま動き続けます。

なお、新しいノードの起動には通常数分かかります。急なアクセス増に追いつかない場合は、優先度の低いダミーのPodで余白を確保しておき、本番のPodが来たら押し出させる方法（オーバープロビジョニング）が知られています。

主要なクラウドでの有効化

GKE

GKEでは、Cluster Autoscalerがマネージドで組み込まれており、ノードプールごとに有効化します。

gcloud container clusters update <クラスタ名> \
  --node-pool=<ノードプール名> \
  --enable-autoscaling --min-nodes=1 --max-nodes=5 \
  --location=<リージョンまたはゾーン>

AKS

AKSも組み込みの機能で、クラスタまたはノードプール単位で有効化します。

az aks update --resource-group <リソースグループ> --name <クラスタ名> \
  --enable-cluster-autoscaler --min-count 1 --max-count 5

EKS

EKSでは、Cluster Autoscalerを自分でクラスタにデプロイする方法のほか、Karpenterや、AWSがノード管理を受け持つ EKS Auto Mode を使う方法があります。どれを選ぶかでノードの管理方法が大きく変わるため、新しく構築するならAWSの公式ドキュメントで現在の推奨を確認してから決めてください。

Cluster Autoscalerを使う場合は、公式のHelmチャートで導入し、Auto Scaling グループのタグで対象を自動検出させるのが一般的です。

helm repo add autoscaler https://kubernetes.github.io/autoscaler
helm repo update

helm install cluster-autoscaler autoscaler/cluster-autoscaler \
  --namespace kube-system \
  --set autoDiscovery.clusterName=<クラスタ名> \
  --set awsRegion=<リージョン>

自動検出には、対象の Auto Scaling グループに k8s.io/cluster-autoscaler/enabled と k8s.io/cluster-autoscaler/<クラスタ名> のタグが必要です。Auto Scaling グループを操作するためのIAM権限も、IRSA（IAM Roles for Service Accounts）やEKS Pod Identityを使ってCluster AutoscalerのServiceAccountに与えます。必要な権限の一覧は版によって変わるため、チャートのドキュメントにあるものを使います。

自分でデプロイする場合、Cluster Autoscalerのイメージの版はKubernetesのマイナーバージョンに合わせます。クラスタをアップグレードしたら、Cluster Autoscalerも合わせて更新します。

よく調整する設定

自分でデプロイする場合、起動オプションで挙動を変えられます。代表的なものは次のとおりです。既定値は版によって変わることがあるため、使う版のFAQで確認してください。

• --scale-down-utilization-threshold：これを下回る使用率（requestsベース）のノードを削除候補にします。
• --scale-down-unneeded-time：候補になってから実際に削除するまでの待ち時間です。
• --scale-down-delay-after-add：ノードを増やした直後、スケールインを控える時間です。
• --expander：複数のノードグループが候補になったとき、どれを増やすかの選び方です。least-waste（余りが少ない）、priority（優先度の指定）などがあります。
• --balance-similar-node-groups：同じ構成のノードグループ（ゾーン違いなど）の台数をそろえます。

ノードグループの最小・最大台数は、費用の上限と可用性の下限を決める値でもあります。最大を大きくしすぎると、設定ミスで大量のPodが作られたときにノードも大量に増えます。

ノードが増えない・減らないときの調べ方

まずPendingのPodのイベントを見る

kubectl get pods -A --field-selector=status.phase=Pending
kubectl describe pod <pod名> -n <namespace>

Events に Cluster Autoscaler からのメッセージが出ます。TriggeredScaleUp なら増やす判断はされています。NotTriggerScaleUp なら、どのノードグループでも置けないと判断されており、理由が併記されます。taintやnodeSelector、requestsの大きさを確認します。

Cluster Autoscalerの状態とログを見る

# 自分でデプロイした場合の状態（ConfigMapに書き出される）
kubectl -n kube-system get configmap cluster-autoscaler-status -o yaml

# Deployment名を確かめてからログを見る
kubectl -n kube-system get deployments | grep -i autoscaler
kubectl -n kube-system logs deployment/<上で確認したDeployment名> --tail=200

Deployment名は導入方法（Helmのリリース名やチャートの命名規則）で変わるため、先に一覧で確認します。ConfigMapの名前も起動オプションで変えられます。GKEやAKSのマネージド版は、ログをクラウドのログサービスで確認します。

増やす判断はされたのにノードが来ない

クラウド側でノードの作成に失敗しています。インスタンスの割り当て上限（クォータ）、指定したインスタンスタイプの在庫不足、サブネットのIPアドレス不足がよくある原因です。クラウドのコンソールで、ノードグループのアクティビティ履歴を確認します。

減らない

削除候補のノードにどんなPodがあるかを見ます。

kubectl get pods -A -o wide --field-selector=spec.nodeName=<ノード名>

前述の「削除されないPod」が含まれていないか、PDBの minAvailable が厳しすぎて1つも移せない状態になっていないかを確認します。移動して問題の無いPodなら、cluster-autoscaler.kubernetes.io/safe-to-evict: "true" を付けると候補になります。付ける前に、そのPodが本当に作り直しに耐えるか（ローカルのデータを失わないか）を確かめてください。

設定を変えるときは、現在の値を記録しておき、検証用のクラスタで増減の挙動を確かめてから本番に反映します。

まとめ

• Cluster Autoscalerは、requestsが原因でPendingになったPodを見てノードを増やし、requestsの合計が低いノードを減らします。実際のCPU使用率では判断しません。
• HPAがPodを、Cluster Autoscalerがノードを増やします。両方ともrequestsの設定が前提です。
• GKE・AKSは組み込みの機能をノードプール単位で有効化し、EKSは自分でデプロイするほかKarpenterやEKS Auto Modeも選べます。
• 増えないときは Pending のPodのイベント（TriggeredScaleUp / NotTriggerScaleUp）、減らないときはノード上のPodとPDBを確認します。

• Kubernetesのリソース制限（requests/limits）を設定する方法
• Kubernetesのコスト最適化の方法