0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@ordovicia

Kubernetes 1.37: SIG-Scheduling の変更内容

0
Last updated at Posted at 2026-09-28

Kubernetes 1.37 の CHANGELOG から、SIG-Scheduling に関するところを抜粋して紹介します。 :pencil: は筆者によるコメントです。

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

:pencil: 全体を通して

Kubernetes 1.36 までで導入された Workload / PodGroup API によって workload-aware scheduling (WAS) の概念が導入され、Pod グループの gang scheduling やトポロジ制約 (Node label co-location)、プリエンプション戦略を表現できるようになりました。

1.37 では WAS がさらに進化し、複数の機能追加、パフォーマンス改善、ベータ版への昇格がありました。ここでは、新しい API である CompositePodGroup をハイライトして紹介します。

なお、他の更新も含めて Kubernetes 公式ブログ Kubernetes v1.37: Advancing Workload-Aware Scheduling も詳しくまとまっているので、あわせて参照してください。

CompositePodGroup

1.36 の PodGroup は、複数の Pod を直接束ねるフラットな構成でした。これで十分カバーできるワークロードもありましたが、より複雑で階層的な構造をもつワークロードの要件はうまく表現できませんでした。Kubernetes 1.37 で導入（アルファ版）された CompositePodGroup (KEP-6012: CompositePodGroup API) は複数の PodGroup、あるいは別の CompositePodGroup を子にもつ階層的な構造のワークロードを表現できます。

ユースケースとして、LLM の推論サービスをデプロイすることを考えます。Prefill と decode を分離する構成を取りたいとき、それぞれを独立した Pod グループとして定義しながらも、両グループをまとめて一つのワークロードとして運用したくなります。CompositePodGroup を使うことで、この階層構造を以下のように表現できます。

apiVersion: scheduling.k8s.io/v1beta1
kind: Workload
metadata:
  name: pd-serving
spec:
  compositePodGroupTemplates: # Workload を構成する CompositePodGroup のテンプレート
  - name: serving
    schedulingPolicy:
      gang:
        minGroupCount: 2
    podGroupTemplates:
    - name: prefill
      schedulingPolicy:
        gang:
          minCount: 4
    - name: decode
      schedulingPolicy:
        gang:
          minCount: 8
  # podGroupTemplates: # 一階層で十分な場合はこれまでどおり PodGroup のテンプレートを使う
  # - ...
---
apiVersion: scheduling.k8s.io/v1alpha3
kind: CompositePodGroup
metadata:
  name: pd-serving-root
spec:
  workloadRef: # もととなる Workload を参照
    workloadName: pd-serving
    templateName: serving
  schedulingPolicy:
    gang:
      minGroupCount: 2 # CompositePodGroup をスケジュールさせるために同時に必要な最小の子グループ数
---
apiVersion: scheduling.k8s.io/v1beta1
kind: PodGroup
metadata:
  name: pd-serving-prefill
spec:
  parentCompositePodGroupName: pd-serving-root # 親の CompositePodGroup を参照
  workloadRef: # もととなる Workload を参照
    workloadName: pd-serving
    templateName: prefill
  schedulingPolicy:
    gang:
      minCount: 4 # この Pod グループをスケジュールさせるために同時に必要な最小の Pod 数
---
apiVersion: scheduling.k8s.io/v1beta1
kind: PodGroup
metadata:
  name: pd-serving-decode
spec:
  parentCompositePodGroupName: pd-serving-root
  workloadRef:
    workloadName: pd-serving
    templateName: decode
  schedulingPolicy:
    gang:
      minCount: 8

Workload に対する topology-aware scheduling も進化し、多層的なトポロジ制約を表現しスケジューリング時に考慮されるようになりました。以下のように Workload の階層ごとにトポロジ制約を設定でき、すべての制約が満たされるように配置先を探索します。

apiVersion: scheduling.k8s.io/v1beta1
kind: Workload
metadata: # ...
spec:
  compositePodGroupTemplates:
  - name: serving
    schedulingPolicy: # ...
    schedulingConstraints: # ワークロード全体を同一の zone に収める
      topology:
      - key: topology.kubernetes.io/zone
    podGroupTemplates:
    - name: prefill
      schedulingPolicy: # ...
      schedulingConstraints: # この Pod グループを同一の rack に収める
        topology:
        - key: topology.kubernetes.io/rack
    - name: decode
      schedulingPolicy: # ...
      schedulingConstraints: # この Pod グループを同一の rack に収める
        topology:
        - key: topology.kubernetes.io/rack

