プロンプトとコンテキスト
マルチテナントGPU推論プラットフォームでは、Kubernetes Device PluginsとDynamic Resource Allocation（DRA）を使用しています。ドライバーが切断されたカードを検出した際、従来のシステムではノードログにのみエラーが出力され、Podが再起動して同じデバイスを繰り返し要求してしまいます。Podの.statusにおけるallocatedResourcesStatusを中心とした障害ガバナンスを設計してください。オペレーターやコントローラーがデバイスの健全性を把握し、不良カードを隔離し、Unknownを安全に処理し、一時的なシグナルによる大量削除を回避できるようにする必要があります。
Kubernetes v1.36では、リソース健全性ステータスがBetaに昇格しました。公式リリースノートによると、Podステータスで割り当てられたデバイスの健全性が報告され、kubectl describe podがUnhealthyまたはUnknownを公開できるようになりました。この仕組みは従来のDevice PluginsとDRAの両方のパスをカバーしています。
面接官がテストしているポイント
- 割り当て成功、デバイス健全性、コンテナレディネス（readiness）、ビジネスSLOを明確に区別できるか？
- ドライバー、kubelet、Podステータス、コントローラー、スケジューラー、アラート間のデータフローを描けるか？
- 観測の欠落をハードな障害として扱うのではなく、
UnhealthyとUnknownを適切に区別して扱えるか？ - べき等な隔離、リース、リトライ、レート制限、および復旧後の再エントリーを設計できるか？
- ステータスは診断シグナルであり、スケジューリングポリシーやビジネスプローブを自動的に代替するものではないことを説明できるか？
最初に明確にすべき質問
- 健全性を生成するドライバーはどれで、その更新遅延とハートビート周期はどのくらいか？
- Podが複数のカードを保持している場合、1枚が故障した際にジョブを部分的に縮退できるか、それともユニット単位で移行する必要があるか？
Unknownは一時的な切断、ノードの停止、またはサポートされていないドライバーの挙動を意味するのか？その許容ウィンドウはどのくらいか？- 隔離はデバイス単位、ノード単位、ResourceClaim単位、テナントワークロード単位のいずれで実施され、誰が解除できるのか？
- ジョブにはチェックポイント、べき等なコミット、リトライバジェットがあるか？移行によってどの程度のGPUチャーン（入れ替わり）が発生し得るか？
30秒の回答
「デバイスの健全性はPod削除コマンドではなく、状態入力として扱います。ドライバーとkubeletがallocatedResourcesStatusを更新した後、コントローラーがデバイスIDごとに集約します。Unhealthyは隔離とアラートの対象となり、Unknownにはまずハートビート許容ウィンドウが与えられます。べき等性キーとリースにより新規割り当てをブロックし、チェックポイントを持つジョブはノードごとのレート制限を適用して移行させます。復旧時はプローブと小さなカナリアを実行してから解除します。状態の鮮度、誤隔離、移行成功率、ビジネスSLOを検証します。」
ステップごとの詳細解説
- 状態モデルを定義する。 デバイスの識別情報、Pod、コンテナ、ResourceClaim、ノード、健全性の値、メッセージ、観測時刻、ステータスバージョンを記録します。1つのブール値がすべての自動処理をトリガーしてしまわないよう、
Unhealthy（確認済みの障害）とUnknown（未確認）を分離します。
- データフローを構築する。 DRAまたはDevice PluginがデバイスをPodに割り当て、kubeletがドライバーから報告された健全性をPodステータスに書き込みます。ステータスオブザーバーがPodの変更を監視し、デバイスキーで重複排除を行って、再生可能なデバイスディレクトリに書き込みます。アラートとコントローラーは、APIを個別にスキャンする代わりにそのディレクトリを読み取ります。
- 新規割り当てを隔離する。 不健全であることが確認されたデバイスについて、内部隔離レコードを作成し、スケジューラー拡張、ResourceClaim選択、またはノード容量ビューから除外します。Podステータスを直接編集したり、単発のイベントを即座にNode NotReadyに変更したりしないでください。隔離アクションには理由、実行者、有効期限が必要です。
- 実行中ジョブを処理する。 コントローラーは移行リースを取得する前に、チェックポイントとべき等コミットを確認します。復旧可能なジョブは新規リクエストを停止し、チェックポイントを保存し、デバイスを解放して健全なデバイス上で再構築します。復旧不可能なジョブは証拠を保全し、テナントに通知します。デバイスとジョブを所有できる移行フローは1つのみです。
- Unknownをガードする。 Unknownはkubelet、ドライバー、またはノードのネットワーク瞬断から発生する可能性があります。ハートビートに基づく許容ウィンドウと指数バックオフを適用し、ウィンドウ期間中はアラートを出し、期限切れになった後にのみ割り当てを制限します。ノード全体の停止については、1つのPodステータスからすべてのデバイスが壊れていると推測するのではなく、ノードリースと既存の障害検出を使用します。
- 復旧と検証を行う。 デバイスが再び健全と報告されたら、隔離を解除する前にドライバープローブ、小規模ジョブ、および安定ウィンドウを実行します。ステータスの鮮度、Unknownの継続時間、誤隔離率、移行成功率、アイドルGPU時間、ビジネスエラーを追跡します。重複イベントや順序不同のイベントを再生し、コントローラーを再起動して復旧をテストします。
Device health event
-> Pod status observer
-> deduplicate by (node, deviceID, statusVersion)
-> device quarantine record with lease and expiry
-> scheduler/claim filter excludes unhealthy device
-> checkpointed workload migration
-> probe + canary
-> release quarantineモデル回答
ドライバー、kubelet、Pod、ResourceClaim、ジョブを紐付けるデバイスレベルのステータスディレクトリを作成します。Unhealthyは確認済みの障害であるため、有効期限付きのリースで保護された隔離を作成し、新規割り当てをブロックしてアラートを発行します。Unknownはまずハートビート許容ウィンドウに入り、ウィンドウが期限切れになった場合のみ割り当てを制限します。オブザーバーはデバイスIDで重複排除を行い、再起動したコントローラーはインメモリフラグではなく永続化されたイベントとレコードから状態を再構築します。
移行はチェックポイント、べき等コミット、テナントの優先度に依存します。復旧可能なジョブはチェックポイントを取得し、デバイスを解放して健全なデバイスで再構築します。復旧不可能なジョブは証拠を保全します。復旧はドライバープローブと小さなカナリアから開始します。スケジューラー拡張、DRA選択、容量ビューは隔離レコードを参照しますが、ステータスはレディネスやビジネスSLOではなく診断入力としての位置付けを維持します。状態の鮮度、誤検知、移行成功、ビジネスエラーのメトリクスによってこの設計を証明します。
よくある間違い
- 事象: ステータスが
UnknownのときにすべてのPodを削除する → 失敗の理由: 一時的な観測のギャップがクラスター全体のチャーンにつながる → 対策: リース、ハートビートウィンドウ、レート制限を使用する。 - 事象: ノードのみを隔離し、デバイスの識別情報を無視する → 失敗の理由: 1枚の不良カードによって健全なデバイスまで巻き添えになる → 対策: デバイスとResourceClaimをキーにして記録し、正当な理由がある場合にのみノード単位にエスカレーションする。
- 事象: デバイスが健全に見えるようにPodステータスを編集する → 失敗の理由: 単一の真実のソース（Source of Truth）が破壊され、誤った復旧につながる可能性がある → 対策: kubeletのステータスを保持し、監査可能な隔離状態を個別に作成する。
- 事象: 復旧したデバイスを即座にフルロードに戻す → 失敗の理由: 一時的な復旧や不安定なドライバーにより再発する可能性がある → 対策: プローブ、カナリアテストを実施し、段階的に負荷を上げる。
フォローアップの質問と回答
1つのGPUが故障しましたが、Podは他のGPUも所有しています。ジョブの一部のみを移行すべきですか？
まず、フレームワークが動的な縮退と再バインドをサポートしているか確認します。モデルが固定のデバイストポロジーを必要とする場合は、ジョブ全体を移行します。シャーディングが可能な場合は、影響を受けたシャードのみを移動し、残りのデバイスに対するResourceClaimとチェックポイントのセマンティクスを維持します。
値はHealthyですが、ステータスメッセージが古いです。どう対応しますか？
健全性の値とステータスの鮮度を分離します。ハートビート制限を超えた後は、古いHealthyを最新の証拠として扱うのではなくUnknownに遷移させます。アラートとスケジューリングガードレールには鮮度（age）を使用します。
複数のコントローラーが同じジョブを移行しないようにするにはどうすればよいですか？
デバイスID、ジョブID、ステータスバージョンから構築されたべき等性キーを使用し、有効期限付きリースまたは楽観的バージョン更新を組み合わせます。リースを失ったコントローラーは停止し、代替コントローラーが永続化されたレコードから再開します。
デバイスはいつキャパシティプールに復帰できますか？
ドライバーからの健全報告は必要条件ですが、十分条件ではありません。デバイスプローブ、小規模ジョブ、安定ウィンドウ、および隔離理由のクローズが必要です。いずれかの失敗により隔離が延長され、手動での強制解除はブロックされます。
参考文献
- Kubernetes v1.36: Haru
- Kubernetes v1.36: More Drivers, New Features, and the Next Era of DRA
- Kubernetes v1.34: Pods Report DRA Resource Health
- Dynamic Resource Allocation ドキュメント
面接チェックリスト
ドライバーからPodステータス、オブザーバー、隔離、スケジューリングフィルターへのフローを描きます。UnhealthyとUnknownを分離し、リース、チェックポイント、レート制限、復旧カナリア、メトリクスを追加します。
1行のまとめ
デバイスの健全性によりKubernetes上でハードウェア障害を観測できるようになりますが、安全な復旧にはデバイスレベルの隔離、Unknownに対するガードレール、べき等な移行、段階的な再利用が不可欠です。