プロンプトと適用範囲
あるマルチテナントクラスタにおいて、デバイス全体単位でのみ割り当てることができないGPUメモリや仮想NIC帯域幅が存在します。プラットフォームは、複数のPodが1つのデバイスを共有できるようにしつつ、すべてのリクエストに最小値、刻み幅（step）、上限、および追跡可能な割り当て識別子（ID）を持たせることを求めています。Kubernetes DRAの消費可能キャパシティを使用して、リソースモデルとエンドツーエンドのフローを設計してください。
Kubernetes 1.34およびキャパシティ制限を強制できるドライバを前提とします。スケジューラはデバイスをオーバーサブスクライブしてはなりません。Kubernetes 1.34ではコアDRA APIが一般提供（GA）となりましたが、消費可能キャパシティはアルファ機能です。優れた回答は、安定版API、フィーチャーゲート、ドライバ固有の保証の境界を明確に区別します。
面接官が評価するポイント
回答では、DeviceClass、ResourceSlice、ResourceClaim、DeviceRequest、スケジューラ、およびドライバに対して明確な責務を割り当てる必要があります。1つのデバイスの割り当て済みキャパシティが合計キャパシティを決して超えないという不変条件を述べ、allowMultipleAllocations、RequestPolicy、ShareID、およびDistinctAttributeについて説明する必要があります。
面接官はまた、スケジューリング決定の成功とアプリケーションレベルのスロットリングを混同していないかも確認します。本番環境向けの設計には、ドライバによる強制、ステータスレポート、ネームスペース認可、ノード障害復旧、およびロールバック可能なロールアウトが必要です。
明確化のための質問
リソースは分離可能か？
ハードウェアまたはドライバが分離を強制できるか確認します。強制できない場合、プラットフォームはソフトクォータやデバイス全体の割り当てを提供することはできますが、APIフィールドのみからQoSを保証することはできません。
共有と認可の境界は何か？
ネームスペース間でデバイスを共有できるか、管理者アクセスが許可されているか、テナントがどのデバイス属性やキャパシティを読み取れるかを質問します。これらの回答によって、セレクタ、アドミッションチェック、監査のスコープが変わります。
障害発生時に何を維持（残存）させる必要があるか？
スケジューリングの失敗、ドライバの割り当て失敗、ノード喪失、またはPodの再作成後に何が起きるか（解放、リースの保持、再キューイングなど）を明確にします。一時的なリトライと恒久的なハードウェア障害には個別の状態が必要です。
30秒の回答フレームワーク
「私はまずキャパシティ不変条件とテナント境界を定義します。DeviceClassで対象デバイスを記述し、ResourceSliceでキャパシティとリクエストポリシーを公開し、ResourceClaimでPodの要求を表現します。スケジューラはキャパシティを超えないようにデバイスを選択し、ドライバはShareIDを使用して実際のメモリまたは帯域幅の制限を強制し、ステータスをレポートします。クロスネームスペースの共有には認可と監査が必要です。すべての解放はべき等です。デバイスクラスごとに段階的にロールアウトし、割り当て済みキャパシティ、実際の制限、スケジューリングレイテンシ、拒否率、復旧時間を比較します。」
ステップバイステップの詳細解説
ステップ1：リソースモデルの定義
DeviceClassはデバイスタイプとCELセレクタを記述します。ResourceSliceは各デバイス、その属性、キャパシティ、および複数割り当てが許可されているかどうかを公開します。ResourceClaimはDeviceRequestを使用してクラスとキャパシティを指定します。デバイス全体の合計キャパシティとリクエストのキャパシティは分離してください。デバイス数1はキャパシティ値ではありません。
ステップ2：キャパシティ不変条件の提示
デバイスごとに、割り当て済みキャパシティ、単位、リクエストポリシーを追跡します。あるデバイスが40 GiBを持ち、リクエストが5 GiB単位で最小5 GiBである必要がある場合、すべてのリクエストはその境界を満たす必要があり、すべてのアクティブなShareIDの合計は最大40 GiBでなければなりません。解放およびリトライ操作には割り当てバージョンを使用し、重複したコールバックによって2回減算されないようにします。
ステップ3：スケジューリングとドライバのデータフローの記述
スケジューラはResourceSliceを読み取り、セレクタ、キャパシティ範囲、allowMultipleAllocationsをフィルタリングして候補を予約し、ResourceClaimをバインドします。ドライバは割り当てを受け取り、ShareIDをキーとする独立した制限を作成してデバイスに適用し、ResourceClaimのステータスに動的データをレポートします。スケジューリングが成功してもドライバが割り当てを拒否した場合、コントローラはリトライ可能または終端の状態を公開します。PodをReady状態に見せてはなりません。
ステップ4：ネームスペースと重複デバイスの処理
共有デバイスであっても、ResourceClaimのネームスペース境界が消えるわけではありません。アドミッションによってDeviceClassの使用、管理者アクセス、ドライバ設定を制限する必要があります。DistinctAttributeは、2つのネットワークインターフェースが異なるサブネットに到達する必要がある場合など、1つのクレームが同じ基盤デバイスを2回選択することを防ぎます。最終的なデバイス名だけでなく、テナント、クレーム、ShareID、キャパシティ、ポリシーバージョンを監査します。
ステップ5：障害と回収の設計
ドライバの再起動後は、永続化された状態からShareIDと実際の制限を復旧します。ノード喪失後は、割り当てをunknownとマークし、リース、デバイスフェンシング、またはドライバの確認によって古い割り当てが消滅したことが証明されるまで、そのキャパシティを別のPodに即座に与えてはなりません。Podの削除、クレームの期限切れ、スケジューリングのロールバックは再現可能（べき等）である必要があります。既存の割り当てはポリシーのスナップショットを保持し、新しいクレームには変更後のポリシーが適用されます。
ステップ6：ロールアウト、SLO、およびキャパシティ計算
それぞれ40 GiBを持つ100台のデバイスがあり、目標平均使用率を70%と仮定します。論理的なスケジューリング可能キャパシティは約2,800 GiBであり、これはスループットの保証ではありません。ドライバのオーバーヘッド、断片化、障害用ヘッドルームを確保してください。スケジューリングp99、ドライバ設定p99、キャパシティ拒否率、ステータス収束のSLOを設定します。デバイスクラスごとにフィーチャーゲートを有効化します。スループット、テールレイテンシ、断片化、復旧をデバイス全体の割り当てと比較します。
ステップ7：代替案の比較
ハードウェアが固定スライスのみをサポートしている場合、MIGまたは事前パーティション分割されたDeviceClassの方がシンプルで検証も容易ですが、断片化と柔軟性の低下というコストが伴います。ドライバがきめ細かな制限を強制できない場合は、デバイス全体の割り当てまたはキャパシティ拡張にフォールバックします。キャパシティフィールドが存在するだけで分離が提供されるかのように見せかけてはなりません。
質の高い模範解答
私はまず、デバイスがキャパシティ分離を強制できるかどうかを検証します。強制できない場合、その設計は宣言的な選択に過ぎず、QoSの保証はありません。強制できる場合、DeviceClassが対象デバイスを記述し、ResourceSliceがキャパシティとリクエストポリシーを公開し、ResourceClaimがテナントのリクエストを伝達します。スケジューラは、セレクタが一致し、キャパシティの合計がデバイスの上限を下回っている場合にのみバインドします。その後、ドライバがShareIDスコープの制限を作成し、ステータスをレポートします。
私はキャパシティの合計、ポリシーバージョン、べき等な解放を明示的な不変条件とします。クロスネームスペース共有にはアドミッション、管理者認可、監査を使用し、DistinctAttributeによって1つのクレーム内での基盤デバイスの重複選択を防ぎます。ドライバまたはノードの障害時には、回収前にフェンシングまたは確認が得られるまで割り当てをunknown状態として保持します。ロールアウトは1つのクラスから開始し、スケジューリングp99、ドライバp99、拒否率、実際の強制、復旧を測定します。固定スライスのハードウェアには事前パーティション分割設計を使用します。
よくある間違い
- 症状 → ResourceClaimにのみキャパシティ値を設定する → 失敗する理由 → ドライバが実際の制限を強制しない可能性がある → 修正方法 → 強制パスとステータスパスを証明する。
- 症状 → デバイス数をキャパシティの合計として使用する → 失敗する理由 → 同時リクエストによってオーバーサブスクライブや断片の浪費が発生する → 修正方法 → デバイスおよびバージョンごとに割り当て済みキャパシティを追跡する。
- 症状 → 共有デバイスを無条件のテナント間共有として扱う → 失敗する理由 → ネームスペースと認可の境界が失われる → 修正方法 → アドミッション、管理者アクセス制御、監査を追加する。
- 症状 → ノード喪失後すぐにキャパシティを解放する → 失敗する理由 → 古いドライバが依然として割り当てを強制している可能性があり、二重割り当てが発生する → 修正方法 → フェンシングを行うか、リースを確認するか、明示的なunknown状態を維持する。
- 症状 → アルファフィーチャーゲートに対して安定版のSLOを約束する → 失敗する理由 → API、ドライバ、アップグレードの動作が変動する → 修正方法 → バージョンの境界を明確にし、カナリアリリースを通じて検証する。
フォローアップと優れた回答
フォローアップ1：2つのネームスペースが同時に最後の10 GiBをリクエストしました。競合をどのように回避しますか？
キャパシティを予約する際に、ResourceSliceのバージョンまたは同等の楽観的並行性チェックを使用します。バインドに失敗した場合は、現在の状態を再読み込みしてリトライします。ドライバのコールバックがスケジューラの不変条件をバイパスすることはできません。コントロールプレーンが最終的な割り当てを確認します。
フォローアップ2：ドライバがShareIDをレポートしましたが、Podが起動しません。何が起きますか？
割り当て状態とPodの準備完了（readiness）状態を分離します。タイムアウト後、コントローラはShareID、クレームバージョン、理由を保持したまま、べき等な解放を実行するか、オペレータが確認可能な状態に移行します。PodがRunningでないという理由だけで、キャパシティや監査データを破棄してはなりません。
フォローアップ3：ポリシーが最小5 GiBから10 GiBに変更されました。既存のクレームは変更されますか？
完了した割り当ては、付与された時点のポリシースナップショットを保持します。新しいクレームには新しいポリシーが使用されます。リバランスには、明示的な移行フロー、リサイズに対するドライバのサポート、およびロールバック可能な解放・再割り当てシーケンスが必要です。
フォローアップ4：共有帯域幅が実際に強制されていることをどのように証明しますか？
固定されたトラフィック、ノード、ドライババージョンを使用して、単一テナントのベースラインテストと複数ShareIDの負荷テストを実行します。テナントごとのスループット、p99、ドロップ率、強制上限値を比較します。ResourceClaimのステータスだけではハードウェアQoSを証明できません。