プロンプトとコンテキスト
あなたはトレーニングおよび推論ジョブ用のKubernetesクラスターを担当しています。ノードにはH100、A100、およびより小規模なアクセラレータが搭載されています。あるワークロードは、容量が不足している場合、まずH100、次にA100、その次に他の互換デバイスを要求します。決定論性、公平性、障害、可観測性、移行、およびロールバックを網羅したDynamic Resource Allocation（DRA）の要求およびスケジューリングフローを設計してください。アーキテクチャ上のトレードオフを判断できるシニアエンジニアとして回答してください。
面接官がテストするポイント
- 優先度がクライアント側のポーリングやハードコードされた確保ではなく、検証可能なポリシーになっているか。
- ResourceClaim、ResourceSlice、ドライバー、およびスケジューラーのライフサイクルの理解。
- 決定論的なタイブレーク、ヘルス状態の変化、リトライ、およびタイムアウト。
- 公平な容量割り当て、テナント分離、メトリクス、および監査性。
- デバイスプラグインからDRAへのリバーシブルな移行パス。
明確にすべき質問
- 利用可能なフォールバックであれば何でも許容されますか、それともメモリ、アーキテクチャ、ドライバーの機能はハード制約として維持する必要がありますか？
- 1つのPodが異なるデバイスモデルを受け入れることは可能ですか？トポロジー、NUMA、ネットワーク帯域幅はハード制約ですか？
- ビジネス要件として厳密なモデル保証が必要ですか、それとも成功率やコストのためにモデルの優先度を妥協できますか？
- テナントにクォータ、優先度、プリエンプションルールはありますか？異常なデバイスはいつ候補から除外されますか？
- 既存のワークロードはResourceClaimを採用できますか？また、移行中に従来のデバイスプラグインと共存する必要がありますか？
30秒の回答
デバイスの優先度をDRAリクエスト内で順序付けられた候補とハード制約としてエンコードし、クライアントがノードをポーリングする代わりに、Claimのライフサイクル中にスケジューラーがリソースをマッチングするようにします。スケジューラーはまずドライバー、アーキテクチャ、トポロジー、テナントクォータの制約をフィルタリングし、次にH100、A100、その他の互換デバイスを順に評価します。各階層では安定したタイブレーカーを使用し、イベントとメトリクスに候補、拒否理由、最終的な選択を記録します。ヘルスの変化やバインドの失敗は、Claimがリトライ可能な場合にのみ再評価をトリガーします。キュースケールのクォータとテナントの重み付けによって公平性を提供します。移行にはデュアルトラックのカナリアリリース、バージョニングされたResourceClaimテンプレート、および従来のプラグインへの切り戻しメカニズムを使用します。
ステップごとの詳細解説
1. 優先度モデルの定義
モデルの優先順序をソフトな優先度として扱います。ドライバーバージョン、アーキテクチャ、最小メモリ要件、トポロジー、分離をハード制約として扱います。リクエストで「第1候補H100、第2候補A100」と指定することはできますが、フォールバックによってメモリやテナントクォータをバイパスしてはなりません。監査とロールバックのために、バージョニングされたポリシー識別子を含めます。
apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
spec:
spec:
devices:
requests:
- name: accelerator
exactly:
deviceClassName: gpu
selectors:
- cel: "device.attributes['model'] == 'H100'"
- cel: "device.attributes['model'] == 'A100'"順序付けられた候補はビジネス上の優先度を表現します。デプロイメントはクラスターがサポートするDRA APIバージョンおよびドライバー機能と一致している必要があります。
2. リソースClaimとスケジューリングフロー
PodはResourceClaimTemplateを使用してClaimを作成します。DRAドライバーは、デバイス属性、容量、ヘルス状態を含むResourceSliceを公開します。事前フィルタリング中、スケジューラーはClaimとSliceを読み取り、ハード制約を検証し、候補を順に検索します。バインド後、ドライバーはコンテナに割り当てを公開します。リトライによって回収不能な重複割り当てが発生しないよう、Claimは冪等でなければなりません。
3. 決定論的な選択と説明性
ある階層に複数のデバイスが存在する場合、リソースプール、ResourceSlice名、デバイス識別子に基づく安定した順序、または明示的な容量・トポロジーランキングを使用します。このルールをインターフェース規約の一部とします。候補、フィルター、拒否理由、最終デバイス、ポリシーバージョンを記録します。同じ入力を再実行した場合に同じ結果が得られる必要があり、運用者はなぜH100がスキップされたのかを説明できなければなりません。
4. 障害、ヘルス、およびリトライの挙動
新しいClaimは異常とマークされたデバイスをスキップする必要があります。既にバインドされているワークロードは、終了、移行、または再作成に関するランタイムおよびコントローラーのポリシーに従います。バインドの競合、古いSlice、ノード障害を、リトライ可能か致命的かで分類します。スケジューラーの負荷を増大させる繰り返しのスキャンを防ぐため、リトライにはバックオフと冪等性キーが必要です。A100へのフォールバックはハード制約が維持されている場合にのみ有効であり、実際のモデルはPodのstatusで確認可能でなければなりません。
5. 公平性、容量、および可観測性
優先度がH100を無期限に専有するパスになってはなりません。キューレベルの調停にはテナントクォータ、重み付け、待機時間を使用し、デバイスレベルの選択は候補順に従います。モデルごとのリクエスト量、フォールバック率、待機時間、バインド失敗、ヘルスの変化、テナントの使用状況、ポリシーのヒット率を追跡します。ログに機密性の高いテナントデータを含めることを避けつつ、イベントに判読可能な決定チェーンを保持します。
6. 移行とロールバック
従来のデバイスプラグインが残りを処理する間に、ワークロードのごく一部に対してDRAクラスとResourceClaimテンプレートの導入から開始します。拡大する前に、成功率、フォールバック率、スケジューリングレイテンシ、GPU使用率を比較します。テンプレートとポリシーをバージョニングします。ドライバーまたはスケジューリングの問題が発生した場合は、新しいテンプレートの公開を停止し、ワークロードを従来のプラグインに戻します。Claimとデバイス割り当てを同時に変更するのではなく、規定の終了ポリシーに基づいて既にバインドされているジョブを処理します。
模範解答
優先度、制約、および割り当ての証明を分離します。優先度は順序付けられた候補リストです。制約はモデルの機能、メモリ、ドライバー、トポロジー、テナントクォータ、分離をカバーします。PodがResourceClaimを作成した後、DRAドライバーがResourceSliceを公開し、スケジューラーはハード制約をフィルタリングした上で候補を順に選択します。リソースプールとデバイス識別子の安定した順序によってタイブレークを行い、再現を決定論的にします。イベントには候補、拒否理由、ポリシーバージョン、実際のモデルが含まれます。
障害パスでは、異常なデバイス、バインド競合、古いClaim、ノード障害を区別します。リトライ可能なエラーのみがバックオフを使用し、フォールバックがハード制約を超えることはなく、最終的なモデルがstatusに書き込まれます。テナントクォータ、キューの重み付け、待機時間によって公平性が保護され、H100の優先によって他のテナントがリソース枯渇に陥るのを防ぎます。移行はカナリア環境で従来のプラグインとDRAを並行運用し、バージョニングされたテンプレートとテスト済みのロールバックスイッチを使用します。
よくある間違い
- ハード制約や階層内のタイブレーカーを考慮せず「モデル順にソートする」とだけ答える。
- クライアントにノードをスキャンさせたりデバイスを直接確保させたりして、Claimやスケジューラーをバイパスする。
- ヘルス変化、バインド競合、満たせない制約を無限リトライとして扱う。
- テナントの公平性、クォータ、待機時間を無視してH100のヒット率のみを最適化する。
- 従来のデバイスプラグインを一度に削除し、迅速なロールバック手段を残さない。
- 最終的なデバイスのみを記録し、候補や拒否の証拠を失ってしまう。
フォローアップ質問と回答
H100とA100の両方が制約を満たす場合、ランダムに選択してはいけない理由は？
ランダムな選択は再現性と診断性を低下させます。キャパシティバランシングは安定した順序に従うことができますが、そのルールは説明可能かつ観測可能でなければなりません。ランダムシードが隠れた規約になってはなりません。
事前フィルタリングの後、バインドの前にデバイスが異常になった場合はどうなりますか？
バインド時にバージョンとヘルスを再確認します。分類されたエラーを返し、Claimが依然として有効で候補が存在する場合にのみバックオフ付きでリトライします。そうでない場合はPod上で明確な充足不能理由を公開します。
フォールバックが公平性を損なわなかったことをどのように証明しますか？
テナントおよびモデルごとに待機時間、使用量、フォールバック率、キューのシェアを測定し、再実行およびカナリアコホートを比較します。あるテナントが第一希望をほとんど取得できない場合は、リクエストの優先度を上げ続けるのではなく、クォータまたは重み付けを調整します。