システムデザイン面接：Kubernetes v1.36 DRAをNode Allocatableリソースにどのように活用するか？

質問と範囲

マルチテナントの推論クラスタが、Dynamic Resource Allocation（DRA）を介してアクセラレータを割り当てます。ドライバはデバイスごとにCPU、メモリ、またはhugepagesを消費し、一部のデバイスはNUMAアライメントを必要とします。スケジューラがDRAの割り当てと通常のPodリクエストを統合して会計処理できるように、Kubernetes v1.36のNode Allocatable計画を設計してください。ResourceSliceマッピング、Pod status、ロールアウト、モニタリング、およびロールバックの境界について説明してください。

公式のv1.36 DRAアップデートでは、Node Allocatableリソースは、DRAが管理するCPU、メモリ、hugepagesを標準のノード会計に取り込む最初のイテレーションとして説明されています。この機能はまだalphaであるため、設計には実験的機能のためのガードレールが必要です。

コンテキストと境界

この質問は、スケジューリング前のリソース会計、トポロジー制約、およびリリースの安全性に焦点を当てています。ドライバ内部でのハードウェア割り当てやビジネスレベルのフォールトトレランスは外部依存関係です。回答では、APIバージョン、feature gate、鮮度（freshness）ポリシー、台帳（ledger）の一貫性、およびロールバック条件を明記する必要があります。

面接官が見ているポイント

• リソース台帳、スケジューラ、DRAドライバ、ResourceSlice、およびPod statusを関連付けられるか。
• デバイス容量と、デバイス割り当てによって消費されるノードリソース、および通常のPodリクエストを明確に区別できるか。
• NUMA、hugepages、順不同の更新、ドライバの再起動、および古いResourceSliceを適切に処理できるか。
• alphaのfeature gateを、カナリア、オブザーバビリティ、ロールバック、および旧ドライバとの互換性を考慮してロールアウトできるか。
• statusの更新がDRAの合成サブリソース（synthetic subresources）およびノードスコープの権限に制限されているか。

30秒の回答

「DRAドライバに、各デバイスのCPU、メモリ、またはhugepageへの寄与をResourceSlice上のnodeAllocatableResourceMappingsで宣言させます。スケジューラは、バインドされたclaimからの割り当てと通常のPodリクエストをノード台帳内でマージし、各claimを1回だけカウントします。固定フットプリントにはallocationMultiplierを使用し、容量ベースのフットプリントにはcapacityKeyを使用できます。Pod statusはnodeAllocatableResourceClaimStatusesを通じてその結果を公開します。DRANodeAllocatableResourcesはカナリアノードのみで有効化し、NUMA、古い更新、pendingの挙動をテストし、台帳やマッピングが安全でなくなった場合は新しいclaimを停止します。」

ステップバイステップの解決策

1. リソースモデルを定義する。 デバイスID、ResourceClaim、ノード、NUMAゾーン、リソース名、単位、マッピングバージョン、および観測時刻を再生可能な台帳に保存します。デバイス容量と、CPU、メモリ、hugepageの消費を分離します。claimは台帳に1回だけ登録される必要があります。

1. ResourceSliceマッピングを公開する。 DRAドライバはnodeAllocatableResourceMappingsをResourceSliceに書き込みます。マッピングキーはCPU、メモリ、ephemeral-storage、またはhugepagesを表すことができます。デバイスごとの固定フットプリントはallocationMultiplierで表現でき、容量ベースの消費はcapacityKeyを使用できます。

resourceSlice:
  nodeAllocatableResourceMappings:
    cpu:
      allocationMultiplier: 2
    memory:
      allocationMultiplier: 4Gi
    hugepages-2Mi:
      capacityKey: consumed

これはマッピングのセマンティクスのみを示しています。フィールドタイプと単位は、現在のKubernetes APIスキーマおよびドライバの実装に照らして確認する必要があり、そのまま投入可能なオブジェクトではありません。

1. スケジューリング台帳をマージする。 スケジューラはResourceSlicesとバインドされたResourceClaimsを読み取り、DRAの寄与分を計算して通常のPodリクエストを加算します。重複排除には安定したclaimキーを使用します。ResourceSliceが古い場合やマッピングが存在しない場合は、古い容量に基づいてスケジューリングするのではなく、新しいPodをpendingのままにしてアラートを発行します。

1. NUMAと順序付けを処理する。 NUMAアフィニティとバージョンを記録します。ノードのバージョン順序が単調増加である場合にのみ、割り当て、解放、またはResourceSliceの更新をコミットします。ドライバの再起動中は、一時的な二重割り当てを回避するために、新しいclaimを受け入れる前にマッピングを再構築します。

1. statusとテレメトリを公開する。 Podのstatus.nodeAllocatableResourceClaimStatusesにclaimのノードリソース状態を記録します。台帳の容量、使用量、マッピングの経過時間、pendingの理由、重複拒否カウント、NUMA配置失敗を追跡します。statusの書き込みとスケジューリングの決定をclaim UIDと関連付けます。

1. カナリアとロールバック。 コントロールプレーン、スケジューラ、およびドライバの互換性が確認された後、カナリアノードに対してのみDRANodeAllocatableResourcesを有効化します。ResourceSlices、claimと通常のPodの混在、ノードの再起動、ドライバのアップグレード、解放をテストします。障害発生時は、新しいclaimを停止し、既存のバインディングを維持し、台帳をエクスポートしてマッピングを修復し、バージョンごとに再開します。すべてのクラスタでalpha機能を安全に有効化できると思い込まないでください。

