質問とコンテキスト
あなたは、OCI イメージからモデル、ボキャブラリ、またはルールパッケージを読み取り専用ファイルとしてマウントする必要がある推論サービスを担当しています。ダイジェスト固定、段階的ロールアウト、診断可能な起動失敗、および迅速なロールバックを備えたリリースアプローチを設計してください。Kubernetes の image volume の境界について説明してください。
面接官が評価するポイント
- アーティファクトの同一性、スケジューリングの互換性、およびロールアウト制御を分離できているか。
reference、pullPolicy、起動時の解決、および読み取り専用マウントを正確に説明できているか。- 単に YAML を記述するだけでなく、アドミッション、オブザーバビリティ、ロールバック、およびノードキャッシュの動作を網羅できているか。
- バージョン、ランタイム、およびレジストリ権限を前提条件として特定できているか。
最初に確認すべき明確化の質問
アーティファクトのライフサイクル
モデルまたはルールパッケージのビルド、署名、保持は誰が行いますか？本番環境ではイミュータブルなダイジェストを使用する必要がありますか、それともミュータブルなタグに従うことが許容されますか？アーティファクトのサイズ、更新頻度、および同時起動数はどのくらいですか？
クラスターとランタイム
利用可能なクラスターバージョン、ノード OS、コンテナランタイム、およびレジストリ認証情報は何ですか？アップグレード中にノードバージョンが混在する可能性はありますか？
セキュリティとロールバック
誰が Pod の reference を変更できますか？レジストリはプライベートアクセスと監査ログを提供しますか？ロールバックには前回のダイジェストのみが必要ですか、それとも再現可能な署名、設定、および互換性のエビデンスも必要ですか？
30秒での回答
署名付きの OCI アーティファクトをビルドし、そのダイジェストをリリースマニフェストに固定します。Pod は image volume を介してそれを読み取り専用でマウントし、アドミッションポリシーによって未承認のレジストリやダイジェストを拒否します。コントローラーは互換性のあるノードに制限して Pod をバッチ単位でロールアウトし、プル、マウント、アプリケーションのセルフチェック、およびリクエストメトリクスを監視します。障害発生時には、以前のワークロードとダイジェストを復元します。参照されていないアーティファクトは、保持要件と監査要件が満たされた後にのみガベージコレクションされます。
詳細なソリューション
1. アーティファクトの同一性をイミュータブルにする
reference は OCI イメージ参照を指すことができます。本番環境ではミュータブルなタグではなくダイジェストを使用する必要があります。署名、SBOM、およびビルドの出所（provenance）をそのダイジェストに紐付けます。ダイジェスト、パイプライン、互換性マトリクス、および所有者をリリースレコードに保存します。ダイジェスト固定によりリリースは再現可能になりますが、脆弱性スキャンや署名検証に代わるものではありません。
2. Pod のマウントを定義する
以下のボリュームがコンテナ内に読み取り専用でマウントされます。
volumes:
- name: model
image:
reference: registry.example.com/models/ranker@sha256:0123456789abcdef
pullPolicy: IfNotPresent
containers:
- name: api
image: registry.example.com/services/ranker-api@sha256:abcdef0123456789
volumeMounts:
- name: model
mountPath: /opt/model
readOnly: trueKubernetes のドキュメントでは、image volume は kubelet ホスト上で利用可能にされた OCI オブジェクトであり、コンテンツは読み取り専用であると説明されています。Always、Never、および IfNotPresent は、毎回プルする、プルしない、ローカルに存在しない場合にプルすることを表します。本番環境では一般的に固定ダイジェストと IfNotPresent を組み合わせ、アドミッションとノード制御がサプライチェーンの境界を定義します。
3. アドミッションと権限のチェックを追加する
アドミッションポリシーは、レジストリドメイン、ダイジェスト形式、署名、脆弱性のしきい値、およびサービスとアーティファクトの互換性をチェックします。サービスアカウントは必要なレジストリ権限のみを受け取ります。ノードのアイデンティティ、プルシークレット、および監査ログは個別に管理されたままとなります。拒否される場合は、アプリケーションコンテナの失敗を待つのではなく、Pod 作成時にその原因を説明する必要があります。
4. ノードとランタイムの互換性を検証する
image volume には、ノード、コンテナランタイム、およびクラスターバージョンからのサポートが必要です。ノードラベルとスケジューリング制約によってケーパビリティを表現し、アップグレード中は互換性のあるノード上で小さなバッチをテストします。コントロールプレーンがそのフィールドを受け入れたからといって、すべてのノードがそれをマウントできるとは限りません。バージョン混在クラスターでは、明示的な最小ケーパビリティとダウングレード計画が必要です。
5. ロールアウトとキャッシュウォーミングを計画する
コントローラーは小さなカナリアから開始し、Pod の準備完了、アーティファクトの存在、ダイジェストチェック、およびアプリケーションのセルフチェックを検証してから、Deployment を拡大します。プル失敗はコンテナの起動をブロックし、通常の再試行バックオフに従うため、レジストリ認証、ネットワーク、ノードディスク、および破損したアーティファクトによる失敗を区別します。ターゲットノードのキャッシュをウォーミングすることでレイテンシを短縮できますが、アドミッションやダイジェストのチェックをバイパスすることはできません。
6. 起動とビジネス成果を監視する
ワークロード、Pod、ノード、アーティファクトダイジェスト、およびロールアウトバッチを関連付けます。プルレイテンシ、起動バックオフ、マウントエラー、ディスク使用量、セルフチェック、およびリクエストエラー率を監視します。また、Kubernetes のドキュメントには、再作成された Pod はリモートコンテンツを再度解決すると記載されているため、新しい各 Pod で実際に使用されたダイジェストを記録し、相違がある場合はアラートを発報します。
7. ロールバックとガベージコレクション
ロールバックでは、承認済みの古いダイジェストと一致するサービスバージョンに切り替え、その署名、SBOM、および設定を保持します。古いアーティファクトが引き続き取得可能であることを確認します。ノードキャッシュが恒久的であると思い込んではいけません。アクティブな参照が存在せず、保持期間が経過し、監査レコードがアーカイブされた後にのみガベージコレクションを実行します。ロールバックや調査に関係するダイジェストを保護します。
優れた回答の例
私はモデルイメージをイミュータブルなリリースとして扱います。ビルドによって SBOM、署名、およびダイジェストが生成されます。リリースレコードにはそのダイジェストとサービスの互換性マトリクスが保存されます。Pod は image volume を読み取り専用でマウントし、アドミッションによってレジストリを制限し署名を検証します。コントローラーはノードケーパビリティとカナリアバッチによって進行します。Kubernetes は Pod の起動時に image volume を準備し、プルの失敗は起動をブロックするため、認証、ネットワーク、ディスク、およびバックオフのシグナルを分離します。新しい各 Pod は実際のダイジェストを記録し、セルフチェックとリクエストメトリクスが成功した場合にのみロールアウトを進めます。障害時には以前のダイジェストを復元し、クリーンアップはアーティファクトが参照されなくなり保持期間を過ぎるまで待機します。
よくある間違い
- ミュータビリティやダイジェスト固定について議論せず、イメージタグのみを使用すること。
- image volume を書き込み可能な共有ディスクとして扱うこと。
- クラスター、ランタイム、またはノードのバージョンに関係なく、すべてのノードがこの機能をサポートしていると思い込むこと。
- プルバックオフ、マウントエラー、およびアーティファクトチェックを無視して、利用可能なレプリカ数のみを監視すること。
- 署名、アドミッション、または監査の制御をバイパスしてキャッシュをウォーミングすること。
- 互換性のあるアーティファクトダイジェストを復元せずにサービスイメージのみをロールバックすること。
フォローアップの質問と回答
なぜ ConfigMap や通常の PersistentVolume ではないのですか？
OCI サプライチェーン制御を必要とする、バージョン管理された大規模なアセットには image volume が適しています。ConfigMap は小さな設定に適しており、PersistentVolume は書き込み可能または Pod 間で永続化するデータに適しています。最終的な選択は、サイズ、更新方法、権限、およびリカバリオブジェクティブに依存します。
Always の方が安全ですか？
Always は起動ごとにプルを行うため、古いキャッシュのリスクは軽減されますが、起動レイテンシ、レジストリ依存性、および障害面が増加します。プルポリシーの変更単体よりも、ダイジェスト固定、署名アドミッション、および可観測なロールバックの方が通常は重要です。
Pod が再作成されると何が起こりますか？
再作成された Pod はリモート参照を解決し、ボリュームを再度準備します。参照、解決されたダイジェスト、およびイベントをリリース監査データに記録します。古いノードキャッシュが新しい Pod のコンテンツを決定すると仮定してはいけません。
subPath はどのような場合に使用しますか？
アーティファクト内のディレクトリを特定のパスに表示させる必要がある場合に subPath を使用します。現在の Kubernetes ドキュメントでは、image volume の subPath および subPathExpr のサポートは v1.33 から開始されると記載されているため、ターゲットクラスターのバージョンを確認してください。
digest-status ケーパビリティの違いにはどのように対処しますか？
現在の Kubernetes ドキュメントでは、image volume は v1.36 ドキュメントで安定版となっていますが、ImageVolumeWithDigest ステータスフィールドはまだアルファ版とマークされており、対応するバージョンとフィーチャーゲートに依存します。ロールアウトにおいて、そのステータスフィールドが普遍的に利用可能であると想定してはなりません。