こんにちは、タカサオです！

2026年8月12日のアップデートで、Amazon EKS が Kubernetes コントロールプレーンのパラメータ設定に対応しました。

これまで触れなかったスケジューラの挙動を、クラスターの設定として変更できるようになっています。

その中に scoringStrategy という設定があります。ざっくり言うと、Pod をノードに広く散らすか、少ないノードに詰め込むかを選べる設定です。詰め込む方を選ぶと、同じ Pod を動かすのに必要なサーバー台数が減る可能性があります。

ただ、この設定は名前だけ見ても何が起きるのか分かりにくいです。今回は実際のスコア計算を追いかけながら、図でイメージできるように解説してみます！

対象バージョンと前提

項目	内容
発表日	2026年8月12日
対応バージョン	Kubernetes 1.31 以降
対応リージョン	Amazon EKS が使える全リージョン
追加料金	なし

そもそもスケジューラとは何をしているのか

Kubernetes では、アプリは Pod という単位で動きます。そして Pod が実際に動く場所が ノード（EC2 インスタンスなどのサーバー）です。

ここで、その Pod をどのノードで動かすかを決めているのが スケジューラ です。

Pod は「CPU をこれくらい使います」という リクエスト を持っています。スケジューラはこのリクエストを見て、空きのあるノードを探します。

ここで大事なのは、リクエストはあくまで申告値であって、実際の使用量ではないという点です。スケジューラは実際の負荷ではなく、申告された数字だけを見て判断しています。

アップデートで何ができるようになったのか

これまで EKS では、このスケジューラの細かい挙動を利用者が変更できませんでした。今回のアップデートで、以下のパラメータをクラスターの設定として変更できるようになりました。

対象	パラメータ	できること
スケジューラ	`nodeResourcesFit.scoringStrategy`	Pod を散らすか詰めるかを選べる
コントローラーマネージャー	`horizontalPodAutoscalerSyncPeriod`	オートスケールの判断間隔を短くできる
コントローラーマネージャー	`terminatedPodGcThreshold`	終了した Pod の掃除タイミングを変えられる
API サーバー	`eventTtl`	イベントの保持期間を短くできる
API サーバー	`serviceNodePortRange`	使うポート番号の範囲を変えられる

この記事で扱うのは一番上の scoringStrategy です。

スケジューラは3ステップでノードを選んでいる

scoringStrategy の話に入る前に、スケジューラがどうやってノードを決めているかを押さえます。実は3ステップに分かれています。

① 絞り込み では、そもそもその Pod が入らないノードを候補から外します。空きが足りないノードはここで消えます。

② 点数付け では、残ったノードそれぞれに点数をつけます。

③ 割り当て で、一番点数の高いノードに Pod を置きます。

今回のアップデートで変えられるのは ② の点数のつけ方だけ です。ここが結構重要で、①は変わりません。つまり、入らないノードに無理やり詰め込むようなことは起きない仕組みになっています。あくまで入るノードが複数あるときに、どれを選ぶかが変わるだけです。

選べるスコアリング戦略

では点数のつけ方を見ていきます。選べるのは2つです。

設定値	点数の計算	性格
LeastAllocated（デフォルト）	空いている割合 × 100	空いているノードほど高得点 → 散らす
MostAllocated	使われている割合 × 100	詰まっているノードほど高得点 → 詰める

どちらも一番点数の高いノードを選ぶという動きは同じです。見ている数字が空きなのか使用率なのかだけが違います。

なので、2つの点数を足すと必ず 100 になります。ちょうど正反対の関係になっています。

なお点数を計算するときの使用率には、これから置こうとしている Pod の分も含まれます。置いた後の状態で採点するイメージです。

例1: 3台のノードから1台を選んでみる

言葉だけだと分かりにくいので、実際に計算してみます。

1台あたり 4000m の CPU が使えるノードが3台あるとします（m はミリコアという単位で、1000m = CPU 1個分です）。それぞれ使用量が違う状態を考えます。

NodeA [██████░░]  使用 3000m / 空き 1000m
NodeB [████░░░░]  使用 2000m / 空き 2000m
NodeC [█░░░░░░░]  使用  500m / 空き 3500m

  █ = 使用中     ░ = 空き     1マス = 500m

ここに 500m の Pod を1個置きます。それぞれの点数はこうなります。

	置いた後の使用量	LeastAllocated の点数	MostAllocated の点数
NodeA	3500m	(4000−3500)÷4000 = 12.5点	3500÷4000 = 87.5点
NodeB	2500m	(4000−2500)÷4000 = 37.5点	2500÷4000 = 62.5点
NodeC	1000m	(4000−1000)÷4000 = 75.0点	1000÷4000 = 25.0点

結果はこうなります。

LeastAllocated → 75点の NodeC（一番空いているノード）
MostAllocated → 87.5点の NodeA（一番詰まっているノード）

各行の左右を足すと 100 になっているのが分かると思います。これが先ほど正反対と書いた理由です。

例2: Podを9個、続けて置いてみる

1個だけだとイメージしづらいので、連続で置いたときにどうなるかを見てみます。

空っぽのノード2台（各 4000m = 8マス）に、500m の Pod を9個、順番に置いていきます。

