問題と適用シナリオ
あなたはKubernetes上の分散トレーニングプラットフォームを担当しています。ワークロードはPodGroupで表され、通信レイテンシを削減するためにそのPod群はラックまたはゾーンを共有する必要があります。1つのトポロジードメインに少なくともminCount個のPodを収容できない場合、ワークロードはスケジュール不可（unschedulable）のままとする必要があります。
これはプラットフォームエンジニアリング、SRE、システム設計の面接に適しています。デフォルトで無効化されているKubernetes v1.36 alphaのTopology-Aware Schedulingを想定し、PodGroupごとに1つのトポロジー制約が存在するものとします。
面接官が評価している点
- トポロジー分散（topology spread）によるドメイン間バランシングと、ギャング向けの同一ドメイン配置を明確に区別できているか。
- PodGroup、ノードラベル、候補配置、リソースの実現可能性、アトミックバインディングが1つのデータフローを形成しているか。
minCount、容量不足、スケールアップ、およびトポロジーを契機とするプリエンプションが存在しないことについて説明できるか。- 設計を本番対応可能と呼ぶ前に、alphaステータス、異種混在（ヘテロジニアス）グループ、ロールバックリスクを特定できているか。
回答前に確認すべき質問
- Podはラック、ゾーン、NUMAドメインのどれを共有する必要がありますか？トポロジーキーごとにレイテンシと容量の前提条件が変わります。
- すべてのPodが同時に起動する必要がありますか、それとも進行するために
minCount個で十分ですか？これによりGangポリシーと伸縮性が決まります。 - Podは同種（ホモジニアス）ですか？リクエストされるリソースが異なると、候補配置が見つかるかどうかに影響します。
- クラスターはスケールやプリエンプションを実行できますか？v1.36 TASは単にトポロジーを満たすためだけのプリエンプションは行いません。
30秒の回答フレームワーク
「私は目標を、レプリカの分散ではなく、1つのトポロジードメイン内でのグループレベルの実現可能性と定義します。WorkloadテンプレートがgangとminCountを持つPodGroupを作成し、ノードラベルがトポロジーキーを提供します。スケジューラは候補ノードのサブセットを生成し、グループ全体をチェックして、実行可能な配置をスコアリングします。適合するものがなければ、グループはスケジュール不可のままになります。コントローラーとオートスケジューラーはリソース全体の形状を考慮し、v1.36 TASはプリエンプションをトリガーしないためプリエンプションは個別に処理します。alphaフィーチャーゲートの背後で、ドメイン容量、ノード喪失、異種リクエストをテストします。」
ステップごとの詳細解説
1. 分散ではなく同一配置（co-location）を明記する
topologySpreadConstraintsはmaxSkewを使用して複数のドメイン間でPodをバランシングします。この質問では、すべてのメンバーが1つのトポロジーラベル値を共有することが求められます。これらのセマンティクスを混同すると逆の配置が生成されるため、不変条件を「1つのドメインが少なくともminCount個を収容できなければならない」と定義します。
2. PodGroupのコントラクトを定義する
テンプレートでは、Gangポリシー、minCount、および1つのトポロジーキーを宣言します。構成の例は以下のとおりです。
apiVersion: scheduling.k8s.io/v1alpha2
kind: PodGroup
spec:
schedulingPolicy:
gang:
minCount: 4
schedulingConstraints:
topology:
- key: topology.example.com/rackノードには、安定的で管理されたラベル値が必要です。PodGroupは配置を表現し、メンバーの作成、バージョン、ライフサイクルは引き続きWorkloadコントローラーが担当します。
3. 候補配置のプロセスを説明する
スケジューラはまず、リソース、テイント、アフィニティ、およびトポロジーキーを使用して候補ノードのサブセットを生成します。次に、PodGroup全体が各サブセット内に収まるかどうかをチェックし、実行可能な配置をスコアリングします。これにより、一部のPodがドメインをまたいで早期にバインドされ、残りのメンバーがminCountを満たせなくなる事態を防ぎます。
4. 容量、スケールアップ、プリエンプションの処理
十分な容量を持つ候補ドメインがない場合、グループ全体がスケジュール不可のままになります。オートスケジューラーは、最初のPending Podに対してスケールするのではなく、CPU、メモリ、GPU、およびドメインの完全な形状を消費して処理する必要があります。v1.36 TASはトポロジーを満たすためにPodやWorkloadのプリエンプションをトリガーしないため、容量予約、キュー、または明示的なアップストリームのプリエンプションポリシーが個別の要件となります。
5. メンバーの再作成とドメインの固定性の処理
メンバーがすでにドメイン内で実行されている場合、再作成されたPodはその同じドメインに強制配置されます。別のドメインに空きがある場合でも、そのドメインに容量が不足していればPendingのままになります。これをドメイン固定の待機（domain-sticky wait）として公開し、待機するか、チェックポイントを復元するか、異なる制約を持つ新しいPodGroupジェネレーションを作成するかを決定します。
6. alpha版の制約と異種混在グループの制限を評価する
v1.36 APIはalphaステータスであり、デフォルトで無効になっています。公式のリリースノートでは、異種混在のPodGroupやPod間依存関係がある場合、配置先が存在していても見つかる保証はないと記載されています。本番環境への導入判定には、バージョン、フィーチャーゲート、スケジューラプラグイン、オートスケジューラー、およびロールバックを含める必要があります。1回のスケジューリング成功は普遍的な保証にはなりません。
7. 検証およびロールバックループを構築する
ギリギリのドメイン容量、1ノードの欠落、トポロジーラベルの欠落、異なるGPUタイプ、メンバーの再作成といった条件下で、同一のトレーニングワークロードを実行します。候補ドメイン、実行可能メンバー数、Pending理由、待機時間、ドメイン間トラフィック、トレーニングスループットを記録します。カナリアテストが失敗した場合は、監査用にPodGroupイベントを保持しつつ、フィーチャーゲートを無効化するか、通常のGangスケジューリングに戻します。
高品質な回答サンプル
私は不変条件を、バランシングのための分散制約を使用するのではなく、「少なくともminCount個のメンバーが1つのトポロジードメインに同時に収まること」と定義します。WorkloadコントローラーはGang、minCount、および1つのトポロジーキーを持つPodGroupを作成し、それを参照するPodを作成します。スケジューラはリソースとノードラベルから候補ドメインを生成し、グループ全体をチェックして、実行可能なドメインのみをスコアリングします。適合するものがなければ、グループはPendingのままになります。オートスケジューラーはグループの形状に基づいてスケールし、v1.36 TASはプリエンプションをトリガーしないためプリエンプションは個別に処理されます。再作成されたメンバーはドメインの固定性を保持します。そのドメインが失われた場合は、新しいジェネレーションを作成します。最後に、待機時間、ドメイン間トラフィック、トレーニングスループットを測定しながら、ノード喪失、ラベルの欠落、異種GPU、およびロールバックをalphaゲートの背後で検証します。
よくある間違い
- 症状：同一ドメイン配置を
maxSkewで説明する。失敗する理由：分散は均等配置を目的としており、Gangの同一配置とは逆になります。修正策：まずPodGroupの単一ドメイン不変条件を提示します。 - 症状：Podを1つずつバインドする。失敗する理由：早期のバインドが複数のドメインにわたって容量を消費し、
minCountに到達できなくなります。修正策：まず完全な候補配置を評価します。 - 症状：TASが自動的にプリエンプションを実行すると想定する。失敗する理由：v1.36ではトポロジー対応スケジューリングがプリエンプションをトリガーしないことが明記されています。修正策：予約、キュー、またはアップストリームのプリエンプションコントローラーを設計します。
- 症状：異種混在グループとalphaステータスを無視する。失敗する理由：配置は保証されておらず、機能はデフォルトで無効になっています。修正策：バージョン、ゲート、プラグイン、およびロールバックのチェックを追加します。
フォローアップの質問と回答
1つのラックにminCount個を収容できないが、2つのラックを合わせると収容できる場合はどうなりますか？
同一ドメインの不変条件が満たされないため、グループをPendingのままにするか、アプリケーションが伸縮性を許可している場合にのみminCountを下げます。通信に関する前提が変わってしまうため、暗黙的にラックをまたぐ配置にフォールバックしてはなりません。
オートスケジューラーはどのように適切にスケールすべきですか？
リソースリクエスト全体、トポロジーキー、およびminCountを1つのスケール単位として扱います。ターゲットドメインで必要なノードタイプとノード数を予測し、スケールアップ後に候補を再生成して、待機期限（wait deadline）を適用します。
再作成されたメンバーが別のドメインに移動できないのはなぜですか？
ドキュメントに記載されている動作では、既存のメンバーが実行されているドメインに新しいメンバーが保持されます。1つを移動するとレイテンシや共有リソースの前提条件が変化するためです。ドメインが恒久的に失われた場合は、古いPodGroupを暗黙的に変更するのではなく、新しいPodGroupジェネレーションを作成します。
これをトポロジー分散制約（topology spread constraints）と共存させるにはどうすればよいですか？
単一のトレーニングジョブ内のメンバーを同一配置するにはTASを使用し、複数のジョブ間でレプリカを分散するにはtopology spreadを使用します。両方を1つのPodに設定する前に、それらのハード制約が空でない共通部分を持っているかをテストしてください。そうしないとPodがPendingのままになる可能性があります。
通常のGangスケジューリングの方がTASよりも適しているのはどのような場合ですか？
ドメイン間通信のコストが低い場合、ドメイン容量が頻繁に逼迫する場合、alpha機能がロールアウトの準備段階にない場合、またはワークロードがラックの共有を必要としない場合は、通常のGangを選択します。TASを有効にするのは、スループットの向上が容量や運用のコストに見合う場合のみにしてください。