Cluster Autoscaler Helmチャートは、Kubernetes Cluster Autoscalerをインストールするための手段の一つです。Cluster Autoscalerは、Podがスケジュールできないときにワーカーノードを追加し、不要になったノードを削除します。helm installコマンド1つでインストールできますが、うまく機能するかどうかは2つの要素に大きく左右されます。設定内容と、Podのリソースリクエストです。
本ガイドでは、この両方に加えて、Cluster Autoscalerがどのようにスケーリングを判断するのかを解説します。 ノードの追加・削除の判断基準、インストールすべきチャート、EKS・AKS・GKEでのインストールと動作確認の方法、動作を制御するHelm values、大規模クラスタ向けのチューニング、そしてよくあるスケーリング問題のトラブルシューティングを学べます。
Cluster Autoscaler Helmチャートとは?
Cluster Autoscalerは、Podの必要量に応じてクラスタ内のノード数を変更します。容量不足でPodがスケジュールできない場合にノードを追加し、Podを他のノードで実行できる場合には不要になったノードを削除します。
これは、AWS Auto Scaling Group(ASG)、Azure Virtual Machine Scale Set(VMSS)、Google Compute Engine Managed Instance Group(MIG)といった、クラウドプロバイダーのノードグループのサイズを変更することで実現されます。
Helmチャートは、Cluster AutoscalerのDeployment、RBAC権限、設定を1つのインストールにパッケージ化したものです。これにより、インストール・管理・アップグレードが容易になります。 Cluster Autoscalerがノードをスケールするのに対し、HPAとKEDAはPodをスケールします。
Cluster Autoscalerはどのようにノードの追加・削除を判断するのか?
Cluster Autoscalerがノードの追加・削除のタイミングを判断する際の主な要素は次のとおりです。
Pending状態のPodがスケールアップのトリガーになる
Autoscalerは--scan-intervalの設定に基づき10秒ごとに、既存ノードに収まらずPending状態のままになっているPodを探します。各ノードグループの新しいノードでそれらのPodを実行できるかを確認し、適切なグループを選択して、クラウドプロバイダーがノードを追加できるようにdesired sizeを増やします。スケジュール不能なPodがなければ、Cluster Autoscalerはノードを追加しません。
低い使用率と待機時間がスケールダウンのトリガーになる
ノードを追加する必要がない場合、Autoscalerは削除できるノードがないかを確認します。ノード上のPodのCPUおよびメモリのリクエストが--scale-down-utilization-threshold(デフォルト0.5=50%)を下回ると、そのノードは削除候補になります。ノードは--scale-down-unneeded-time(デフォルト10分)で設定された時間、低使用率の状態を維持している必要があります。また、Autoscalerはスケールアップ後も--scale-down-delay-after-add(こちらもデフォルト10分)に基づいてノード削除を待機します。これが、スケールダウンが通常スケールアップより遅い理由です。
ノードグループとExpanderが新しいノードの供給元を決める
Autoscalerは、管理対象のノードグループを把握している必要があります。自動検出することも、明示的なリストを使うこともできます。複数のノードグループがPending状態のPodを実行できる場合は、--expanderの設定でどのグループを拡張するかが決まります。選択肢はrandom、most-pods、least-waste、price、priorityです。
リソースリクエストがスケーリング判断を左右する
ここは理解しておくべき特に重要なポイントです。Cluster Autoscalerは、実際のCPUやメモリの使用量ではなく、Podのリソースリクエストを使用します。リクエストされたリソースが収まらない場合にノードを追加し、ノード上のPodのリクエストに基づいて低使用率かどうかを判断します。たとえば、Podがノード容量の80%をリクエストしているのに実際には20%しか使っていない場合でも、Autoscalerはそのノードを80%使用中と見なし、削除しない可能性があります。そのため、過大なリクエストは余分なノードを稼働させ続け、クラウドコストを増加させることがあります。
どのCluster Autoscalerチャートをインストールすべきか?
新規インストールでは、kubernetes/autoscalerリポジトリの公式autoscaler/cluster-autoscalerチャートを使用してください。
古いstable/aws-cluster-autoscalerやstable/cluster-autoscalerチャートが見つかることもありますが、これらは非推奨でメンテナンスされていないため、使用は避けてください。
Helmだけが選択肢ではありません。マネージドKubernetesサービスでは独自のツールでCluster Autoscalerが提供される場合があり、Terraformで管理するチームもあります。最適な選択は、クラスタの管理方法によって異なります。
前提条件とバージョン互換性
インストール前に確認すべき点は次の2つです。
Cluster AutoscalerのバージョンをKubernetesのバージョンに合わせる
Kubernetes 1.30にはCluster Autoscaler v1.30.x、Kubernetes 1.31にはv1.31.xというように、バージョンを揃える必要があります。Autoscalerは独自のスケジューリングロジックでPodが新しいノードに収まるかどうかを確認するため、バージョンが一致していないと誤ったスケーリング判断につながる可能性があります。チャートのデフォルトのイメージタグを確認し、必要に応じて正しいバージョンに固定してください。
Cluster Autoscalerにクラウドプロバイダーへのアクセス権を付与する
Autoscalerには、ノードグループのサイズを変更する権限と、管理対象のノードグループを特定するための情報が必要です。AWSでは、必要なIAM権限と適切にタグ付けされたAuto Scaling Group(ASG)がこれにあたります。AzureやGCEでは、同等の権限と正しく設定されたVM Scale Set(VMSS)またはManaged Instance Group(MIG)が必要です。
インストール前に、これらの権限とノードグループの設定が正しいことを確認してください。設定が誤っていてもチャート自体は正常に起動しますが、Cluster Autoscalerはノードをスケールできません。
稼働中のクラスタへのチャートのインストール
まず、公式リポジトリを追加します。
helm repo add autoscaler https://kubernetes.github.io/autoscalerhelm repo updateインストールの前に、Cluster Autoscalerが管理すべきノードグループを指定する必要があります。設定方法はクラウドプロバイダーによって異なります。
マネージドのAKSとGKEでは、ノードの自動スケーリングがノードプール単位で有効化できる組み込み機能としてすでに提供されているため、通常このHelmチャートをインストールする必要はありません。このチャートは主にAmazon EKSやセルフマネージドクラスタで役立ちます。
EKSへのインストール
EKSでは、自動検出(auto-discovery)が最もシンプルな方法です。まず、Cluster Autoscalerに管理させたい各Auto Scaling Group(ASG)にk8s.io/cluster-autoscaler/enabledとk8s.io/cluster-autoscaler/<your-cluster-name>のタグを付けます。
次にチャートをインストールします。
helm install cluster-autoscaler autoscaler/cluster-autoscaler \ --namespace kube-system \ --set cloudProvider=aws \ --set autoDiscovery.clusterName=<your-cluster-name> \ --set awsRegion=<your-region>セルフマネージドのAzureまたはGCEへのインストール
セルフマネージドのAzureまたはGCEクラスタでは、cloudProvider=azureまたはcloudProvider=gceを設定し、Cluster Autoscalerに管理させたいスケールセットまたはインスタンスグループの詳細を指定します。
具体的な設定はクラウドプロバイダーによって異なりますが、基本的なセットアップは同じです。クラウドプロバイダー、ノードグループ、そしてCluster Autoscalerが使用する認証情報またはアイデンティティを指定します。
インストール後、Cluster AutoscalerのPodが稼働していることを確認します。
kubectl get pods -n kube-system -l app.kubernetes.io/instance=cluster-autoscaler続いてステータスを確認します。
kubectl describe configmap cluster-autoscaler-status -n kube-systemステータスConfigMapには、各ノードグループのサイズと直近のスケールアップ・スケールダウンのアクティビティが表示されます。これにより、Cluster Autoscalerが稼働し、スケーリング判断を行っているかどうかをすばやく把握できます。
Autoscalerの動作を変えるHelm values
重要な設定値は次のとおりです。
cloudProvider と autoDiscovery
これらは、使用しているクラウドプロバイダーと、管理対象のノードグループの検出方法をCluster Autoscalerに伝えます。これらが間違っていると、Autoscalerにはスケールすべきノードグループが存在しないことになります。
クラウドアクセス用のサービスアカウントのアノテーション
すべてのノードに広範な権限を与える代わりに、サービスアカウント経由でCluster Autoscaler自身にクラウド権限を付与できます。EKSではIAM Roles for Service Accounts(IRSA)を使うのが一般的です。AzureやGCEではWorkload Identityを利用できます。サービスアカウントのアノテーションはrbac.serviceAccount.annotationsで設定します。
スケーリング動作を制御する extraArgs
extraArgsでは、scan-interval、scale-down-utilization-threshold、scale-down-unneeded-time、expanderなどのCluster Autoscalerのオプションを設定します。また、expendable-pods-priority-cutoffを使って、どの優先度未満のPodを「犠牲にしてもよい(expendable)」として扱うかも設定できます。これらの設定は、Autoscalerがクラスタを確認する頻度と、追加・削除するノードの選び方を制御します。
レプリカ数、リーダー選出、リソース
高可用性のために、複数のレプリカを実行できます。Cluster Autoscalerはリーダー選出を使用するため、アクティブなレプリカは常に1つで、残りは引き継ぎに備えて待機します。また、Autoscaler自体のCPUとメモリのリクエストとリミットも設定してください。Autoscalerはクラスタの状態をメモリに保持するため、大規模クラスタではより多くのメモリが必要になる場合があります。
これらの値はvalues.yamlファイルに記述し、-fを付けてチャートをインストールできます。
cloudProvider: awsautoDiscovery: clusterName: my-clusterawsRegion: us-east-1replicaCount: 2extraArgs: scan-interval: 10s scale-down-utilization-threshold: "0.5" expander: least-waste balance-similar-node-groups: "true"resources: requests: cpu: 100m memory: 300Mi limits: cpu: 200m memory: 500Mi大規模またはマルチテナントクラスタ向けのチューニング
大規模クラスタでは、スキャンごとに確認すべきPod、ノード、ノードグループが多くなるため、追加のチューニングが必要です。クラスタの成長に合わせて健全性を保つのに役立つ設定とパターンをいくつか紹介します。
ノードグループの数を減らす
Autoscalerが管理するノードグループが多いほど、スキャンごとの処理量が増えます。可能な限りノードグループの数を抑え、自動検出タグを使って自動スケーリングが必要なグループのみを対象にしてください。
超大規模クラスタではシャーディングを使う
複数のCluster Autoscalerインスタンスを実行し、それぞれに異なるノードグループ群を管理させることができます。これにより処理が複数のAutoscalerインスタンスに分散されます。トレードオフとして、これらのインスタンスは互いに連携しないため、2つのインスタンスが同じPending状態のPodに反応し、一時的に必要以上のノードが追加されることがあります。余分なノードは、その後のスケールダウンで削除されます。
Priority Expanderと組み合わせてSpotノードを使う
コスト重視のクラスタでは、SpotノードグループとPriority Expanderを組み合わせられます。これにより、Autoscalerが低コストのSpotキャパシティを優先し、必要に応じてオンデマンドノードにフォールバックできます。
オーバープロビジョニングでスケーリングを高速化する
オーバープロビジョニングでは、低優先度のプレースホルダーPodを使ってクラスタに余剰キャパシティを確保します。実際のワークロードが到着すると、これらのプレースホルダーPodが退避してスペースを空け、その間にAutoscalerが新しいノードを追加します。
ノードグループをゼロまでスケールさせる
使用されていないノードグループは、ゼロまでスケールダウンできます。これは特に高価なGPUノードグループで有効です。EKSでは、ノード数がゼロのときでもそのグループのノードが何を提供できるかをCluster Autoscalerが把握できるよう、ノードグループのAutoscalerタグに必要なラベルとtaintが設定されていることを確認してください。
スケールしない場合の診断
Cluster Autoscalerが期待どおりにスケールしない場合、まず確認すべきはステータスConfigMapとPodのログです。よくあるケースは次のとおりです。
PodがPendingのままでノードが追加されない
まずkubectl describe pod <pod-name>でPodのイベントを確認します。次にCluster Autoscalerのログを確認します。よくある原因は、ノードグループがすでに最大サイズに達している、Podのリソースリクエストを満たせるノードグループが存在しない、Podのノードセレクタやアフィニティが利用可能なノードグループに一致しない、などです。クラウド権限やノードグループのタグが不足していると、Autoscalerがノードグループを検出・変更できないこともあります。
ノードが低使用率のまま削除されない
Cluster Autoscalerはデフォルトで一部のノードをスキップします。たとえば、--skip-nodes-with-system-podsが有効な場合はkube-systemのPodが動作するノードを、--skip-nodes-with-local-storageが有効な場合はローカルストレージを使用するPodがあるノードをスキップします。また、スケールダウンの待機時間中も待機します。さらに重要なのは、Cluster Autoscalerが実際の使用量ではなくリソースリクエストを使う点です。リクエストによってノードが使用率のしきい値を上回っている場合、実際のCPUやメモリの使用量が低くても、そのノードは削除候補になりません。
アノテーションとPodDisruptionBudgetがノード削除をブロックする
Cluster Autoscalerは、PodDisruptionBudget(PDB)に違反する場合はノードを削除しません。また、cluster-autoscaler.kubernetes.io/safe-to-evict: "false"が付いたPodや、scale-down-disabledアノテーションが付いたノードもスキップします。これらの設定はワークロードを意図しない退避から保護しますが、古い設定や不要な設定が残っていると、ノードが想定より長く稼働し続けることがあります。kubectl describe configmap cluster-autoscaler-status -n kube-systemを実行して、どのノードが削除できないのか、その理由は何かを確認してください。
Cluster Autoscalerと併用できるツール
Cluster Autoscalerはノード数を管理しますが、以下のツールはPodのサイジングやノードのプロビジョニングに役立ちます。
PerfectScale
Cluster Autoscalerは、実際のCPUやメモリの使用量ではなく、Podのリソースリクエストに基づいてスケーリングを判断します。リクエストが大きすぎると、不要なノードが追加されたり、本来削除できるノードが残り続けたりします。PerfectScaleはワークロードの実際の使用量を監視し、自動化されたライトサイジングの推奨を提供することで、CPUとメモリのリクエストを実使用量に近づけるのに役立ちます。これにより、Cluster Autoscalerはより適切なスケーリング判断ができるようになります。無料で試すことも、技術セッションを予約することもできます。
Vertical Pod Autoscaler(VPA)とGoldilocks
VPAは、観測された使用量に基づいてPodのリソースリクエストを調整します。Goldilocksは、VPAの推奨値を確認できるダッシュボードを提供します。どちらもリソースリクエストを実使用量に近づけるのに役立ち、Cluster Autoscalerのスケーリング判断に、より正確な情報を与えられます。
Karpenter
Karpenterは、ノードスケーリングに対して異なるアプローチを取ります。固定されたノードグループのサイズを変更する代わりに、Pending状態のPodの要件に基づいてノードをプロビジョニングできます。
本番環境でCluster Autoscalerを運用するためのベストプラクティス
ノードの自動スケーリングを効率的かつ安全に保つためのプラクティスは次のとおりです。
1. Autoscalerの設定を調整する前にPodリクエストをライトサイジングする
Cluster AutoscalerはPodのリソースリクエストに基づいて判断するため、Autoscalerの設定変更よりも正確なリクエストのほうが重要です。まずリソースリクエストを修正し、その後にタイマーやExpanderを調整してください。
2. ノードグループ内のCPU、メモリ、アベイラビリティゾーンを揃える
同一ノードグループ内のノードは、互いに類似していることが前提です。インスタンスタイプやアベイラビリティゾーンが異なると、Autoscalerのスケジューリングシミュレーションの精度が下がる可能性があります。類似したノードグループはbalance-similar-node-groupsでバランスを取れます。
3. 中断させたくないワークロードにはPodDisruptionBudgetを設定する
PodDisruptionBudget(PDB)は、同時に利用不可にできるPodの数を定義します。これにより、Cluster Autoscalerはワークロードに十分なレプリカを確保しながらノードを削除できます。
4. チャートのバージョンを固定し、アップグレードをテストする
Cluster AutoscalerのバージョンはKubernetesのバージョンと一致させる必要があります。そのため、Kubernetesのアップグレードは、変更を本番環境に反映する前に、対応するバージョンのAutoscalerでテストすべきです。
5. AutoscalerのメトリクスをPrometheusにエクスポートし、スケールアップ失敗にアラートを設定する
Cluster Autoscalerは、スケーリングのアクティビティと失敗を示すPrometheusメトリクスを公開しています。スケールアップの失敗やPendingのままのPodに対するアラートを設定すれば、ワークロードへの影響が長引く前に問題を発見できます。
6. スケールダウンのしきい値を実際のコスト削減効果と照らして見直す
積極的なスケールダウンはコストを下げられますが、急なトラフィックスパイクがあるワークロードでは、スケールアップとスケールダウンが頻発する可能性があります。scale-down-utilization-thresholdとスケールダウンのタイマーは、ノード数の削減だけを目的にするのではなく、実際のトラフィックパターンに合わせて調整できます。