クラスタオートスケーラとビンパッキング

なぜ「使用量」ではなく「リクエスト」で増減するのか

クラスタオートスケーラ（Cluster Autoscaler、以下 CA）は、Kubernetes のノード台数を需要に合わせて増減させるコンポーネントです。ここで最初に押さえるべき原理は、CA がノード追加の判断に使うのは CPU/メモリの実使用量ではなく、ポッドの「リソースリクエスト」だという点です。これは Horizontal Pod Autoscaler（HPA）がポッド数を実メトリクスで増やすのとは別の層であり、両者はしばしば連携します（/devops/autoscaling-control-theory/）。

なぜリクエストなのか。Kubernetes のスケジューラがポッドをノードへ配置できるかを判定する材料が、まさに各コンテナの requests だからです。スケジューラはノードの 割り当て可能量（allocatable）から既存ポッドのリクエスト合計を引いた残り にリクエストが収まるかでフィルタします。実使用が低くてもリクエストが大きければ「空きがない」とみなされ、ポッドは Pending（スケジュール不能） のまま残ります。CA はこの Pending ポッドを検知してノードを足すので、判断の通貨は終始リクエストです。

ノード追加：PendingポッドからノードグループとAZを選ぶ

CA のスケールアップは一定間隔（既定は数秒〜十数秒）のループで動きます。流れは次のとおりです。

スケールアップの判断ループ（概念）
  1. スケジュール不能なPendingポッドを集める
       （リソース不足・アフィニティ・taint等で載らないもの）
  2. 各ノードグループ（ASG/MIG/ノードプール）について:
       そのグループの「テンプレートノード」を1台仮想的に追加し、
       Pendingポッドがそのノードへスケジュールできるかを
       スケジューラと同じ述語（predicate）でシミュレート
  3. 載せられる候補グループを expander で1つ選ぶ
  4. 選んだグループの希望台数（desired）を増やす
       → クラウド側がノードを起動し、kubeletがNotReady→Readyへ

鍵は 2 のシミュレーション です。CA は各ノードグループの代表的なノード（既存ノードかテンプレート）を雛形に、「このグループを1台増やしたら、Pending ポッドのうち何個が載るか」をスケジューラと同じ述語（taint/toleration、nodeSelector、ノードアフィニティ、トポロジ分散制約、リソース残量など）で評価します。つまり CA は スケジューラの判断を先読みで再現 しているため、ポッドが要求するアフィニティや zone 制約はそのままノードグループ選択に効きます。

複数のノードグループが候補になったとき、どれを増やすかを決めるのが expander です。

AZ（可用性ゾーン）の選択 は二段構えで決まります。第一に、ポッドが zone のノードアフィニティやトポロジ分散制約（topologySpreadConstraints）を持つなら、CA はそれを満たせるノードグループだけを候補にします。第二に、ノードグループが複数 AZ にまたがる単一の ASG/MIG の場合、どの AZ に実際のノードが立つかはクラウド側のバランシング（例: AWS の Balanced across AZs）に委ねられ、CA は台数だけを指示します。ゾーンごとの厳密な制御が要るなら、AZ ごとにノードグループを分けるのが定石です。ステートフルワークロードで EBS のような ゾーン固定のボリュームを使う場合、ボリュームのある AZ にしかノードを立てられないため、この分割はとくに重要です。

ビンパッキングによる集約とコスト最適化

CA とスケジューラが目指すのは、少ない台数のノードへポッドを隙間なく詰めることです。これは古典的な ビンパッキング問題（容量の決まった箱に、できるだけ少ない箱数で品物を詰める）に対応します。ビンパッキングは NP 困難なので、実装は厳密最適ではなく ヒューリスティック（first-fit、best-fit など近似）でリクエストを配置します。

集約が効く理由は単純です。各ノードには kubelet・OS・DaemonSet などの 固定オーバーヘッドがあり、台数が増えるほどこのオーバーヘッドの総和が膨らみます。同じワークロードを少数の大きなノードに集約すれば、オーバーヘッドの本数が減り、断片化（fragmentation）——どのノードにも中途半端な空きが残ってポッドが載らない状態——も減って、結果としてノード台数=コストが下がります。least-waste expander や、後述する デフラグ（consolidation） はこの集約を能動的に進めます。

