Kubernetes v1.32、QueueingHintを有効化しPodスケジューリングのスループットを最適化

2024年12月のKubernetes Blogへの投稿で、Tetrate.ioのKensei Nakada氏は、バージョン1.32で導入されたKubernetesスケジューラの重要な内部改善について詳述しました。このアップデートは、スケジュール不能なPodの再試行タイミングを知的に管理することで、スケジューラへの不要な処理負荷を軽減するよう設計されたQueueingHintメカニズムを安定化させ、デフォルトで有効にします。

何が起きたか

Kubernetesスケジューラは、クラスター内のノードに新しいPodを割り当てる役割を担っています。Podを順次処理するため、クラスターが大きくなるにつれて、スケジューラのスループットが重要なパフォーマンスボトルネックとなります。過去数年間、Kubernetes SIG Schedulingグループは、このスループットを向上させるためにさまざまな強化策を実施してきました。最新の主要な改善であるQueueingHintというスケジューリングコンテキスト要素は、Kubernetes v1.32に含まれています。

このリリース以前は、スケジューラは3つの内部データ構造を使用して未スケジュールのPodを管理していました。新規または再試行準備ができているPod用のActiveQ、失敗後にバックオフ期間を待っているPod用のBackoffQ、そして現在スケジュールできないPod用のUnschedulable Pod Poolです。Podがスケジューリングサイクルで失敗すると、通常はUnschedulable Pod Poolに移動します。スケジューラは、スケジューリング失敗を解決する可能性のある特定のクラスター変更が発生した場合のみ、これらのPodをActiveQまたはBackoffQに戻します。

従来、失敗を解決できるクラスターイベントを決定するロジックは広範であり、しばしば非効率でした。プラグインは、EnqueueExtensionsを通じて、オブジェクトの作成や削除などの一般的なクラスターイベントを登録していました。登録されたイベントが発生すると、そのイベントが前回の失敗の具体的な理由と無関係であっても、スケジューラはPodを再試行していました。さらに、preCheckという内部機能はコア制約に基づいてイベントをフィルタリングしようとしましたが、カスタムプラグインへの拡張性がなく、精度も欠けていました。

仕組み

QueueingHintは、各プラグインが特定のクラスターイベントを購読し、受信したイベントが実際に特定のPodをスケジュール可能にするかどうかについて細かな判断を下すことを可能にすることで、この再試行メカニズムを改良します。登録されたイベントが発生するたびにPodを広範囲に再試行する代わりに、スケジューラは関連するプラグインに対して、その特定の変更が重要かどうかを尋ねます。

例えば、特定のPodアフィニティを必要とするpod-aという名前のPodを考えてみます。既存のノードに一致するPodがないためInterPodAffinityプラグインによってpod-aが拒否されると、pod-aはUnschedulable Pod Poolに入ります。スケジューラは、InterPodAffinityが拒否の原因であることを記録します。QueueingHintを使用すると、InterPodAffinityプラグインはPodラベルの更新を購読します。実行中のPodが、pod-aのアフィニティ要件と一致するようになったラベル更新を受け取った場合、プラグインのQueueingHintコールバックがこの一致を検出し、スケジューラにpod-aをActiveQまたはBackoffQに戻すよう促します。ラベル更新が一致しない場合、Podはプールに残り、スケジューリングサイクルを節約します。

この機能はKubernetes v1.28以来開発されてきました。当初はデフォルトで有効でしたが、報告されたメモリリークのためパッチリリースで無効化されました。v1.28からv1.31の間で、コントリビューターはメモリリークを修正し、すべてのin-treeプラグインでQueueingHintsを実装しました。v1.32では、実装が完了し安定性の問題が解決されたため、この機能は再びデフォルトで有効になっています。

主な詳細

• バージョン: QueueingHint機能はKubernetes v1.32でデフォルトで有効になります。
• メカニズム: QueueingHintにより、プラグインは特定のクラスターイベントを評価し、スケジュール不能なPodを再試行すべきかどうかを判断できます。
• 以前の課題: 従来の方法では広範なイベント登録が使用されており、スケジュール不能なままのPodに対する不要なスケジューリング再試行が発生していました。
• 拡張性: 古いpreCheck機能とは異なり、QueueingHintは拡張可能でカスタムプラグインでも動作し、issue #110175に対応しています。
• 歴史: この機能はv1.28で実験的に導入され、メモリリークのため無効化され、後続のバージョンで安定化されました。
• コンポーネント: この最適化はスケジューリングキュー、特にUnschedulable Pod PoolとActiveQ/BackoffQ間のPodの移動を対象としています。

なぜ重要なのか

大規模なKubernetesクラスターを管理するエンジニアにとって、スケジューラのスループットはアプリケーションのデプロイ速度とリソース利用率に直接影響します。スケジューラがスケジュールされる見込みのないPodの配置を試みるたびに、CPUサイクルを消費し、他の保留中のPodの処理に遅延を追加します。これらの無駄な再試行を排除することで、QueueingHintはコントロールプレーンの計算オーバーヘッドを削減します。

この最適化は、広範なPodアフィニティやアンチアフィニティルールを使用するなど、複雑なスケジューリング要件を持つクラスターで特に価値があります。そのような環境では、Podが頻繁にUnschedulable Pod Poolに入ります。精密な再試行ロジックがない場合、スケジューラは無関係なクラスター変更のためにこれらのPodを繰り返し起動し、ノイズを生じさせ、実行可能なPodのスケジューリングを遅らせる可能性があります。QueueingHintは、意味のある変更のみが再試行を引き起こすようにし、スケジューリングパイプラインを効率的に保ちます。

さらに、QueueingHintの拡張性は、カスタムスケジューリングプラグインを作成する開発者にとって有益です。以前は、カスタムプラグインはpreCheckによる効率的なフィルタリングを活用できず、より広範で非効率なイベントトリガーに頼らざるを得ませんでした。現在では、カスタムプラグイン独自のQueueingHintロジックを実装でき、スケジューラの最適化された再試行メカニズムとシームレスに統合することができます。これにより、標準およびカスタムのスケジューリングワークフロー全体で一貫したパフォーマンスが実現されます。

やれること

• テストクラスターをKubernetes v1.32にアップグレードし、安定化したQueueingHintの挙動を観察してください。
• カスタムスケジューリングプラグインを見直し、精密なイベント処理のためにQueueingHintコールバックを実装していることを確認してください。
• スケジューラメトリクスを監視し、高負荷シナリオでの再試行率の低下とスループットの向上を確認してください。
• 実験的なv1.28実装で問題を経験した場合は、残存するメモリ使用パターンをチェックしてください。
• カスタムプラグインでのQueueingHint実装に関する詳細なガイダンスについては、Kubernetes SIG Schedulingドキュメントを参照してください。
• アップグレード前後のクラスターパフォーマンスを評価し、不要なスケジューリングサイクルの削減を定量化してください。