1. セキュリティ境界。 DRAドライバには、そのstatus更新に必要な合成サブリソースの権限のみを付与します。ノードローカルのドライバは、ノード対応の動詞と最小権限のRBACを使用します。書き込み失敗時はアラートを発行して再試行すべきであり、権限を拡張しても台帳の不整合は修復されません。

模範解答

私はNode Allocatableをバージョニングされたリソース台帳として扱います。ドライバはnodeAllocatableResourceMappings内でデバイスのCPU、メモリ、またはhugepagesへの寄与を宣言します。固定の寄与にはallocationMultiplierを使用し、容量ベースの寄与にはcapacityKeyを使用します。スケジューラはバインドされたclaimを読み取り、各claimの寄与分と通常のPodリクエストをマージし、claim UIDによって重複排除を行うことで、デバイス使用量とノードリソース使用量が二重計上されないようにします。

台帳には、ノード、デバイス、NUMA、マッピングバージョン、および観測時刻を記録します。ResourceSliceが古くなった場合、バージョンの後退が発生した場合、またはドライバが再起動した場合は、古い容量からスケジューリングするのではなく、新しいPodをpendingのままにします。PodのnodeAllocatableResourceClaimStatusesはリードバックと診断をサポートしますが、台帳の一貫性チェックに代わるものではありません。

v1.36は依然としてalphaであるため、まずカナリアノードでDRANodeAllocatableResourcesを有効化し、claimとPodの混在、NUMA、ノード再起動、解放、ドライバアップグレードをテストします。ロールバックでは、新しいclaimを停止し、既存のバインディングを維持し、マッピング修復前に台帳をエクスポートします。RBACはDRA合成サブリソースとノードスコープの権限に制限します。

よくある間違い

• 間違い: デバイスごとに1回、claim再試行後にもう1回ノードCPUを差し引く → 失敗する理由: 安定した冪等性キーがない → 修正策: claim UID、デバイスID、マッピングバージョンで重複排除する。
• 間違い: 説明用のYAMLを本番用APIオブジェクトとして投入する → 失敗する理由: フィールドスキーマと単位がバージョニングされている → 修正策: ResourceSlice APIとドライババージョンを検証する。
• 間違い: ResourceSliceが利用不可の間、古い容量を使い続ける → 失敗する理由: 古いデータはオーバーコミットを引き起こす可能性がある → 修正策: 鮮度ウィンドウ（freshness window）を設け、期限切れ後は新しいclaimをpendingにする。
• 間違い: alphaのgateを一度に全体で有効化する → 失敗する理由: 互換性とロールバックがテストされていない → 修正策: カナリア、メトリクス、claimアドミッション停止、および回復可能な台帳を採用する。
• 間違い: status書き込みエラーを修正するためにRBACを拡張する → 失敗する理由: データの一貫性を修正することなく権限のみを広げてしまう → 修正策: 合成サブリソース、ノード対応動詞、および監査ログを使用する。

フォローアップ質問と回答

allocationMultiplierとcapacityKeyはどのような場合に使い分けるべきですか？

すべての割り当てが固定量のCPUまたはメモリを消費する場合はallocationMultiplierを使用します。ドライバ定義の監査可能なセマンティクスにより、消費量がデバイス容量やワークロードに応じて変化する場合はcapacityKeyを使用します。どちらの選択肢でも単位とバージョニングを固定してください。

通常のPodリクエストとDRAマッピングの二重計上をどのように防ぎますか？

1つの台帳を維持します。通常のリクエストはリクエストストリームに入り、DRAの寄与分はclaim UIDをキーとして割り当てストリームに入ります。スケジューラは各マッピングを1回だけ適用し、ソースとバージョンを記録します。重複したキーは拒否され、アラートが発せられます。

ドライバ再起動後、直ちにスケジューリングを再開すべきですか？

いいえ。ResourceSlicesを再構築し、バインドされたclaimを検証し、単調増加するバージョンと容量を確認してから、新しいclaimを受け入れます。再構築中は、既存のバインディングを維持し、新しいPodをpendingのままにします。

NUMA配置が会計の一貫性を維持していることをどのように示しますか？

異なるNUMA間、同一NUMA内、解放再試行、およびノード再起動イベントをリプレイします。ノードの合計、NUMAサブ台帳、およびPod statusを比較します。配置失敗、台帳の乖離、pending時間、および重複拒否カウントを追跡します。

alpha機能はいつプロモートできますか？

互換性のあるドライバのカバレッジ、ロールバック訓練、ノード再起動およびアップグレードのリプレイ、乖離ゼロの観察期間、ならびに明確な容量およびpending SLOが必要です。ビルドの成功や1ノードでのテストだけでは、完全なロールアウトには不十分です。

参考文献

• Kubernetes v1.36 DRA update (Kubernetes Blog)
• Feature Gates (Kubernetes Documentation)
• ResourceSlice API (Kubernetes Documentation)
• Pod API (Kubernetes Documentation)
• DRA hardening guide (Kubernetes Documentation)

面接チェックリスト

ドライバからResourceSlice、claim、スケジューラ、Node Allocatable台帳、Pod statusへのフローを描きます。次に、冪等性、バージョン、NUMA、カナリア、最小権限を追加します。

1行のまとめ

DRA Node Allocatableは、単一のバージョニングされロールバック安全な台帳が、各claimの実際のノードリソース寄与分を会計処理するときに成功します。

練習を続けよう

マッピングをマルチノードResourceClaimsに拡張し、トポロジー、鮮度（freshness）、およびリカバリがスケジューリング決定をどのように変えるかを説明してください。