断片化の例（各ノードのallocatable=8、ポッドのリクエスト=5）
  詰め方A: ノード1[5+空き3]  ノード2[5+空き3]  → 2台、空き計6（無駄）
  詰め方B: もしリクエストが3なら 1ノードに[3+3+空き2] と集約可
  ※ リクエスト粒度とノード容量の比が断片化量を決める

ただしビンパッキングを攻めるほど 可用性とのトレードオフが顕在化します。少数の大ノードへ集約すると、1台の障害で同時に失うポッド数が増え、ブラスト半径が大きくなります。これを抑えるのがトポロジ分散制約（同一サービスのレプリカを複数ノード/AZへ散らす）で、集約（密に詰めたい）と分散（散らして守りたい）は本質的に綱引きします。CA はこの分散制約もシミュレーションに織り込むため、分散を強く要求すれば、空きがあっても新ノードが立つことがあります。

スケールダウン：過少利用ノードを安全に畳む

スケールダウンはスケールアップより慎重さが要ります。CA は各ノードを定期的に評価し、一定時間（既定はおよそ10分）連続して利用率がしきい値（既定でリクエスト合計が割り当て可能量の50%）を下回るノードを削除候補にします。ここでも判断は実使用ではなくリクエスト合計です。

削除の絶対条件は、そのノード上の全ポッドを、他の既存ノードへ退避（reschedule）できることです。CA は削除候補ノードを空にしたと仮定し、載っていたポッドを他ノードへ再配置できるかをシミュレートします。退避先が無ければ削除しません——畳んだ瞬間にポッドが Pending になって、すぐスケールアップし直す「フラッピング」を避けるためです。退避できると判明したら、ノードを cordon（新規スケジュール停止）→ drain（退避）→ 削除 の順で安全に畳みます（/devops/graceful-shutdown-draining/）。

ここで決定的に効くのが、退避を阻む二つの要因です。

• PodDisruptionBudget（PDB）: サービスごとに「同時に減らしてよいレプリカ数」の下限を宣言する仕組みです。minAvailable: 2 なら、退避によって可用レプリカが2を割る操作はブロックされます。CA はこの 自発的退避（voluntary disruption）の予算を尊重し、PDB を破る退避はしません。PDB が厳しすぎる（例: 3レプリカで minAvailable=3）と、退避が常にブロックされてノードが永久に畳めなくなります。
• ローカルストレージ（emptyDir / hostPath）: ノードのローカルディスクにデータを持つポッドは、別ノードへ移すとそのデータが失われます。CA は既定でローカルストレージを使うポッドが載ったノードを削除しません。明示的に許可する場合は、消えても良いと宣言するアノテーション（safe-to-evict 系）を付ける必要があります。

連携と原則：HPA・スケジューラ・priorityとの噛み合わせ

CA は単独では完結しません。HPA がリクエストの大きいレプリカを増やせば Pending が生まれ CA が追従し、HPA が縮めれば過少利用ノードが生まれ CA が畳む——HPA がポッド軸、CA がノード軸で噛み合います。また、緊急時にすぐ起動できる容量を確保したいなら、**低優先度の「バルーン（pause）ポッド」**で空き容量を予約し、本番ポッドが来たらプリエンプトで押し出して即スケジュール、CA が裏でノードを足す、というオーバープロビジョニング手法が使われます。これは PriorityClass とプリエンプションの仕組みに乗っています。

まとめ

• CA は リソースリクエストを通貨に判断する。スケジュール不能な Pending ポッドを検知してノードを足し、リクエスト合計が低い過少利用ノードを畳む。実使用量ではない点が肝。
• スケールアップは各ノードグループの テンプレートノードでスケジュール可否をシミュレートし、expander（least-waste/most-pods/price 等）で1グループを選ぶ。AZ はポッドの zone 制約とクラウド側バランシングで決まり、ゾーン固定が要るなら AZ ごとにグループを分ける。
• ビンパッキング（NP 困難を first-fit 等で近似）で少数の大ノードへ集約すると、固定オーバーヘッドと断片化が減りコストが下がる。ただし集約は ブラスト半径=可用性と綱引きし、トポロジ分散制約がそれを調停する。
• スケールダウンの絶対条件は 全ポッドの退避先が存在すること。PDB（最小可用数）・ローカルストレージ・safe-to-evict が退避を阻む三要因で、設定ミスはノードが畳めない静かなコスト漏れになる。
• CA は **HPA（ポッド軸）**と噛み合い、低優先度バルーンポッドで先行容量を予約する手法とも組み合わさる。判断はすべてリクエストとスケジューラ述語の先読みに根ざす。