LeastAllocated の場合: 交互に置かれていく

何個目	直前の状態	Aの点数	Bの点数	置かれる先
1個目	A:0 / B:0	87.5	87.5	A（同点）
2個目	A:500 / B:0	75.0	87.5	B
3個目	A:500 / B:500	75.0	75.0	A（同点）
4個目	A:1000 / B:500	62.5	75.0	B
5個目	A:1000 / B:1000	62.5	62.5	A（同点）

Pod を置くとそのノードの空きが減るので、点数が下がります。すると次は反対側が勝ちます。この繰り返しで、左右交互に置かれていきます。

9個置き終わるとこうなります。

NodeA [█████░░░]  Pod 5個 = 2500m
NodeB [████░░░░]  Pod 4個 = 2000m

MostAllocated の場合: 1台を埋めきってから次に行く

何個目	直前の状態	Aの点数	Bの点数	置かれる先
1個目	A:0 / B:0	12.5	12.5	A（同点）
2個目	A:500 / B:0	25.0	12.5	A
3個目	A:1000 / B:0	37.5	12.5	A
4個目	A:1500 / B:0	50.0	12.5	A
5個目	A:2000 / B:0	62.5	12.5	A

今度は逆です。Pod を置くとそのノードの使用率が上がるので、点数も上がります。だから同じノードが勝ち続けます。

A が満杯になると、①の絞り込みで A が候補から外れます。そこではじめて B に移ります。

9個置き終わるとこうなります。

NodeA [████████]  Pod 8個 = 4000m（満杯）
NodeB [█░░░░░░░]  Pod 1個 =  500m

同じ9個の Pod なのに、並び方がまったく変わりました。

総量は変わらないが、空きの散らばり方が変わる

ここで両者を比べてみます。

	NodeA	NodeB	使用量の合計	空きの合計
LeastAllocated	2500m	2000m	4500m	3500m
MostAllocated	4000m	500m	4500m	3500m

使っている総量も、空いている総量も、まったく同じです。

考えてみれば当たり前で、Pod 9個は9個分の容量しか使いません。詰め方を変えても総量は変わりません。

違うのは、空き 3500m がどう散らばっているかです。

LeastAllocated                    MostAllocated

NodeA [█████░░░] 空き1500m        NodeA [████████] 空き   0m
NodeB [████░░░░] 空き2000m        NodeB [█░░░░░░░] 空き3500m

  空きがバラバラに散らばる           空きが1か所にまとまる

同じ 3500m でも、細かく散らばっているか、1か所にまとまっているかが違います。

サイズの違うPodが来たときに差が出る

では、この散らばり方の違いは何に効くのでしょうか。

ここに 2500m の大きめの Pod（5マス分）を1個追加してみます。

LeastAllocated
NodeA [█████░░░] 空き 3マス → 5マスは入らない
NodeB [████░░░░] 空き 4マス → 5マスは入らない
                              ↓
                    どのノードにも入らない！
                    → 新しいノードが必要になる


MostAllocated
NodeA [████████] 空き 0マス → 入らない
NodeB [█░░░░░░░] 空き 7マス → 5マスが入る！
                              ↓
                    今あるノードに収まった
                    → ノードを増やさずに済む

空きの合計はどちらも 3500m で同じなのに、片方だけ入りません。

これが MostAllocated の嬉しいところです。空きを1か所にまとめておくと、あとから大きめの Pod が来ても既存のノードに収まる確率が上がります。結果として、サーバーの台数を抑えられる可能性が出てきます。

逆に言うと、動かしている Pod のサイズが全部同じ場合、この差は出にくいです。上の例でも、追加するのが 500m の Pod だったらどちらにも入ります。Pod のサイズがバラバラなワークロードほど効いてくる、と考えると分かりやすいと思います。

なお、スケジューラは今回説明した計算以外にもいくつかの観点で点数をつけていて、その合計で最終的な行き先を決めています。なので、必ずしも上の例のようにきれいに詰まるとは限りません。

まとめ

今回は EKS で設定できるようになったスケジューラのスコアリング戦略について解説しました。

	LeastAllocated（デフォルト）	MostAllocated
点数のつけ方	空いている割合	使われている割合
選ばれるノード	一番空いているノード	一番詰まっているノード
Pod の並び方	広く散らばる	少数のノードに集まる
得意なこと	各ノードに余裕を残せる	ノード台数を抑えられる可能性がある
苦手なこと	大きい Pod が入らないことがある	1台障害時の影響範囲が広がる可能性がある

ポイントは、2つの設定が同じ数字を裏返しに見ているだけという点だと思います。仕組みが分かってしまえば、なぜ散らばるのか、なぜ詰まるのかがすっきり理解できるのではないでしょうか。

そして効果が出るかどうかは、Pod のサイズがバラバラかどうかにかかっています。サイズが揃っているワークロードなら設定を変えてもあまり変わらないはずなので、そこは切り分けて考えたいところです。

長らく触れなかったスケジューラの挙動が設定項目として出てきたのは面白いなと思いました。次は実際にクラスターを立てて、台数がどれくらい変わるのか測ってみたいです！

それではまた！

参考