プロンプト
Kubernetes v1.35では、Scheduling Groupがアルファ機能としてドキュメント化されています。相互に依存するワーカーが、少なくともminCount個のPodを一緒に配置できる場合にのみ開始するバッチプラットフォームを設計してください。PodGroup、スケジューラ、コントローラ、オートスケーリング、障害処理がどのように連携するかを説明してください。バージョンとフィーチャーゲートの前提条件も明記してください。
面接官が見ているポイント
中核となるテストは、API、スケジューリング、およびランタイムの状態の整合性を保ちながら、スケジューリングの実行可能性の判断を単一のPodからグループ全体へと引き上げられるかどうかです。優れた回答では、basicとgangを明確に区別し、PodGroupの欠落、キャパシティ不足、メンバーの障害、プリエンプション、可観測性を適切に処理し、アルファ版APIを無条件に本番環境対応として提示することを避けます。
前提条件の確認事項
- すべてのワーカーが同時に起動する必要がありますか、それともより低い同時実行数のしきい値で十分ですか？
- メンバーは1回限りのJobですか、それとも長時間実行されるサービスですか？
- GPU、トポロジー制約、またはクラスタ間配置は必要ですか？ドキュメントに記載されているリファレンスは、同一ネームスペース内のPodGroupです。
- 待機デッドライン（制限時間）はどのくらいですか？また、ジョブのキューイング、キャパシティの借用、またはダウングレードは許可されますか？
30秒フレームワーク
まずは境界条件から始めます。Scheduling GroupおよびPodGroupポリシーはv1.35ではアルファ版であり、デフォルトで無効になっており、GenericWorkloadフィーチャーゲートが必要です。次に、4つのレイヤーを説明します：APIコントラクト、グループスケジューリング、ライフサイクル、および運用です。WorkloadがPodGroupを作成し、Podがそれを参照し、スケジューラがポリシーとminCountを適用し、コントローラがタイムアウト、リトライ、クリーンアップを管轄し、メトリクスとロールバックによってロールアウトを保護します。
ステップバイステップ設計
1. モデルと不変条件
コントローラは、実行ごとに希望するメンバー、ポリシー、バージョン、テナントを指定して1つのPodGroupを作成します。各Podは、同一ネームスペース内のPodGroupを指すようにspec.schedulingGroup.podGroupNameを設定します。このフィールドはイミュータブル（不変）であるため、Podを移動することは新しいセットを作成することを意味します。ギャングの場合、minCountの不変条件が満たされるまで、どのメンバーもバインドされません。
2. ポリシーの選択
メンバーが独立して実行でき、グループ化が主に管理や可観測性を目的としている場合はbasicを使用します。密結合したトレーニングやバッチ処理にはgangを使用します。このグループは、少なくともminCount個のメンバーを同時にスケジュールできる場合にのみ実行可能となります。minCountを合計より少なく設定すると弾力性が得られ、合計と同じ値に設定するとすべてのメンバーが必要になります。
3. 送信と待機状態のステートマシン
参照を正しく解決できるように、Podを作成する前にPodGroupを作成します。参照されたオブジェクトが存在しない場合、PodはPending状態のままとなり、グループが表示された後にスケジューラが再試行します。PendingGroup、WaitingCapacity、Feasible、Bound、Running、Failed、Cancelledなどの状態を追跡し、それぞれにジェネレーション、理由、タイムスタンプを付与します。
4. スケジューリングとキャパシティの調整
スケジューラはまず、フィルタ、トポロジー、デバイス、優先度を使用して候補ノードを評価し、次にグループの実行可能性をチェックします。バインド操作はリトライ可能でべき等でなければならず、候補数がminCountに達した後にのみ実行されます。オートスケーラーは、最初のPodのためだけに容量を追加するのではなく、グループのリソース形状を把握し、リクエスト全体に対してスケールする必要があります。
5. プリエンプション、デッドライン、および公平性
プリエンプションによって使用不能な中途半端なグループが残らないように、グループに一貫した優先度とキューの重みを与えます。デッドラインに達した場合はグループをキャンセルして予約を解放します。古いメンバーが再参加できないように、再試行には新しいジェネレーションを使用します。テナントクォータ、最大グループサイズ、キューのエージングにより、大規模なギャングがクラスタを独占するのを防ぎます。
6. メンバーの障害とロールバック
起動後、クラッシュしたメンバーをグループが現在正常である証拠として扱ってはなりません。ジョブのセマンティクスに応じて、1つのメンバーを再起動するか、グループを終了します。トレーニングジョブでは通常、チェックポイントを復元して新しいジェネレーションを作成します。Workloadを削除すると、監査用のターミナルイベントを保持しながら、所有するPodとPodGroupをクリーンアップする必要があります。
7. 可観測性と安全境界
グループのキューレイテンシ、実行可能メンバー数、minCount、スケールアップおよびプリエンプションの回数、障害理由を公開します。アドミッションWebhookでネームスペース、クォータ、グループサイズ、フィーチャーゲートの可用性を検証します。APIはアルファ版であるため、明示的なロールアウトスイッチ、互換性テスト、および迅速なロールバックパスを用意します。
優れた回答例
「私はWorkloadコントローラに、ギャングポリシーと進行に必要な最小ワーカー数に等しいminCountを指定して、同一ネームスペース内にPodGroupを作成させます。PodはイミュータブルなschedulingGroupフィールドを介してそれを参照します。コントローラが最初にグループを作成するため、未解決の参照はPending状態を維持します。スケジューラはすべてのメンバーのリソース、トポロジー、優先度を評価し、実行可能な数がminCountに達した場合にのみバインドします。オートスケーラーはグループのリソース形状からスケールします。デッドラインによりグループ全体がキャンセルされてキャパシティが解放され、失敗したトレーニング実行はチェックポイントから復元された新しいジェネレーションを取得します。デプロイメントマニフェストにはv1.35 alphaとGenericWorkloadが明示的に記録され、ロールアウトは隔離されたクラスタから開始されます。」
よくある失敗例
- メンバーが個別にスケジュールできるにもかかわらず、
basicをAll-or-Nothingと呼んでしまう。 - 同一ネームスペースのPodGroup参照やイミュータブルなフィールドを説明せず、ラベルのみを使用する。
- グループの欠落、スケールアップ、デッドライン、プリエンプション、リトライジェネレーションを無視する。
- アルファステータスおよび
GenericWorkloadフィーチャーゲートについて触れない。 - グループレベルのキャンセルやメトリクスを考慮せずに、バインドの成功のみを議論する。
フォローアップの方向性
Podの後にPodGroupが作成された場合はどうなりますか？
PodはPending状態のままであり、PodGroupが作成された後にスケジューラによって再評価されます。このタイムラグを短縮するために、コントローラはグループを最初に作成する必要があります。
minCountはどのように選択しますか？
アプリケーションの有用な最小並行度、Podごとのリソース、許容されるキュー待機時間を使用し、クォータと上限を設定します。
ギャングの枯渇（スターベーション）をどのように防ぎますか？
グループの待機時間を監視しながら、フェアキューイング、エージング、グループサイズ制限、テナントクォータ、デッドラインキャンセルを組み合わせます。
これはスケジューリングゲート（Scheduling Gates）とどう違いますか？
ゲートは、単一のPodがスケジュール可能なキューに入るタイミングを制御します。Scheduling Groupは、スケジューラにPodGroupを介してセット全体を評価させます。これらは組み合わせることができますが、メトリクスと障害セマンティクスは個別に管理する必要があります。
ロールアウトを延期するのはどのような場合ですか？
クラスタのバージョン、フィーチャーゲート、スケジューラプラグイン、またはオートスケーラーに互換性がない場合、あるいはアルファ版のアップグレードとロールバックがテストされていない場合は延期します。暫定的な設計として明示的なキューコントローラを使用します。
参考文献
- Kubernetes ドキュメント：「Scheduling Group」
- Kubernetes ドキュメント：「PodGroup Scheduling Policies」
- Kubernetes ドキュメント：「Scheduling API Reference」