プロンプトとスコープ
クラスターはGPUまたはネットワークデバイスにDynamic Resource Allocation（DRA）を使用しています。コンテナーは割り当てられたデバイスのPCI、インターフェース、またはドライバーの属性を必要としますが、Kubernetes APIへのアクセス権限を受け取ってはなりません。ドライバーからコンテナーへのメタデータパスを設計し、バージョニング、分離性、障害処理、アップグレード時の挙動を説明してください。
面接官が見ているポイント
- DRAドライバー、ResourceClaim、kubelet、コンテナー間の責務の境界を理解しているか。
- メタデータパス、生成タイミング、マウント、クリーンアップのライフサイクルを具体的に指定できるか。
- 信頼できないドライバーフィールド、ノード間の情報漏洩、バージョン互換性、Podの再起動を適切に処理できるか。
- alpha版の機能を安定したコントラクトとして扱うのではなく、機能の状態やサポートされているバージョンを確認しているか。
明確化のための質問
- メタデータはディスカバリー用データ、ネットワーク構成、それとも認証情報のような機密データですか？
- どのフィールドとスキーマバージョンが必要であり、アプリケーションはデータの欠落や遅延を許容できますか？
- クラスターとノードはDRAデバイスメタデータをサポートしており、ドライバーは公式ライブラリを使用していますか？
- 再割り当て、Podの再起動、ドライバーのアップグレード、ノード障害が発生した場合、何によってファイルが無効化されますか？
30秒での回答例
ドライバーには現在のResourceClaimに対する非機密メタデータのみを公開させ、デバイスの準備（preparation）中にkubeletがバージョニングされたJSONを生成し、ドキュメント化されたパスへ読み取り専用でマウントします。アプリケーションはAPIではなくファイルを読み取ります。作成、更新、アンマウント、クリーンアップはPodのライフサイクルに従います。フィールドとサイズを検証し、不完全なファイルを公開するのではなくドライバーのエラーを可視化します。この機能はalpha版であるため、バージョン検出を維持し、環境変数、プローブ、または従来のドライバーパスへのフォールバックを用意します。
ステップごとの設計
1. データと信頼境界の定義
DRAはデバイスをResourceClaimに割り当て、ドライバーは物理デバイスを認識し、アプリケーションはその結果を利用します。メタデータはデバイス属性やインターフェースの詳細に限定し、秘密鍵、トークン、テナント間の識別子を含めてはなりません。他のデバイスがPodに投影されないよう、ドライバーの入力をクレーム、リクエスト、ノードにバインドします。
2. 安定した配信メカニズムの使用
ドキュメントでは、コンテナー内の既知のパスとデバイス属性用のJSONファイルを定義します。アプリケーションがAPIに問い合わせる代わりにファイルを読み取れるよう、読み取り専用マウントと確定的なディレクトリ階層を使用します。アプリケーションが未知のバージョンを拒否し、互換ロジックを選択できるように、スキーマまたはバージョンフィールドを含めます。
3. ライフサイクルと障害の処理
割り当てと準備が成功した後にのみファイルを作成し、準備解除（unprepare）、Podの削除、またはクレームの解放時にファイルを削除します。生成、書き込み、またはJSON検証の失敗時に、不完全なファイルを公開してはなりません。監視可能なドライバーまたはkubeletのエラーを報告し、アプリケーションが無効なデータを使用するのを防ぎます。再起動後は、ノード上の古いファイルを再利用するのではなく、現在のクレームから再生成します。
4. アップグレードとオブザーバビリティの計画
ドライバーライブラリ、kubelet、ノード、アプリケーションのバージョンマトリックスを文書化します。生成レイテンシー、失敗率、スキーマ拒否、ドライバーバージョン、Podの再起動を監視します。メタデータの内容を含めずにクレーム、リクエスト、ノードの識別子をログに記録します。互換性のあるスキーマ、feature gates、テスト済みのロールバックを使用してalpha版のアップグレードを制御します。
模範的な高品質の回答
デバイスメタデータをDRA割り当ての読み取り専用プロジェクションとして設計します。ドライバーは現在のResourceClaimとノードに対する非機密属性のみを書き込み、kubeletはそれらをバージョニングされたJSONに変換し、デバイス準備後に既知のパスに読み取り専用でマウントします。アプリケーションにはKubernetes APIの権限は一切不要です。書き込み前にはクレーム、リクエスト、ノードバインディング、許可リスト、サイズを検証し、書き込み後にはスキーマを検証します。障害発生時は不完全なファイルをマウントせず、可視化されたエラーを露出させます。解放時やPod削除時にクリーンアップし、再起動後に再生成します。この機能はalpha版であるため、サポート状況を検出し、feature gateを使用し、従来のパスや明示的な環境変数へのフォールバックを維持します。バージョン間での永続的なファイル安定性を安易に保証するのではなく、障害、レイテンシー、ドライバーのバージョンを監視します。
よくある間違い
- コンテナーにKubernetes APIアクセスや過度に広範なRBAC権限を付与してしまう。
- 認証情報や他テナントのデバイスデータを含む、すべてのドライバーフィールドを露出させてしまう。
- バージョンフィールド、許可リスト、JSONスキーマ検証を省略してしまう。
- Podの再起動やクレーム解放後も、ノード上の古いファイルを残してしまう。
- 生成失敗時に空のファイルをマウントし、アプリケーションにデバイスが使用可能だと誤認させてしまう。
- alpha機能をすべてのバージョンにわたる安定したAPIとして扱ってしまう。
フォローアップの質問と回答
なぜ環境変数を直接使用しないのですか？
環境変数は少数の静的な値には適していますが、複数のデバイス、構造化フィールド、ライフサイクルの変化に対応するには不向きです。読み取り専用のJSONファイルは構造化データを保持でき、明確なバージョンおよび障害セマンティクスを提供します。
マルチテナント間の情報漏洩をどのように防ぎますか？
クレーム、リクエスト、ノードを書き込みの認可境界として使用します。ドライバーが割り当てられたデバイスのみを書き込めるように制限し、機密フィールドをフィルタリングし、Podごとにマウントを分離し、別のクレームが読み取れないことをテストします。
alpha版の機能をどのようにリリースしますか？
クラスターのバージョン、機能の状態、ドライバーライブラリ、kubeletの互換性を確認します。feature gateの背後にある小規模なノードプールでカナリアリリースを実施し、アプリケーションまたはドライバーのフォールバックを維持し、ロールバック計画やアラートにスキーマ変更を含めます。