Urgent Upgrade Notes

  • 対応必須: 将来の拡張に備え、DisruptionMode の enum フィールドを struct に変更しました。scheduling.k8s.io API グループを v1alpha2 から v1alpha3 に昇格させ、v1alpha2 を完全に削除しました。クラスタをアップデートする前に、kube-apiserver からすべての v1alpha2 オブジェクトを削除してください。(#138572, @dom4ha) [SIG API Machinery, Apps, CLI, Etcd, Node, Scheduling and Testing]
    • :pencil: 以下のような構造になりました。現時点では single も all も、その中にフィールドをもっていません。 
      disruptionMode:
  # いずれか一つのみを指定する
  single: {} # 子要素がそれぞれ独立に disrupt されてよい
  all: {} # 子要素をすべてまとめて disrupt する

API Changes

  • DRADeviceCompatibilityGroups フィーチャゲート（デフォルトで無効）のもとで、DRA デバイスの互換性グループをアルファ段階でサポートしました。DRA ドライバは ResourceSlice の各 device.consumesCounters[] エントリに不透明な compatibilityGroups を宣言できます。スケジューラは、同じ counter set を消費するデバイスの互換性グループが共通部分をもつ場合にのみ、これらを同時に割り当てます。これにより、互換性のない同時割り当てが、準備時の失敗ではなくスケジューリング時の拒否として検出されるようになります。(#139795, @omeryahud) [SIG API Machinery, Node, Scheduling and Testing]
  • Building block API と workloadbuilder ライブラリで CompositePodGroup をサポートしました。(#140717, @helayoty) [SIG API Machinery, Apps, Auth, Scheduling and Testing]
  • Job コントローラを workloadbuilder ライブラリおよび Workload building block API と統合することで、workload-aware scheduling（WAS）をサポートしました。(#140188, @helayoty) [SIG API Machinery, Apps, Auth, Network, Node, Scheduling, Storage and Testing]
  • PodGroup に PreemptionPolicy フィールドを追加し、workload-aware preemption の際 kube-scheduler が PodGroup に属する Pod をどうプリエンプトするか制御できるようになりました。(#139240, @ania-borowiec) [SIG Scheduling]
    • :pencil: おそらく changelog の意味が逆になっています。PodGroup が「どうプリエンプトされるか」ではなく、PodGroup が他のワークロードを「どうプリエンプトできるか」を制御できるようになったということだと思われます。Pod と同様に PreemptLowerPriority と Never の選択肢があり、優先度が高い PodGroup でも他のワークロードをプリエンプトしないようできます。
  • InPlacePodVerticalScalingSchedulerPreemption フィーチャゲート（アルファ）が有効な場合に、優先度の高い Pod の Deferred 状態の in-place Pod resize に必要な空きを作るため、スケジューラが優先度の低い Pod をプリエンプトできるようにしました。(#140000, @natasha41575) [SIG API Machinery, Apps, Node, Scheduling, Storage and Testing]
  • scheduling.k8s.io/v1alpha3 に CompositePodGroup API を追加しました。(#139596, @jdzikowski) [SIG API Machinery, Apps, Auth, Etcd, Node, Scheduling and Testing]
  • CompositePodGroup の workload-aware preemption に対応するため、Workload API と CompositePodGroup API に DisruptionMode フィールドと PreemptionPolicy フィールドを追加しました。(#140634, @tosi3k) [SIG API Machinery, Auth, Etcd, Node, Scheduling and Testing]
  • スケジューリングフレームワークに PodGroupPostFilter 拡張点を追加し、WorkloadAwarePreemption 用の内部的なハードコーディングを、PodGroup 向けのカスタマイズ可能な拡張点に置き換えました。(#139674, @GFilipek) [SIG Scheduling and Testing]
    • :pencil: PodGroup 向けの拡張点です。Pod 単体のプリエンプション処理をおこなう PostFilter と似ていますが、PodGroupPostFilter は Pod グループ全体の配置ができなかったときの処理をプラグインでカスタマイズできます。
  • Workload-aware preemption のポリシーを定義できるよう、PodGroupTemplate に PreemptionPolicy フィールドを追加しました。(#140312, @ania-borowiec) [SIG API Machinery, Apps, Scheduling and Testing]
  • SchedulerPreQueueingHints フィーチャゲート（アルファ段階、デフォルトで無効）を追加しました。有効にすると、スケジューラプラグインが PreQueueingHintFn を提供し、クラスタイベントの発生時に評価する Pod を絞り込めるため、スケジューリングのスループットが向上します。DRA プラグインはこれを ResourceClaimTemplate を使うワークロードの最適化に利用します。(#138916, @geetasg) [SIG API Machinery, Apps, Architecture, Auth, CLI, Cloud Provider, Instrumentation, Network, Node, Scheduling, Storage, Testing and Windows]
    • :pencil: Queueing hint 機能は、クラスタで特定のイベントが起こったときに、以前スケジュール不能と評価されていた Pod を再試行できます。QueueingHintFn は与えられた Pod を再試行するかどうかを判定する関数ですが、PreQueueingHintFn はそもそもどの Pod を判定にかけるかを判定するという、二段階の絞り込みになっています。この変更では、DRA 関連で性能改善のためより綿密な絞り込みをするために PreQueueingHintFn 拡張点を導入しました。
  • DRA Device Taints and Tolerations 機能が GA に昇格し、resource.k8s.io/v1 API で利用できるようになりました。(#138676, @pohly) [SIG API Machinery, Apps, Architecture, Auth, Etcd, Node, Scheduling, Storage and Testing]
  • Workload-aware scheduling（WAS）の中核となる Workload API と PodGroup API を scheduling.k8s.io/v1beta1 に昇格させました。kube-apiserver を v1.36 から v1.37 へアップグレードする前に、すべての v1alpha2 オブジェクトを削除してください。(#140184, @tosi3k) [SIG API Machinery, Apps, Auth, Etcd, Node, Scheduling and Testing]
  • GangScheduling と WorkloadAwarePreemption フィーチャゲートが削除されました。中核となる workload-aware scheduling 機能を有効にするには、GenericWorkload フィーチャゲートを使います。(#139520, @macsko) [SIG API Machinery, Node, Scheduling and Testing]
    • :pencil: Workload / PodGroup API, gang scheduling, workload-aware preemption は互いに依存しており、個別に有効にしても実用的ではありません。そのため、これらの機能を一つのフィーチャゲートにまとめました。
  • PodGroup の condition 名が PodGroupScheduled から PodGroupInitiallyScheduled に変更されました。この condition は PodGroup が最初に正常にスケジューリングされたときにのみ設定され、現在のスケジューリング状態を表すとは限らないことが明確になりました。(#139743, @antekjb) [SIG API Machinery, Scheduling and Testing]
    • :pencil: この condition は PodGroup が最初に必要数の Pod を配置できた時点で True になり、その後グループの Pod が消えたり作られたりしても False に更新されることはありません。なお、単体の Pod はノードに割り当てられてから割り当てられない状態になることはない（それはその Pod が消されたことを意味するため）ので、PodScheduled condition に "Initially" は付いていません。
  • PodGroup と PodGroupTemplate について、作成後に minCount が変更できるようになりました。PodGroupTemplate の変更は、既存の PodGroup には影響しません。(#139279, @antekjb) [SIG API Machinery, Scheduling and Testing]
  • PodGroup API の PodGroupTemplateRef フィールドを、PodGroup が属する Workload をより簡潔かつ直接的に参照できる WorkloadRef に置き換えました。(#140080, @dom4ha) [SIG API Machinery, Apps, Etcd, Node, Scheduling and Testing]
    • :pencil: CompositePodGroup のフィールドと同じ名前に揃える意味もあります。

Feature

  • PodGroupManager と SharedLister に PodGroup のメソッドを追加し、スケジューラプラグインが一貫した PodGroup の状態を取得できるようにしました。(#140077, @macsko) [SIG Node, Scheduling and Testing]
  • TopologyAwareWorkloadScheduling フィーチャゲートが有効な場合に利用できる、topology-aware scheduling (TAS) の配置フェーズを観測するメトリクス scheduler_generated_placements_total, scheduler_placement_evaluations_total, scheduler_placement_evaluation_duration_seconds を追加しました。(#139604, @alimaazamat) [SIG Instrumentation, Scheduling and Testing]
  • 単体（PodGroup に属さない）Pod と、disruption mode が single または all の PodGroup について、プリエンプションの動作を比較するためのスケジューラパフォーマンスのベンチマークスイートを追加しました。また、デフォルトのプリエンプション性能テストを専用ディレクトリに整理しました。(#140651, @vshkrabkov) [SIG Scheduling and Testing]
  • Composite Pod Group 機能を有効にする CompositePodGroup フィーチャゲートを追加しました。(#139407, @jdzikowski) [SIG Scheduling]
  • スケジューリングサイクル全体でプラグインが一貫した状態を取得できるよう、kube-scheduler の PodGroupInfo オブジェクトに PodGroup フィールドを追加しました。(#140075, @macsko) [SIG Scheduling]
  • kube-scheduler に client-go informer のメトリクス informer_store_resource_version, informer_queued_items, informer_processing_latency_seconds を追加しました。ラベルは name="kube-scheduler" です。(#140511, @Jefftree) [SIG Scheduling and Testing]
  • PodGroup オブジェクトが kube-scheduler に認識されるのを待つ Pod を保存するため、スケジューリングキューに incompletePodGroupPods データ構造を追加しました。(#139952, @macsko) [SIG Node, Scheduling and Testing]
  • DRAWorkloadResourceClaims フィーチャゲートのもとで、dynamic_resource_allocation_resourceclaim_creates_total メトリックに owner_api_group と owner_api_kind ラベルを追加しました。Pod 用と PodGroup 用に作成された ResourceClaim を区別できるようになります。(#140422, @nojnhuh) [SIG API Machinery, Apps, Instrumentation, Node, Scheduling and Testing]
  • スケジューラのメトリクス queued_entities と queue_incoming_entities_total を追加しました。queued_entities はスケジューラのキュー内に現在あるスケジューリング対象（Pod または PodGroup）の数を、queue_incoming_entities_total はキューに追加された対象の累計数を示します。(#139840, @iomarsayed) [SIG Instrumentation, Network and Scheduling]
  • PodGroup のスケジューリングサイクルを早期に終了できるよう、スケジューリングフレームワークに PlacementFeasible 拡張点を追加しました。GangScheduling プラグインはこれを、minCount を満たせなくなった時点で Pod の評価を止めるために利用します。(#138643, @brejman) [SIG Scheduling and Testing]
    • :pencil: 例えば minCount: 8 の PodGroup で、配置できた Pod が1つ、未評価の Pod が6つしか残っていなければ、残りをすべて配置しても条件を満たせません。従来はそれでも残りの Pod の配置を試していたため、大きな PodGroup ほど無駄な評価が増えました。PlacementFeasible はスケジューリングサイクルを早期リターンするために使えます。なお、この拡張点は内部向けインターフェイスであり、外部から設定できるものではありません。
  • PodGroupPreemptionPolicy フィーチャゲートが有効な場合に、PodGroup に属するすべての Pod のプリエンプションポリシーが一致することを確認する検証を PodGroup のスケジューリングに追加しました。(#140359, @ania-borowiec) [SIG Scheduling and Testing]
  • 評価対象の Pod の優先度が PodGroup の優先度と一致することを確認する検証を、PodGroup のスケジューリングに追加しました。(#139920, @brejman) [SIG Scheduling and Testing]
  • WorkloadAwarePreemption フィーチャゲートのもとで、ワークロードのプリエンプションに関するメトリクスをアルファ段階で追加しました。(#139373, @brejman) [SIG Instrumentation and Scheduling]
  • スケジューリング制約を持つ PodGroup では、PodGroup のスケジューリング試行が失敗した後にプリエンプションを実行するよう変更しました。(#140683, @Argh4k) [SIG API Machinery, Scheduling and Testing]
  • スケジューリングフレームワークの PatchPodStatus API が、単一の Pod condition (*v1.PodCondition) ではなく、Pod condition のスライス ([]*v1.PodCondition) を受け取るよう変更されました。これにより、プラグインは1回の API 呼び出しで複数の Pod condition を更新でき、並行して condition を更新する際に後続の呼び出しが先行する更新を上書きすることを防ぎます。(#135160, @KunWuLuan) [SIG Scheduling]
  • リリース直前に問題が見つかったため、SchedulerPreQueueingHints フィーチャゲートをベータからアルファ（デフォルトで無効）に戻しました。(#140959, @sanposhiho) [SIG Scheduling]
  • Pod 単位のプリエンプションを拡張し、PodGroup もプリエンプション対象にできるようにしました。(#137981, @vshkrabkov) [SIG Scheduling and Testing]
    • :pencil: Kubernetes 1.36 時点では、PodGroup が preemptor になることはできましたが、PodGroup が victim となるときはそれに属する Pod が独立に処理されていました。この変更により、disruption mode に応じて PodGroup 全体が一つの victim として扱えるようになりました。
  • PodGroup のプリエンプションエラーの先頭に、pod group preemption: というメッセージが付くようになりました。(#139218, @Argh4k) [SIG Scheduling]
  • scheduler_plugin_execution_duration_seconds と scheduler_scheduling_algorithm_duration_seconds のメトリクスをアルファからベータに昇格させました。(#138176, @abhay1999) [SIG Instrumentation, Scheduling and Testing]
    • :pencil: 前者は各拡張点でプラグインが費やした時間、後者は配置先ノードを選ぶアルゴリズムの所要時間を計測するメトリクスです。
  • InterPodAffinityHostnameFastPath フィーチャゲートのもとで、topologyKey: kubernetes.io/hostname を指定した必須の Pod アフィニティとアンチアフィニティのスケジューリング性能を改善しました。(#138198, @tetianakh) [SIG Apps, Node, Scheduling and Testing]
  • PersistentVolumeClaim をマウントする Pod について、スケジューリングサイクル間の差分数だけを処理することで kube-scheduler の性能を最適化しました。(#139238, @yue9944882) [SIG Scheduling and Testing]
  • PodGroup のプリエンプションが成功した後、その Pod に nominatedNodeName フィールドを設定するようにしました。単一 Pod のプリエンプションと同じ動作です。(#138967, @antekjb) [SIG Scheduling and Testing]
  • PodGroup のスケジューリング時、nominated node に終了処理中のプリエンプション対象 Pod がすでにいる場合は、スケジューラが不要なプリエンプションの再試行を避けるようにしました。(#138710, @mm4tt) [SIG Scheduling]
  • Pod リソースのクラスタイベントに、AssignedPod, UnscheduledPod, TargetPod の3つのサブタイプを追加しました。性能向上のため、プラグインは対象を絞った Pod イベントに登録でき、また期待されます。(#135905, @iomarsayed) [SIG Node, Scheduling, Storage and Testing]
  • PodGroup のスケジューリング成功後、未スケジューリングの残りの Pod を backoff queue ではなく active queue へ直接戻すようにしました。元のタイムスタンプが保たれるため、より優先度の高いスケジューリング対象が追加されない限り、スケジューリングの順番が維持されます。(#139613, @iomarsayed) [SIG Scheduling and Testing]
    • :pencil: Gang の minCount を満たして PodGroup のスケジューリングが成立すると、その個数の Pod は binding に進みますが、グループの Pod がそれより多ければ未配置の Pod が残ります。それらを active queue に戻して次のスケジューリングサイクルですぐ処理することで、グループ内で連続したスケジューリングができるようになります。
  • PodGroup のスケジューリングサイクルで、Pod について PostFilter プラグインを実行しないようにしました。代わりに、PodGroup 全体がスケジューリング不能になった場合にのみ PodGroupPostFilter を実行します。(#140412, @Argh4k) [SIG Scheduling and Testing]
  • Workload-aware preemption で配置先が見つかったとき、PodGroup のステータスに pod group preemption found a placement for podgroup, preempting <victim_count> victims というメッセージを含めるようにしました。(#140311, @Argh4k) [SIG Scheduling and Testing]
  • Pod の配置候補となるノードが見つかったとき、デフォルトプリエンプションが FailedScheduling イベントと PodScheduled condition に preemption: found a potential placement for pod on node <node_name>, preempting <victim_count> victims というメッセージを含めるようにしました。(#140180, @Argh4k) [SIG Scheduling]
  • Workload-aware preemption で、プリエンプション対象となり得る Pod をすべて取り除いた状態で、スケジューリングを1回だけ試行するようにしました。スケジューリング性能は大きく向上しますが、プリエンプション対象の選択が最適ではなくなる場合があります。(#139980, @Argh4k) [SIG Scheduling and Testing]
  • Workload-aware preemption で、preemptor Pod をできるだけ多くスケジューリングできるよう victim を選ぶようにしました。(#138757, @jdzikowski) [SIG Scheduling and Testing]
  • kube-scheduler: TopologyAwareWorkloadScheduling フィーチャゲート（アルファ段階）のもとで、配置ごとの状態を PlacementScore プラグインへ渡す PlacementCycleState をスケジューリングフレームワークに追加しました。(#138274, @wtravO) [SIG Scheduling]
  • kube-scheduler: スケジューリングキューで PodGroup をサポートしました。Active, backoff, unschedulable queue を抽象化し、個別の Pod と PodGroup の両方を扱う QueuedEntityInfo を格納するようにしました。(#138567, @macsko) [SIG Instrumentation, Scheduling and Testing]

Failing Test

  • Scheduling gate が設定された Pod の nominated node 上の領域に、優先度の低い Pod がスケジューリングされてしまうバグを修正しました。(#139057, @macsko) [SIG Scheduling]

Bug or Regression

  • DRA: ResourceClaim の informer 更新がまれに見落とされた場合、unschedulable queue がフラッシュされるまで Pod が Pending のままになるバグを修正しました。(#140831, @pohly) [SIG Node and Scheduling]
  • DRA consumable capacity に関するスケジューリングのバグを修正しました。共有カウンタを消費するデバイスに、消費する容量がない共有割り当てがすでに保存されていると、そのカウンタが二重計上されることがありました。その結果、同じデバイスに対する後続のクレームが誤って拒否され、Pod が Pending のままになっていました。(#140437, @thc1006) [SIG Node and Scheduling]
  • ImageLocality のスコアリングで、image volume が同等の通常のコンテナイメージより高いスコアを得ることがあるバグを修正しました。(#138951, @sujoshua) [SIG Scheduling]
  • ResourceClaim を共有する PodGroup 内の Pod が、スケジューリング途中で止まるバグを修正しました。(#140269, @nojnhuh) [SIG Node, Scheduling and Testing]
  • GenericWorkload フィーチャゲートが有効な場合に起こる、同じ ResourceClaim を共有する同一 PodGroup 内の Pod が正常にスケジューリングされないことがあるバグを修正しました。(#139418, @nojnhuh) [SIG Node and Scheduling]
  • ResourceClaim を共有する PodGroup 内の Pod が、その ResourceClaim を利用できないノードへスケジューリングされるバグを修正しました。(#140089, @nojnhuh) [SIG Node, Scheduling and Testing]
  • 複数ノードにまたがる ResourceClaim とノードごとの ResourceClaim を併用する Pod が、Pending のままになることがあるバグを修正しました。(#139017, @johnbelamaric) [SIG Node and Scheduling]
  • スケジューリングに成功した Pod に PodScheduled=False condition が残ることがあるバグを修正しました。(#139602, @nojnhuh) [SIG Node and Scheduling]
  • PodGroup のスケジューリングサイクルが失敗した際、その中で評価に成功した Pod の nominatedNodeName に、PodGroup のプリエンプションではなく、その評価で得られた値が設定される問題を修正しました。(#140590, @Argh4k) [SIG Scheduling]
  • スケジューリング失敗を処理する handleSchedulingFailure で、マップの読み書きが並行して発生するデータ競合を修正しました。(#140623, @SparshGarg999) [SIG Scheduling]
  • スケジューラの PriorityQueue で発生するメトリクスのリークを修正しました。Pod が active queue または backoff queue から削除された際に UnschedulableReason メトリクスを減らし、スケジューリング不能の原因となったプラグインを正確に報告します。(#138482, @vshkrabkov) [SIG Scheduling]
  • Preemptor Pod がスケジューリング不能な状態のままになることがある競合状態を修正しました。(#139162, @brejman) [SIG Scheduling and Testing]
  • NominatedNodeName をクリアすると、スケジューラの nominator が空のノードキーの下で Pod を追跡したままになることがあるバグを修正しました。(#139904, @pacoxu) [SIG Scheduling]
  • Deletion timestamp を受け取った後、assume 済みの Pod が PodGroupState から正しく削除されないスケジューラキャッシュのバグを修正しました。(#138445, @iomarsayed) [SIG Scheduling]
  • PodGroup のプリエンプションで進行中のプリエンプションを検出すると、その PodGroup の Pod から nominatedNodeName が消される問題を修正しました。(#140641, @Argh4k) [SIG Scheduling and Testing]
  • PodGroup のスケジューリングサイクル中に kube-scheduler がおこなう Pod 間アフィニティ、アンチアフィニティ、ボリューム制約の評価を修正しました。スケジューラのスナップショットの AssumePod と ForgetPod が、アフィニティノードのリストと PVC の使用状況を正しく維持します。(#139054, @net0pyr) [SIG Scheduling and Testing]
  • Pod 間アンチアフィニティに複数の条件がある場合の queueing hint を修正しました。スケジューリングの遅延につながることがありました。(#139161, @brejman) [SIG Scheduling]
  • PodGroupPostFilter からのエラーメッセージに、正しい拡張点名が含まれるよう修正しました。(#140747, @Argh4k) [SIG Scheduling]
  • Opportunistic batching と PodGroup の不整合により、PodGroup のスケジューリングサイクル中にバッチングヒントが常に実行不可能と判定される問題を修正しました。(#138754, @macsko) [SIG Scheduling]
    • :pencil: KEP-5598: Opportunistic batching は、Pod スケジューリング時にノードのスコアリング結果をキャッシュし、この Pod と同一のスケジューリング要件 (scheduling signature) をもつ Pod で再利用することで、スケジューリング処理の効率化を図る機能です。PodGroup のスケジューリングサイクルでは所属する Pod が同じサイクルを共有するため、従来はヒントが常に実行不可能と判定されていました。同一 PodGroup の Pod 間でバッチ結果を再利用できるようにし、opportunistic batching がグループにもはたらくようにしました。
  • 大規模な PodGroup の処理を改善し、所属する Pod のノードへのバインドが一時的に失敗した際にスケジューリングが停滞する可能性を下げました。多くの Pod が同じ ResourceClaim を共有する場合などが該当します。(#140478, @nojnhuh) [SIG Scheduling]
  • PodGroup が既存の Workload を参照し、定義された PodGroupTemplate と一致することを検証していたアドミッションプラグイン（アルファ）を削除しました。(#139008, @wojtek-t) [SIG API Machinery, Etcd, Scheduling and Testing]
  • グループ内の Pod 間で .spec.schedulerName が一致せずスケジューリングが拒否された場合、失敗理由が PodGroup の status.conditions フィールドに反映されるようにしました。(#140183, @Argh4k) [SIG Scheduling]
  • pods/binding サブリソースのエンドポイントで、指定されたノード名を一貫して検証するようにしました。(#136776, @yakir-shriker) [SIG Apps and Scheduling]
    • :pencil: カスタムスケジューラで pods/binding API を呼ぶとき、これまでは大文字を含むような不正なノード名でもバインドが受理され spec.nodeName に記録されていました。この Pod が finalizer をもつとき、削除するために finalizer を消す更新操作をしようとすると今度は spec.nodeName の形式が検証されて失敗するため、Pod を削除できなくなる事例がありました。対策として、バインド時点でも一貫してノード名の形式を検証します。

Other (Cleanup or Flake)

  • スケジューラの opportunistic batching で、直前に選んだノードがまだ配置可能なら、次のヒントに対して再度スコアリングするようにしました。キャッシュされた候補と比較できるようになり、常にスキップされることがなくなります。(#140289, @romanbaron) [SIG API Machinery, Etcd, Instrumentation, Scheduling and Testing]
    • :pencil: Opportunistic batching はこれまで、すでに選んだノードにまだ空きがあってもバッチの候補から除いていたため、複数の Pod を同じノードに置けるワークロードで最適化がはたらきにくくなっていました。今回の変更ではそのノードを現在の Pod に対して再度スコアリングし、キャッシュされた他の候補ノードと比較します。
  • PodGroup、CompositePodGroup、PodCertificateRequest のフィールド所有権を追跡する際、Server-Side Apply がステータスの変更を正しく除外するよう修正しました。(#140654, @jpbetz) [SIG API Machinery, Auth, Scheduling and Testing]
  • PodGroup に属する Pod が参照する ResourceClaimTemplate から、ResourceClaim コントローラが ResourceClaim を作成するのは、DRAWorkloadResourceClaims フィーチャゲートが有効な場合だけにしました。PodGroup 向けに作られるべき ResourceClaim が、個別の Pod 向けに作られることを防ぎます。(#138363, @nojnhuh) [SIG API Machinery, Apps, Node, Scheduling and Testing]
  • kube-controller-manager と kube-scheduler の両方が、作成した ResourceClaim の数を示す dynamic_resource_allocation_resourceclaim_creates_total メトリクスを公開し、それぞれで異なっていたメトリクス名を置き換えました。kube-controller-manager の resource_claims メトリックも同じ dynamic_resource_allocation サブシステムへ移動しました。(#138542, @pohly) [SIG Apps, Instrumentation, Node, Release, Scheduling and Testing]
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?