# スケジューラーの設定
LLMS index: [llms.txt](/llms.txt)
---
FEATURE STATE:
Kubernetes v1.25 [stable]
設定ファイルを作成し、そのパスをコマンドライン引数として渡すことで`kube-scheduler`の振る舞いをカスタマイズすることができます。
スケジューリングプロファイルは、kube-schedulerでスケジューリングの異なるステージを設定することができます。
各ステージは、拡張点として公開されています。
プラグインをそれらの拡張点に1つ以上実装することで、スケジューリングの振る舞いを変更できます。
KubeSchedulerConfiguration [v1](/docs/reference/config-api/kube-scheduler-config.v1/)構造体を使用して、`kube-scheduler --config `を実行することで、スケジューリングプロファイルを指定することができます。
最小限の設定は次の通りです。
```yaml
apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
clientConnection:
kubeconfig: /etc/srv/kubernetes/kube-scheduler/kubeconfig
```
備考:
KubeSchedulerConfiguration v1beta3は、v1.26で非推奨となりv1.29で削除されました。
KubeSchedulerConfigurationを
v1へ移行するようにしてください。
備考:
score拡張点は、StorageCapacityScoring機能が有効になっている時に有効化されます。
要求されたボリュームに適合する最小のPVを優先的に使用します。
- `VolumeRestrictions`: ノードにマウントされたボリュームが、ボリュームプロバイダー固有の制限を満たしているかを確認します。
拡張点: `filter`
- `VolumeZone`: 要求されたボリュームがゾーン要件を満たしているかどうかを確認します。
拡張点: `filter`
- `NodeVolumeLimits`: ノードのCSIボリューム制限を満たすかどうかをチェックします。
このプラグインは、ノードにCSIドライバーがインストールされていない場合に、そのノードへのPod配置を防ぐこともできます(`VolumeLimitScaling`フィーチャーゲートの有効化が必要です)。
また、アタッチ可能なCSIボリュームを持つスケジュール待ちPodのために必要なノード数を、cluster-autoscalerが正確に算出できるようにします。
拡張点: `filter`
- `EBSLimits`: AWSのEBSボリューム制限がノードに対して満たされるかをチェックします。
拡張点: `filter`
- `GCEPDLimits`: GCP-PDボリューム制限がノードに対して満たされるかをチェックします。
拡張点: `filter`
- `AzureDiskLimits`: Azure Diskボリューム制限がノードに対して満たされるかをチェックします
拡張点: `filter`
- `InterPodAffinity`: [Pod間のアフィニティとアンチアフィニティ](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)を実装します。
拡張点: `preFilter`、`filter`、`preScore`、`score`
- `PrioritySort`: デフォルトの優先順位に基づくソートを提供します。
拡張点: `queueSort`.
- `DefaultBinder`: デフォルトのバインディングメカニズムを提供します。
拡張点: `bind`
- `DefaultPreemption`: デフォルトのプリエンプションメカニズムを提供します。
拡張点: `postFilter`
また、コンポーネント設定のAPIにより、以下のプラグインを有効にすることができます。
デフォルトでは有効になっていません。
- `CinderLimits`: ノードが[OpenStack Cinder](https://docs.openstack.org/cinder/)ボリューム制限を満たせるかチェックします。
拡張点: `filter`
### 複数のプロファイル {#multiple-profiles}
`kube-scheduler`は複数のプロファイルを実行するように設定することができます。
各プロファイルは関連するスケジューラー名を持ち、その[拡張点](#extension-points)に異なるプラグインを設定することが可能です。
以下のサンプル設定では、スケジューラーは2つのプロファイルで実行されます。
1つはデフォルトプラグインで、もう1つはすべてのスコアリングプラグインを無効にしたものです。
```yaml
apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: default-scheduler
- schedulerName: no-scoring-scheduler
plugins:
preScore:
disabled:
- name: '*'
score:
disabled:
- name: '*'
```
特定のプロファイルに従ってスケジュールさせたいPodは、Podの`.spec.schedulerName`に、対応するスケジューラー名を含めることができます。
デフォルトでは、スケジューラー名`default-scheduler`を持つ1つのプロファイルが生成されます。
このプロファイルは、上記のデフォルトプラグインを含みます。
複数のプロファイルを宣言する場合は、それぞれユニークなスケジューラー名にする必要があります。
もしPodがスケジューラー名を指定しない場合、kube-apiserverは`default-scheduler`を設定します。
従って、これらのPodをスケジュールするために、このスケジューラー名を持つプロファイルが存在する必要があります。
備考:
Podのスケジューリングイベントには、ReportingControllerとして.spec.schedulerNameが設定されています。
リーダー選出のイベントには、リスト先頭のプロファイルのスケジューラー名が使用されます。
さらなる情報は、Event APIリファレンスのreportingController項目をご参照ください。
備考:
すべてのプロファイルは、queueSort拡張点で同じプラグインを使用し、同じ設定パラメーターを持つ必要があります(該当する場合)。
これは、pending状態のPodキューがスケジューラーに1つしかないためです。
### 複数の拡張点に適用されるプラグイン {#multipoint}
`kubescheduler.config.k8s.io/v1beta3`からは、プロファイル設定に`multiPoint`というフィールドが追加され、複数の拡張点でプラグインを簡単に有効・無効化できるようになりました。
`multiPoint`設定の目的は、カスタムプロファイルを使用する際に、ユーザーや管理者が必要とする設定を簡素化することです。
`MyPlugin`というプラグインがあり、`preScore`、`score`、`preFilter`、`filter`拡張点を実装しているとします。
すべての利用可能な拡張点で`MyPlugin`を有効化するためには、プロファイル設定は次のようにします。
```yaml
apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: multipoint-scheduler
plugins:
multiPoint:
enabled:
- name: MyPlugin
```
これは以下のように、`MyPlugin`を手動ですべての拡張点に対して有効にすることと同じです。
```yaml
apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: non-multipoint-scheduler
plugins:
preScore:
enabled:
- name: MyPlugin
score:
enabled:
- name: MyPlugin
preFilter:
enabled:
- name: MyPlugin
filter:
enabled:
- name: MyPlugin
```
`multiPoint`を使用する利点の一つは、将来的に`MyPlugin`が別の拡張点を実装した場合に、`multiPoint`設定が自動的に新しい拡張点に対しても有効化されることです。
特定の拡張点は、その拡張点の`disabled`フィールドを使用して、`MultiPoint`の展開から除外することができます。
これは、デフォルトのプラグインを無効にしたり、デフォルト以外のプラグインを無効にしたり、ワイルドカード(`'*'`)を使ってすべてのプラグインを無効にしたりする場合に有効です。
`Score`と`PreScore`を無効にするためには、次の例のようにします。
```yaml
apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: non-multipoint-scheduler
plugins:
multiPoint:
enabled:
- name: 'MyPlugin'
preScore:
disabled:
- name: '*'
score:
disabled:
- name: '*'
```
`v1beta3`からは、`MultiPoint`を通じて、内部的に全ての[デフォルトプラグイン](#scheduling-plugins)が有効化されています。
しかしながら、デフォルト値(並び順やスコアの重みなど)を柔軟に設定し直せるように、個別の拡張点は用意されています。
例えば、2つのスコアプラグイン`DefaultScore1`と`DefaultScore2`に、重み1が設定されているとします。
その場合、次のように重さを変更し、並べ替えることができます。
```yaml
apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: multipoint-scheduler
plugins:
score:
enabled:
- name: 'DefaultScore2'
weight: 5
```
この例では、`MultiPoint`はデフォルトプラグインであるため、明示的にプラグイン名を指定する必要はありません。
そして、`Score`に指定されているプラグインは`DefaultScore2`のみです。
これは、特定の拡張点を通じて設定されたプラグインは、常に`MultiPoint`プラグインよりも優先されるためです。
つまり、この設定例では、結果的に2つのプラグインを両方指定することなく、並び替えが行えます。
`MultiPoint`プラグインを設定する際の一般的な優先順位は、以下の通りです。
1. 特定の拡張点が最初に実行され、その設定は他の場所で設定されたものよりも優先される
2. `MultiPoint`を使用して、手動で設定したプラグインとその設定内容
3. デフォルトプラグインとそのデフォルト設定
上記の優先順位を示すために、次の例はこれらのプラグインをベースにします。
|プラグイン|拡張点|
|---|---|
|`DefaultQueueSort`|`QueueSort`|
|`CustomQueueSort`|`QueueSort`|
|`DefaultPlugin1`|`Score`, `Filter`|
|`DefaultPlugin2`|`Score`|
|`CustomPlugin1`|`Score`, `Filter`|
| プラグイン | 拡張点 |
| ------------------ | ----------------- |
| `DefaultQueueSort` | `QueueSort` |
| `CustomQueueSort` | `QueueSort` |
| `DefaultPlugin1` | `Score`、`Filter` |
| `DefaultPlugin2` | `Score` |
| `CustomPlugin1` | `Score`、`Filter` |
| `CustomPlugin2` | `Score`、`Filter` |
これらのプラグインの有効な設定例は次の通りです。
```yaml
apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: multipoint-scheduler
plugins:
multiPoint:
enabled:
- name: 'CustomQueueSort'
- name: 'CustomPlugin1'
weight: 3
- name: 'CustomPlugin2'
disabled:
- name: 'DefaultQueueSort'
filter:
disabled:
- name: 'DefaultPlugin1'
score:
enabled:
- name: 'DefaultPlugin2'
```
なお、特定の拡張点に`MultiPoint`プラグインを再宣言しても、エラーにはなりません。
特定の拡張点が優先されるため、再宣言は無視されます(ログは記録されます)。
このサンプルは、ほとんどの設定を一箇所にまとめるだけでなく、いくつかの工夫をしています。
* カスタムの`queueSort`プラグインを有効にし、デフォルトのプラグインを無効にする。
* `CustomPlugin1`と`CustomPlugin2`を有効にし、この拡張点のプラグイン内で、最初に実行されるようにする。
* `filter`拡張点でのみ、`DefaultPlugin1`を無効にする。
* `score`拡張点で`DefaultPlugin2`が最初に実行されるように並べ替える(カスタムプラグインより先に)。
`v1beta3`以前のバージョンで、`multiPoint`がない場合、上記の設定例は、次のものと同等になります。
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta2
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: multipoint-scheduler
plugins:
# デフォルトQueueSortプラグインを無効化
queueSort:
enabled:
- name: 'CustomQueueSort'
disabled:
- name: 'DefaultQueueSort'
# カスタムFilterプラグインを有効化
filter:
enabled:
- name: 'CustomPlugin1'
- name: 'CustomPlugin2'
- name: 'DefaultPlugin2'
disabled:
- name: 'DefaultPlugin1'
# カスタムScoreプラグインを有効化し、実行順を並べ替える
score:
enabled:
- name: 'DefaultPlugin2'
weight: 1
- name: 'DefaultPlugin1'
weight: 3
```
これは複雑な例ですが、`MultiPoint`設定の柔軟性と、拡張点を設定する既存の方法とのシームレスな統合を実証しています。
## スケジューラー設定の移行
-
v1beta2のバージョンの設定では、新しいNodeResourcesFitプラグインをスコア拡張点で使用できます。
この新しい拡張機能は、NodeResourcesLeastAllocated、NodeResourcesMostAllocated、 RequestedToCapacityRatioプラグインの機能を組み合わせたものです。
例えば、以前までNodeResourcesMostAllocatedプラグインを使っていたなら、代わりにNodeResourcesFitプラグインを使用し(デフォルトで有効)、pluginConfigに次のようなscoreStrategyを追加することになるでしょう。
apiVersion: kubescheduler.config.k8s.io/v1beta2
kind: KubeSchedulerConfiguration
profiles:
- pluginConfig:
- args:
scoringStrategy:
resources:
- name: cpu
weight: 1
type: MostAllocated
name: NodeResourcesFit
-
スケジューラープラグインのNodeLabelは廃止されました。
代わりにNodeAffinityプラグイン(デフォルトで有効)を使用することで同様の振る舞いを実現できます。
-
スケジューラープラグインのServiceAffinityは廃止されました。
代わりにInterPodAffinityプラグイン(デフォルトで有効)を使用することで同様の振る舞いを実現できます。
-
スケジューラープラグインのNodePreferAvoidPodsは廃止されました。
代わりにノードのTaintを使用することで同様の振る舞いを実現できます。
-
v1beta2で有効化されたプラグインは、そのプラグインのデフォルトの設定より優先されます。
-
スケジューラーのヘルスとメトリクスのバインドアドレスに設定されているhostやportが無効な場合、バリデーションに失敗します。
- デフォルトで3つのプラグインの重みが増加しました。
InterPodAffinity:1から2NodeAffinity:1から2TaintToleration:1から3
- スケジューラープラグインの
SelectorSpreadは廃止されました。
代わりにPodTopologySpreadプラグイン(デフォルトで有効)を使用することで同様の振る舞いを実現できます。