Cluster Autoscaler

2025年11月6日

Cluster Autoscaler

英語表記: Cluster Autoscaler

概要

Cluster Autoscaler（クラスターオートスケーラー、CA）は、Kubernetesクラスターにおけるノード（物理または仮想マシン）の数を、ワークロードの需要に応じて自動的に調整する機能です。この機能は、オーケストレーション環境のスケーリング戦略において、リソースの効率的な利用と可用性の確保を実現するために非常に重要な役割を果たします。具体的には、処理待ちのPodがある場合にノードを追加し、ノードが不要になった場合には削除することで、コスト最適化とパフォーマンス維持を両立させます。

詳細解説

Cluster Autoscalerは、Kubernetesの核となるスケーリング機能を担うコンポーネントであり、手動でのインフラ管理の手間を劇的に削減してくれます。この機能は、私たちが目指す真のクラウドネイティブなオーケストレーションを実現するために欠かせない存在だと言えるでしょう。

目的と位置づけ

Kubernetes環境では、アプリケーションをコンテナ化し、Podとしてデプロイします。しかし、Podがどれだけ増えても、それらを動かす土台となるノード（計算リソース）が不足していれば、アプリケーションは正常に動作しません。CAの主な目的は、このノードリソースの不足を自動で解消することにあります。

これは、Podの数を調整するHorizontal Pod Autoscaler (HPA)とは役割が異なります。HPAが「アプリケーションの負荷に応じてPodの数を調整する（水平スケーリング）」のに対し、CAは「Podの需要に応じてクラスター自体のサイズを調整する」のです。この二つが連携することで、Kubernetesはアプリケーション層とインフラ層の両方で、完全な自動スケーリングを実現します。

スケーリングの仕組み（アップとダウン）

CAの動作は、主に「スケールアップ」と「スケールダウン」の2つのパターンに分けられます。

1. スケールアップ（ノードの追加）

CAがノードの追加を決定する最も重要なトリガーは、「Pending（保留中）」状態のPodが存在することです。

Podの保留: 新しいPodがデプロイされた際、Kubernetesのスケジューラーが、既存のどのノードにもリソース（CPUやメモリ）が不足しているためにPodを配置できないと判断します。このPodは「Pending」状態となります。
CAによる検知: Cluster AutoscalerはこのPending状態のPodを監視します。
ノードの要求: CAは、Pending Podを収容するために必要なリソースを持つノードの数を計算し、基盤となっているクラウドプロバイダー（AWS, GCP, Azureなど）の自動スケーリング機能に対して、新しいノードのプロビジョニングを要求します。
クラスターへの参加: 新しいノードが起動し、Kubernetesクラスターに参加すると、PendingだったPodがそのノードに配置され、実行が開始されます。

2. スケールダウン（ノードの削除）

コスト効率を維持するため、CAはリソースが過剰になっているノードを自動で削除します。

ノードの監視: CAは、一定期間（通常10分以上）にわたってノードの利用率が低い状態（例えば、CPU利用率が50%未満など、設定可能）にあるかどうかを継続的に監視します。
Podの移動可能性の確認: そのノード上で稼働しているPodを、他の既存のノードに安全に移動させることが可能かどうかを確認します。システムPodや移動が禁止されているPod（PDBなどで定義）がある場合は、スケールダウンは行いません。
ノードの解放: 移動可能と判断された場合、CAはまず対象ノードを安全にドレイン（排水）し、Podを他のノードに退避させます。
ノードの削除: 最後に、クラウドプロバイダーを通じてそのノードをクラスターから削除します。これにより、インフラコストの削減が実現します。

このように、Cluster Autoscalerは、オーケストレーション環境の「スケーリング」における経済性と弾力性を担保する、非常に賢いマネージャーだと言えますね。

具体例・活用シーン

Cluster Autoscalerの具体的な働きを理解するために、身近な例で考えてみましょう。

活用シーン：ECサイトの負荷変動対応

あるECサイトがKubernetes上で稼働しているとします。普段はアクセスが落ち着いているため、ノードは3台で十分です。

平時: ノード3台で余裕をもって稼働。CAはノードが過剰利用されていないか監視しています。
セール開始時: テレビCMが流れ、アクセスが急増。HPAが働き、Podの数が急激に増えますが、ノード3台では新しいPodを配置するリソースが足りなくなります。
CAの介入: 新しいPodが「Pending」状態になったことをCAが検知し、即座にノードを5台に増やすよう指示します。これにより、増えたPodがすぐに稼働し始め、ユーザー体験を損なうことなく大量のトラフィックをさばくことができます。
セール終了後: アクセスが落ち着き、ノード5台のうち2台の利用率が著しく低下します。CAは10分間その状態が続くのを確認した後、安全にPodを移動させ、ノード2台を削除します。結果的に、ノード3台体制に戻り、不要なインフラコストの支払いを回避できます。

アナロジー：物流倉庫のトラック管理

Cluster Autoscalerの役割は、物流倉庫における「トラックの自動増減管理」に例えることができます。

Pod: 配送を待つ荷物（タスク）。
ノード: 荷物を積んで配送するトラック（計算リソース）。
Kubernetesスケジューラー: 荷物をトラックに割り当てる係。

普段、倉庫には必要な数（例えば10台）のトラックが待機しています。しかし、年末の贈答シーズンなどで荷物が急増し、待機しているトラック10台すべてに荷物が積み込まれても、まだ大量の荷物が倉庫の隅で「配送待ち（Pending）」の状態になってしまいました。

このとき、Cluster Autoscalerは倉庫の管理者として機能します。管理者は配送待ちの荷物を見て、「これでは間に合わない！」と判断し、自動でリース会社に連絡してトラックを5台追加手配します。これがスケールアップです。

逆に、繁忙期が終わり、トラックが半日以上も荷物を積まずに駐車場で待機している状態が続けば、管理者は「このトラックは不要だ」と判断し、リース会社に返却します。これがスケールダウンです。

CAは、常に「荷物の量（Podの需要）」と「トラックの数（ノードのリソース）」のバランスを取り、待機時間を最小限に抑えつつ、無駄なレンタル費用を発生させないように努めているのです。オーケストレーションの文脈において、この自動化されたリソース管理は非常に強力なメリットとなります。

資格試験向けチェックポイント

ITパスポート試験や基本情報技術者試験では、Kubernetesそのものの詳細が出題されることは稀ですが、応用情報技術者試験やより専門的な試験では、オーケストレーションにおけるスケーリングの仕組みが問われます。Cluster Autoscalerは、特に「スケーリング」の実現方法として重要です。

HPAとの違いを明確に: Cluster Autoscaler (CA) は「ノード（インフラ）」の数を調整します。Horizontal Pod Autoscaler (HPA) は「Pod（アプリケーション）」の数を調整します。両者は異なるレイヤーで動作しますが、協調して動作することで真の弾力性を実現します。この区別は頻出です。
スケールアップのトリガー: CAがノードを追加する決定的な理由は、既存のノードに配置できない「Pending Pod」が存在することです。
スケールダウンの条件: ノードの利用率が低いこと、かつ、そのノード上のPodが他のノードに安全に移動できることが条件となります。
連携対象: CAは、Kubernetesのスケジューラーの状態を監視するだけでなく、ノードのプロビジョニングのために必ずクラウドプロバイダーのAPI（Auto Scaling Groupなど）と連携します。
文脈の理解: CAは、オーケストレーション（Kubernetes）における「スケーリング」というカテゴリの中で、コスト効率と高可用性を両立させるための主要な機能であると理解しておきましょう。