プロンプトとコンテキスト
Kubernetes v1.36において、VolumeGroupSnapshot、VolumeGroupSnapshotContent、およびVolumeGroupSnapshotClassがgroupsnapshot.storage.k8s.io/v1へと昇格しました。面接官は、複数のPersistentVolumeClaimがどのようにして1つのリカバリポイントを形成するのか、CSIドライバが何を担うのか、そしてストレージレベルとアプリケーションレベルの整合性のギャップをどのように処理するのかを知りたがっています。
面接官が評価するポイント
- クラッシュ整合性、アプリケーション整合性、結果整合性を区別できているか。
- Kubernetesコントローラ、external snapshot controller、およびCSIドライバの境界を説明できるか。
- CSIのサポート、容量、トポロジ、スナップショットのライフサイクル制限などの前提条件を特定できているか。
- リカバリ目標、訓練指標、障害時のロールバックを実行可能なプロセスに落とし込めているか。
最初に確認すべき質問
データベースがオンラインバックアップをサポートしているか、すべてのボリュームが同一のCSIドライバを使用しているか、求められるRPO、RTO、およびゾーン間での動作を確認します。また、ストレージシステムが書き込み順序を保証しているか、あるいはアプリケーション側で最初にフラッシュ、フリーズ、または書き込みの一時停止が必要かどうかも確認します。
30秒での回答
私は4つのレイヤーを使用します。アプリケーションが整合性ポイントを作成し、KubernetesがVolumeGroupSnapshotでPVCセットを記録し、CSIドライバがストレージ内でグループスナップショットを作成し、リカバリ時に新しいボリュームを復元して検証します。このAPIはv1.36でGAとなりましたが、これはクラッシュ整合性のあるボリュームスナップショットを協調制御するものであり、データベースログ、鍵管理、定期的なリカバリ訓練を代替するものではありません。
ステップごとの詳細解説
1. 整合性ポイントの確立
データベースは、書き込みの一時的なフリーズ、WALのフラッシュ、チェックポイントの作成など、検証可能なバックアップアクションを実行します。グループスナップショットを作成する前に、トランザクション位置、スナップショット時刻、アプリケーションのバージョンを記録します。アプリケーションの協調制御がないストレージのみのスナップショットは、ディスク上は整合していてもビジネス状態としては不整合になる可能性があります。
2. グループスナップショットの作成と監視
1つのデータベースインスタンスのPVCに対してVolumeGroupSnapshotを作成し、readyステータスになるのを待ちます。コントローラはKubernetesオブジェクトを協調制御し、CSIドライバはストレージ操作を実行します。これにはボリュームグループスナップショット拡張APIのサポートが必要です。一部の成功を復元可能と誤認しないよう、各メンバーのスナップショットハンドル、容量、トポロジ、エラーを記録します。
3. リカバリと検証
データベースとボリュームのマッピングを維持しながら、すべてのメンバーに対して新しいPVCを作成します。分離された環境でデータベースを起動し、WALの位置、テーブル件数、チェックサム、主要なビジネスクエリを検証した上で、トラフィックを切り替えます。ゾーン間リカバリでは、スナップショットのレプリカが読み取り可能であること、およびCSIドライバがターゲットのトポロジを受け入れることも確認する必要があります。
4. 運用上の境界
保持期間、暗号化、アクセス制御を定義し、スナップショットの所要時間と失敗率を監視します。スナップショットは恒久的なアーカイブではなくリカバリ用の素材として扱い、独立したメディアにエクスポートして訓練を通じて実際のRPOとRTOを測定します。PVC、スナップショットオブジェクト、またはバックエンドオブジェクトを削除する前に、Reclaim Policyによって使用中のリカバリポイントが削除されないことを確認します。
優れた回答例
まずリカバリ目標を定義し、単一のCSIドライバによって管理されるPVCを選択します。アプリケーションはチェックポイントを作成してWAL位置を記録し、必要に応じて書き込みを一時的に停止します。その後、groupsnapshot.storage.k8s.io/v1 VolumeGroupSnapshotを作成します。コントローラがKubernetesオブジェクトを協調制御する一方で、CSIドライバとストレージシステムがグループセマンティクスを提供します。ドライバのバージョン、トポロジ、容量、スナップショットのクォータを検証し、各メンバーのready状態についてアラートを設定します。
リカバリにおいて本番ボリュームを上書きすることは決してありません。グループスナップショットから新しいPVCを作成し、分離されたネームスペースでデータベースを起動し、WAL、チェックサム、ビジネスクエリを検証してから初めてトラフィックを切り替えます。いずれかのメンバーが失敗した場合、そのグループは使用不可となりワークフローはロールバックされます。部分的なスナップショットを完全なバックアップと呼ぶことはありません。定期的な訓練によってRPOとRTOを証明し、独立したアーカイブ、暗号化、最小権限の原則により、スナップショットシステムが単一障害点や情報漏洩の原因にならないようにします。
よくある間違い
- GAになったことで、すべてのストレージドライバがこの機能を自動的にサポートすると想定すること（依然としてCSIおよびストレージの実装に依存します）。
- 作成処理のみを説明し、メンバーレベルの障害、トポロジ、ライフサイクルの処理を考慮しないこと。
- クラッシュ整合性をアプリケーション整合性と呼び、フラッシュ、WAL、チェックポイントを省略すること。
- スナップショットのメタデータのみを保持し、復元されたデータベースを分離された環境で一度も起動しないこと。
フォローアップの質問と回答
メンバーボリュームの1つがスナップショットの作成に失敗した場合はどうなりますか？
グループスナップショットを使用不可としてマークし、イベントと作成されたハンドルを保持し、孤立したリソースをクリーンアップして再試行します。リカバリは完全なメンバーセットのみを受け入れ、部分的な成功はアラート通知および容量監査のために報告されます。
なぜ各PVCを個別にスナップショットしないのですか？
個別のスナップショットには共有されたリカバリポイントがないため、ボリューム間で書き込み順序が乖離する可能性があります。グループスナップショットはメンバーセットとグループ操作をストレージに委譲しますが、ビジネス整合性を保つためには依然としてアプリケーションのチェックポイントが必要です。
計画がRPOとRTOを満たしていることをどのように証明しますか？
定期的なスケジュールで分離されたクラスターにリカバリを実施し、チェックポイントからクエリ可能なサービスになるまでの時間、データ位置のドリフト、失敗率を記録します。訓練結果をリリースの判定基準（release gate）とし、しきい値を超えた場合は、スナップショットの頻度、アーカイブパス、または切り替え手順を調整します。