Kubernetes 1.31: SIG-Scheduling の変更内容

Kubernetes 1.31 の [CHANGELOG](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.31.md) から、SIG-Scheduling に関するところを抜粋して紹介します。 :pencil: は筆者によるコメントです。

過去 3 リリースの変更内容：

- [Kubernetes 1.30: SIG-Scheduling の変更内容](https://qiita.com/ordovicia/items/fc0053e0d27d5b0bcca0)
- [Kubernetes 1.29: SIG-Scheduling の変更内容](https://qiita.com/ordovicia/items/e99d8ab6ca3b540b70e1)
- [Kubernetes 1.28: SIG-Scheduling の変更内容](https://qiita.com/ordovicia/items/df66b4f3712f1783c62a)

## :pencil: 所感

In-tree のスケジューラプラグインに対して QueueingHint の実装が進んでいます。
ほとんどのプラグインで実装が完了し、残すプラグインは数個です。
[[Umbrella] Implement QueueingHintFn in in-tree plugins · Issue #118893 · kubernetes/kubernetes](https://github.com/kubernetes/kubernetes/issues/118893)

それに伴ってか、pod の更新イベントが起こったときに、QueueingHint を使って pod を再エンキューするかどうか判断する機能が入りました。
`SchedulerQueueingHints` フィーチャゲートで有効になります（デフォルトで無効）。

また、`PodDisruptionConditions` と `JobPodFailurePolicy` が GA に昇格しました。
`PodDisruptionConditions` では、プリエンプションなど pod が削除された理由が pod の `DisruptionTarget` condition に記録されます。
`JobPodFailurePolicy` では、コンテナの終了コードや pod の condition によって、Job で管理される pod が失敗したかどうかの判定を制御できます。
これらを組み合わせると、プリエンプションは pod の失敗とは見なさないようにすることで、プリエンプションが頻発したことによって Job が失敗するという状況を回避できます。
計算リソースが有限の Kubernetes クラスタで使えるとうれしい機能です。

## Urgent Upgrade Notes

`SchedulerQueueingHints` フィーチャゲートが有効化されている場合、pod の更新イベントが起こったときに、スケジューラが QueueingHint を使い、スケジュール不可能と判定されていた pod のスケジュール可能性を判断するようになりました。
これまでは、スケジュール不可能と判定されていた pod が更新されると、スケジューラは常に pod を activeQ/backoffQ に戻していました。
しかし、とくに多くのスケジューリング制約は不変であることから、すべての pod の更新イベントが、pod をスケジュール可能にするわけではありません。
これからは、スケジュール不可能と判断されていた pod が更新されると、スケジューラは QueueingHint を処理し、この更新イベントによって pod がスケジュール可能になりうるかどうかを判断し、少なくとも 1 つの QueueingHint が `Queue` を返す場合にのみ、pod を activeQ/backoffQ に再キューイングします。

カスタムスケジューラプラグイン開発者はアクションが必要です：
カスタムプラグインによる pod のスケジュール不可能という判定が、pod の更新により解決される可能性がある場合、カスタムプラグインは pod の更新イベントに対して QueueingHint を実装する必要があります。
例：`schedulable=false` ラベルを持つ pod を拒否するカスタムプラグインを開発するとします。
`schedulable=false` ラベルが削除されると、その pod はスケジュール可能になるため、このプラグインは未スケジュールの pod でこのようなラベルの変更がおこなわれた場合に `Queue` を返す pod 更新イベントの QueueingHint を実装する必要があります。
([#122234](https://github.com/kubernetes/kubernetes/pull/122234), [@AxeZhan](https://github.com/AxeZhan)) [SIG Scheduling and Testing]

## Changes by Kind

### Deprecation

kube-scheduler はすべての CSI でないボリュームタイプの Volume Limit プラグインを非推奨化し、デフォルトのプラグインから削除しました。

- `AzureDiskLimits`
- `CinderLimits`
- `EBSLimits`
- `GCEPDLimits`

これらのボリュームタイプは CSI に移行したため、`NodeVolumeLimits` プラグインが同じ機能を提供します。
スケジューラの設定でこれらのプラグインを明示的に使用している場合は削除し、`NodeVolumeLimits` プラグインに置き換えてください。
これらのプラグインは 1.32 で削除されます。
([#124500](https://github.com/kubernetes/kubernetes/pull/124500), [@carlory](https://github.com/carlory)) [SIG Scheduling and Storage]

### API Change

- `CoordinatedLeaderElection` フィーチャゲートで有効にできる、Coordinated Leader Election 機能をアルファとして追加しました。この機能が有効の場合、コントロールプレーンは LeaseCandidate オブジェクト（`coordination.k8s.io/v1alpha1` API グループ）を使ってリーダ選出に参加でき、kube-apiserver がある戦略にしたがった最も良いインスタンスを選択します。([#124012](https://github.com/kubernetes/kubernetes/pull/124012), [@Jefftree](https://github.com/Jefftree)) [SIG API Machinery, Apps, Auth, Cloud Provider, Etcd, Node, Release, Scheduling and Testing]
    - :pencil: フィーチャゲートが有効な場合、kube-scheduler も LeaseCandidate を使ったリーダ選出をおこないます
- Dynamic Resource Allocation (DRA): `ResourceQuota` を使い、ネームスペースごとの ResourceClaim オブジェクトの個数や、特定のクラスから要求されるデバイスの個数を制限できる機能が追加されました。([#120611](https://github.com/kubernetes/kubernetes/pull/120611), [@pohly](https://github.com/pohly)) [SIG API Machinery, Apps, Auth, CLI, Etcd, Node, Release, Scheduling and Testing]
- Dynamic Resource Allocation (DRA): `pod.spec.resourceClaims` 配列において、`source` フィールドによる間接参照が不要になりました。例えば、`source: resourceClaimTemplateName: my-template` の代わりに、`resourceClaimTemplateName: my-template` と記述できます。([#125116](https://github.com/kubernetes/kubernetes/pull/125116), [@pohly](https://github.com/pohly)) [SIG API Machinery, Apps, Auth, Node, Scheduling and Testing]
- Dynamic Resource Allocation (DRA) を改善し、`resource.k8s.io` API グループに新しいバージョンを追加しました。主なユーザ向けのタイプは ResourceClaim のままですが、大きなな変更がおこなわれ、新しいバージョン `v1alpha3` が導入されました。このバージョンは以前のバージョンと互換性がありません。([#125488](https://github.com/kubernetes/kubernetes/pull/125488), [@pohly](https://github.com/pohly)) [SIG API Machinery, Apps, Auth, CLI, Cluster Lifecycle, Etcd, Node, Release, Scheduling, Storage and Testing]
    - :pencil: 変更内容は [KEP-4381 を更新する PR](https://github.com/kubernetes/enhancements/pull/4709) に書かれています。
- `PodDisruptionConditions` を GA に昇格し、常に有効になるようにしました。([#125461](https://github.com/kubernetes/kubernetes/pull/125461), [@mimowo](https://github.com/mimowo)) [SIG Apps, Node, Scheduling and Testing]
    - :pencil: Pod に `DisruptionTarget` condition が追加され、プリエンプションなど pod が削除された理由が示されるという機能です。[Disruptions | Kubernetes](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/#pod-disruption-conditions)
- PodAffinity/PodAntiAffinity における MatchLabelKeys/MismatchLabelKeys をベータに昇格しました。([#123638](https://github.com/kubernetes/kubernetes/pull/123638), [@sanposhiho](https://github.com/sanposhiho)) [SIG API Machinery, Apps, Scheduling and Testing]
    - :pencil: デフォルトで有効になりました。 例えば、ReplicaSet で管理されている pod 群のアフィニティに `matchLabelKeys: [pod-template-hash]` という条件を追加することで、ローリングアップデートの際に同じリビジョンの pod 群だけをアフィニティの計算に入れることができるという機能です。
- `JobPodFailurePolicy` を GA に昇格し、常に有効になるようにしました。([#125442](https://github.com/kubernetes/kubernetes/pull/125442), [@mimowo](https://github.com/mimowo)) [SIG API Machinery, Apps, Scheduling and Testing]
    - :pencil: コンテナの終了コードや pod の condition によって、pod が失敗したかどうかの判定を制御できるという機能です。[Jobs | Kubernetes](https://kubernetes.io/docs/concepts/workloads/controllers/job/#pod-failure-policy)
- ノードの数が多く、PreFilter が 1, 2 ノード（例えば DaemonSet）を返す場合のスケジューリング性能を向上させました。Out-of-tree の PostFilter プラグインの開発者は、`NodeToStatusMap` のセマンティクスが変更されることに注意してください。`NodeToStatusMap` に値が存在しないノードは、`UnschedulableAndUnresolvable` ステータスを持つものとして解釈されるべきです。([#125197](https://github.com/kubernetes/kubernetes/pull/125197), [@gabesaba](https://github.com/gabesaba)) [sig/scheduling]
    - :pencil: `NodeToStatusMap` は、pod がスケジュール不可能だった各ノードについて、プリエンプションによってスケジュール可能になるか否かを記録しています。マップにノードが存在しない場合の状態を仮定することでスループットを上げました。

### Feature

- カスタムスケジューラプラグイン開発者はアクションが必要です：`EnqueueExtensions` インターフェイスの `EventsToRegister` が引数として `ctx` を受け取り、戻り値に `error` を含むようになりました。プラグインの実装をそれに応じて変更してください。([#126113](https://github.com/kubernetes/kubernetes/pull/126113), [@googs1025](https://github.com/googs1025)) [SIG Node, Scheduling, Storage and Testing]
    - :pencil: Wasm でスケジューラプラグインを開発するときにこれらが必要になったのが、この変更のきっかけのようです。[Implement EnqueueExtensions by codefromthecrypt · Pull Request #55 · kubernetes-sigs/kube-scheduler-wasm-extension](https://github.com/kubernetes-sigs/kube-scheduler-wasm-extension/pull/55)
- `VolumeAttributesClass` フィーチャゲートが有効な場合、claim に適した永続ボリュームを探すときに、kube-controller-manager は PVC と PV オブジェクトの `volumeAttributesClassName` フィールドを認識します。`volumeAttributesClassName` フィールドは、ボリュームの可変な属性を表現する一連の key-value ペアを含む VolumeAttributesClass オブジェクトへの参照です。PVC が PV オブジェクトにバインドされるまで、PVC オブジェクトの `volumeAttributesClassName` フィールドを変更することは禁止されています。バインド処理中に、PVC が `volumeAttributesClassName` フィールドをもつ場合、コントローラーは同じ `volumeAttributesClassName` を持つボリュームのみを考慮します。`volumeAttributesClassName` フィールドが設定されていないか空の文字列に設定されている場合、空の `volumeAttributesClassName` を持つボリュームのみが考慮されます。([#121902](https://github.com/kubernetes/kubernetes/pull/121902), [@carlory](https://github.com/carlory)) [SIG Apps, Scheduling, Storage and Testing]
- `event_handling_duration_seconds` メトリックを実装しました。これは、スケジューラーが各種イベントを処理するのにかかる時間です。([#125929](https://github.com/kubernetes/kubernetes/pull/125929), [@sanposhiho](https://github.com/sanposhiho)) [sig/scheduling]
- `queueing_hint_execution_duration_seconds` メトリックを実装しました。これは、QueueingHint 関数が実行されるのにかかる時間です。([#126227](https://github.com/kubernetes/kubernetes/pull/126227), [@sanposhiho](https://github.com/sanposhiho)) [sig/scheduling]
- スケジューラープラグイン向けに、新しいクラスタイベント `UpdatePodScaleDown` と `UpdatePodLabel` を実装しました。([#122628](https://github.com/kubernetes/kubernetes/pull/122628), [@sanposhiho](https://github.com/sanposhiho)) [sig/scheduling]
- kube-scheduler は `CSILimit` プラグインに対するスケジューリングヒントを実装しました。このスケジューリングヒントにより、削除された pod が同じドライバからの PVC を持っていた場合、以前に `CSILimit` プラグインによって拒否された pod のスケジューリングを再試行することができます。([#121508](https://github.com/kubernetes/kubernetes/pull/121508), [@utam0k](https://github.com/utam0k)) [SIG Scheduling and Storage]
- kube-scheduler は `VolumeRestriction` プラグインに対するスケジューリングヒントを実装しました。このスケジューリングヒントにより、削除された pod がスケジュール対象の pod のボリュームと競合していた場合、以前に `VolumeRestriction` プラグインによって拒否された pod のスケジューリングを再試行することができます。([#125279](https://github.com/kubernetes/kubernetes/pull/125279), [@HirazawaUi](https://github.com/HirazawaUi)) [SIG Scheduling and Storage]
- kube-scheduler は `VolumeRestriction` プラグインに対するスケジューリングヒントを実装しました。このスケジューリングヒントにより、新しく PVC が追加され、その PVC が pod に属している場合、以前に `VolumeRestriction` プラグインによって拒否された pod のスケジューリングを再試行することができます。([#125280](https://github.com/kubernetes/kubernetes/pull/125280), [@HirazawaUi](https://github.com/HirazawaUi)) [SIG Scheduling and Storage]
- kube-scheduler は `VolumeZone` プラグインに対するスケジューリングヒントを実装しました。このスケジューリングヒントにより、ノードの追加・更新、PV の追加・更新、PVC の追加・更新、または StorageClass の追加が pod のトポロジ設定に一致する場合にのみ、以前に `VolumeZone` プラグインによって拒否された pod のスケジューリングを再試行することができます。([#124996](https://github.com/kubernetes/kubernetes/pull/124996), [@Gekko0114](https://github.com/Gekko0114)) [SIG Scheduling and Storage]
- kube-scheduler は VolumeZone プラグインに対するスケジューリングヒントを実装しました。このスケジューリングヒントにより、ノードの追加/更新、PV の追加/更新、PVC の追加/更新、または SC の追加がポッドのトポロジ設定に一致する場合にのみ、以前に VolumeZone プラグインによって拒否されたポッドのスケジューリングを再試行することができます。([#125000](https://github.com/kubernetes/kubernetes/pull/125000), [@Gekko0114](https://github.com/Gekko0114)) [SIG Scheduling and Storage] [sig/scheduling,sig/storage]
- `LogarithmicScaleDown` フィーチャゲートを GA に昇格し、常に有効になるようにしました。([#125459](https://github.com/kubernetes/kubernetes/pull/125459), [@MinpengJin](https://github.com/MinpengJin)) [SIG Apps and Scheduling]
    - :pencil: ReplicaSet をスケールインする際、実行時間で pod を並び替えるときにある程度近い値を同一視することで、削除される pod のランダム性を高める機能です。[KEP-2185: Random Pod Selection on ReplicaSet Downscale](https://github.com/kubernetes/enhancements/tree/master/keps/sig-apps/2185-random-pod-select-on-replicaset-downscale)
- スケジューラが `evaluatedNodes` を計算するロジックを、「PreFilterResult および Filter プラグインによってフィルタされたノードの数」から「Filter プラグインによってフィルタされたノードのみの数」に変更しました。([#124735](https://github.com/kubernetes/kubernetes/pull/124735), [@AxeZhan](https://github.com/AxeZhan)) [sig/scheduling]
    - :pencil: Kubernetes 1.29 以前の仕様に戻りました。
- kube-scheduler は `InterPodAffinity` プラグインに対するスケジューリングヒントを追加しました。このスケジューリングヒントにより、関連する pod または pod affinity に合致するノードに変更（作成・削除・更新）があった場合、以前に `InterPodAffinity` プラグインによって拒否された pod のスケジューリングを再試行することができます。([#122471](https://github.com/kubernetes/kubernetes/pull/122471), [@nayihz](https://github.com/nayihz)) [SIG Scheduling and Testing]
- kube-scheduler は `VolumeBinding` プラグインに対して、CSIStorageCapacity リソースに関するスケジューリングヒントを追加しました。このスケジューリングヒントにより、プラグインによって参照される新しいリソースが作成されたか既存のリソースが更新された場合にのみ、以前に `VolumeBinding` プラグインによって拒否された pod のスケジューリングを再試行することができます。([#124961](https://github.com/kubernetes/kubernetes/pull/124961), [@bells17](https://github.com/bells17)) [SIG Scheduling and Storage]
- kube-scheduler は `VolumeBinding` プラグインに対して、PersistentVolumeClaim リソースに関するスケジューリングヒントを追加しました。このスケジューリングヒントにより、プラグインによって参照される新しいリソースが作成されたか既存のリソースが更新された場合にのみ、以前に `VolumeBinding` プラグインによって拒否された pod のスケジューリングを再試行することができます。([#124959](https://github.com/kubernetes/kubernetes/pull/124959), [@bells17](https://github.com/bells17)) [SIG Scheduling and Storage]
- kube-scheduler は `VolumeBinding` プラグインに対して、StorageClass リソースに関するスケジューリングヒントをサポートしました。このスケジューリングヒントにより、プラグインによって参照される新しいリソースが作成されたか既存のリソースが更新された場合にのみ、以前に `VolumeBinding` プラグインによって拒否された pod のスケジューリングを再試行することができます。([#124958](https://github.com/kubernetes/kubernetes/pull/124958), [@bells17](https://github.com/bells17)) [SIG Scheduling and Storage]
- スケジューラーは `TaintToleration` プラグインに QueueingHint を実装し、スケジューリングのスループットを向上させました。([#124287](https://github.com/kubernetes/kubernetes/pull/124287), [@sanposhiho](https://github.com/sanposhiho)) [SIG Scheduling and Testing]
- スケジューラーは `VolumeBinding` プラグインの CSINode イベントに QueueingHint を実装し、スケジューリングのスループットを向上させました。([#125097](https://github.com/kubernetes/kubernetes/pull/125097), [@YamasouA](https://github.com/YamasouA)) [SIG Scheduling and Storage]
- ユーザは `IterateOverWaitingPods` メソッドを使い、スケジューラ内の permit ステージで待機しているすべての pod を走査できます。つまり、スケジューラ内のすべての `waitingPods` は任意のプロファイルから取得できます。以前は、各プロファイルはそのプロファイル内の `waitingPods` のみを取得できました。([#124926](https://github.com/kubernetes/kubernetes/pull/124926), [@kerthcet](https://github.com/kerthcet)) [SIG Scheduling]
    - :pencil: 一つのグループに属するが別々のプロファイルでスケジュールされる pod 群を gang scheduling するユースケースがあります。

### Failing Test

SIG-Scheduling に関連する項目はありません。

### Bug or Regression

- Dynamic Resource Allocation (DRA): Pod 間で再利用される claim に構造化パラメータを使用すると、無効な状態（ファイナライザなしで割当てられる）の claim が発生し、その claim を使用する pod のスケジューリングが停止する可能性がありました。([#124931](https://github.com/kubernetes/kubernetes/pull/124931), [@pohly](https://github.com/pohly)) [SIG Node and Scheduling]
- `PodTopologySpread` プラグインが pod を拒否した場合、最悪の場合、それらが 5 分間 Pending 状態にスタックするバグを修正しました。同じ問題は、`EventsToRegister` に Pod/Add または Pod/Update イベントが含まれるカスタムプラグインでも発生する可能性があり、この PR で解決されましたが、`SchedulerQueueingHints` フィーチャゲートが有効な場合に限ります。([#122627](https://github.com/kubernetes/kubernetes/pull/122627), [@sanposhiho](https://github.com/sanposhiho)) [SIG Scheduling and Testing]
    - :pencil: スケジュール不可能と判断された pod の Topology Spread Constraint に関係する、かつ `spec.nodeName` が設定されている pod が作成・更新された場合に、この問題が起こっていました。Pod の作成・更新イベントのハンドラで、`PodTopologySpread` プラグインが以前に拒否した pod を再キューイングするようにすることで修正されました。
- PreFilter プラグインが、存在しないノードを返すとスケジューラがクラッシュするバグを修正しました。([#124933](https://github.com/kubernetes/kubernetes/pull/124933), [@AxeZhan](https://github.com/AxeZhan)) [SIG Scheduling and Testing]
- Pod 以外のリソースの変更により結果を変えうる PreEnqueue プラグインによって拒否された場合、pod が unschedulable pool にスタックする可能性があるバグを修正しました。In-tree でこのバグの条件を満たす唯一のプラグインは DRA プラグインであるため、`DynamicResourceAllocation` フィーチャゲートが有効な場合、DRA を使う pod がこのバグの影響を受けていた可能性があります。([#125527](https://github.com/kubernetes/kubernetes/pull/125527), [@sanposhiho](https://github.com/sanposhiho)) [SIG Scheduling and Testing]
    - :pencil: Pod の更新以外のイベントが起こったときに、PreEnqueue プラグインで拒否された pod について、pod を activeQ/backoffQ に移動するかの判定と移動をおこなう処理がスキップされていました。DRA などのプラグインで、この処理をスキップしないように修正されました。
- Resync 処理中の transforming informer のバグによって発生する、kube-controller-manager とスケジューラの競合状態を、変換関数を冪等にすることで修正しました。([#124352](https://github.com/kubernetes/kubernetes/pull/124352), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery and Scheduling]
    - :pencil: スケジューラではメモリ消費量の削減のために、`.metadata.managedFields` を削除して pod をキャッシュしています。同じことを kube-controller-manager でもおこなっていて、競合していたようです。
- Scheduling gate を設定する際に Pod condition の `lastTransitionTime` が null になる問題を修正しました。([#122636](https://github.com/kubernetes/kubernetes/pull/122636), [@lianghao208](https://github.com/lianghao208)) [SIG Node and Scheduling]
- DaemonSet pod のスケジューリング時のスループットを、QPS が許す限り 300 pods/s に到達できるように修正しました。([#124714](https://github.com/kubernetes/kubernetes/pull/124714), [@sanposhiho](https://github.com/sanposhiho)) [sig/scheduling]
    - :pencil: [#125197](https://github.com/kubernetes/kubernetes/pull/125197) と同じくスループット向上が目的ですが、#125197 のほうが効果があるのでそちらに上書きされました。
- Scheduling gate をもつ pod と、unschedulable pool から再キューイングを引き起こすイベントが多数ある場合のスケジューリングレイテンシを改善しました。([#124618](https://github.com/kubernetes/kubernetes/pull/124618), [@gabesaba](https://github.com/gabesaba)) [SIG Scheduling and Testing]
    - :pencil: Pod の更新以外のイベントが起こったときに、scheduling gate をもつ pod について、pod を activeQ/backoffQ に移動するかの判定と移動をおこなう処理をスキップするようにしました。
- スケジューラーは、PreFilter プラグインによって拒否された pod のスケジューリングをより適切に再試行します。Pod を拒否した PreFilter プラグインに登録されたイベントが考慮されるようになります。([#122251](https://github.com/kubernetes/kubernetes/pull/122251), [@olderTaoist](https://github.com/olderTaoist)) [SIG Scheduling and Testing]
- `SchedulerQueueingHints` フィーチャゲートが有効な場合、スケジューリングキューはスケジューリング中の pod を即座に更新しません。([#125578](https://github.com/kubernetes/kubernetes/pull/125578), [@nayihz](https://github.com/nayihz)) [sig/scheduling]
    - :pencil: キューの中で pod が更新されるのではなく、pod の更新イベントが記録され、pod がスケジュール不可能と判断された場合の再エンキューの判定に使われます。

### Other (Cleanup or Flake)

- Dynamic Resource Allocation (DRA): Pod スケジューリング時に発生する可能性の低い小さな競合状態を修正しました。([#124595](https://github.com/kubernetes/kubernetes/pull/124595), [@pohly](https://github.com/pohly)) [SIG Node, Scheduling and Testing]
- kube-scheduler の `/livez` および `/readz` エンドポイントを公開し、https://kubernetes.io/docs/reference/using-api/health-checks/#api-endpoints-for-health に準拠したヘルスチェックができるようになりました。([#118148](https://github.com/kubernetes/kubernetes/pull/118148), [@linxiulei](https://github.com/linxiulei)) [SIG API Machinery, Scheduling and Testing]
- kube-scheduler の `pod_scheduling_sli_duration_seconds` メトリックのヘルプテキストの誤字を修正しました。([#124221](https://github.com/kubernetes/kubernetes/pull/124221), [@arturhoo](https://github.com/arturhoo)) [SIG Instrumentation, Scheduling and Testing]
- ログ出力を最適化し、pod の情報が冗長に出力されないようにしました。([#124055](https://github.com/kubernetes/kubernetes/pull/124055), [@yangjunmyfm192085](https://github.com/yangjunmyfm192085)) [sig/scheduling]
- スケジューラフレームワーク: PreBind プラグインが `Pending` および `Unschedulable` ステータスコードを返すことを許可しました。([#125360](https://github.com/kubernetes/kubernetes/pull/125360), [@pohly](https://github.com/pohly)) [sig/scheduling]
    - :pencil: DRA プラグインが PreBind プラグインで kube-apiserver にリクエストをし、それが完了するまで `Pending` を返すようです。