CNCFは2026年9月10日、ステートフルなKubernetesアプリケーションの災害復旧をテストすることを目的に、再現可能な3つの障害シナリオに基づくガイダンスを公開しました。バックアップが単にCompletedの状態で終了したことを監視するだけではありません。ラボのリポジトリからノートパソコン上で実行できる実験では、既知の内容を持つ4行のPostgreSQLアプリケーションを使用し、一般的な状態インジケーターに頼るのではなく、復旧の実際の結果を検証できるようにしました。
この資料は、CNCFアンバサダーのSaiyam Pathak氏とSaloni Narang氏が作成しました。対象範囲はKubernetes内でのアプリケーション状態の復旧に限定されており、コンプライアンスフレームワーク、製品比較、基盤となるクラウドまたはデータセンターインフラストラクチャの復旧は扱っていません。VeleroやCSI Snapshot APIなどのツールはシナリオのリファレンス実装として登場しますが、障害パターンは同じ役割を果たすツールにも当てはまります。
完了したバックアップは復旧可能性を証明しない
最初のシナリオでは、Kubernetesバックアップの構成要素を、YAML形式のリソース定義と永続ボリュームのデータに分離しました。ラボでは、2つのクラスタの外部にあるS3互換オブジェクトストアへデータを転送する仕組みとともにVeleroを使用しました。DataUploadオブジェクトを調査した結果、ボリュームのデータ47,989,888バイトが実際に外部ストアへ転送されたことが示されました。
PVCを含むネームスペースを削除した後、約2分で同じ4行が復旧されました。しかしCNCFは、ボリュームデータを保護しても、データベースのコピーが自動的にアプリケーション整合性を持つとは限らないと警告しています。アプリケーションにはflushまたはquiesceの処理が必要になる場合があります。また、異なるインフラストラクチャへ復旧する場合は、StorageClassの適合やその他の変換が必要になることがあり、それらはチームが設計し、テストしなければなりません。
さらに重要なのは、バックアップツールは既存のクラスタにリソースを復旧するのであって、ノード、ネットワーク、ロードバランサー、DNSを作成するわけではないという点です。そのため復旧計画では、コピーを受け入れる環境を明確に定義する必要があります。必要に応じて、Kubernetesの復旧をInfrastructure as CodeまたはCluster APIに担わせます。
Gitは意図を復元するが、保存された状態は復元しない
2番目のシナリオでは、本番クラスタを停止しました。一方、復旧クラスタはあらかじめ存在し、Gitリポジトリに接続されたGitOpsコントローラーと、共有ストアに接続されたバックアップツールを備えていました。アプリケーションの同期は成功し、StatefulSetは稼働状態となり、ダッシュボードも正常な状態を示しました。しかしデータベースへの問い合わせは、relation "attendees" does not existというエラーを返しました。
原因はKubernetesやGitOpsの障害ではありません。リポジトリに含まれていたのは定義だけだったため、コントローラーはStatefulSet、Service、そして新しい空のストレージボリュームを再作成しました。実際には、Gitが保存するのは宣言された状態またはチームの意図であり、バックアップが保存するのは実データです。どちらか一方だけでは、アプリケーション全体を復旧できません。
ラボでの復旧手順では、まず同期によって作成された空のアプリケーションを削除し、次にバックアップストアからアプリケーションとそのボリュームを復旧し、最後にデータを期待される内容と比較しました。本番の停止から検証済みデータの表示までの所要時間は、ライブ実験で4分、再テストでは2分弱でした。CNCFは、これらの数値はプログラム化された部分のみを対象としており、インシデントの発見、意思決定、トラフィックの切り替え、元の環境への復帰は含まないと説明しています。
個別のスナップショットでは、実際には存在しなかった復旧ポイントが生じる可能性がある
3番目のシナリオでは、相互に関連する2つのストレージボリュームを使用するアプリケーションをテストしました。1つは注文用、もう1つは支払い用です。ラボでは、各支払いが注文に対応するという条件の下で、毎秒5組の一致するペアを書き込みました。5秒の間隔を空けて2つの個別スナップショットを取得したところ、それぞれのスナップショットは単独では準備完了かつ正常に見えました。しかし復旧すると、最後に記録された注文は108352であるのに対し、支払いは108377件あり、対応する注文のない支払いが25件存在していました。
この結果は、個々のストレージ操作が成功しても、複数のストレージボリュームにまたがるアプリケーションの整合性は保証されないことを示しています。2つのスナップショットを組み合わせると、実際には存在しなかった時点を表す可能性があります。資料では、本番環境でバックアップツールが多数のPVCを1つずつ処理する場合、この差がさらに拡大する可能性があると指摘しています。
Kubernetes 1.36でGAになったVolumeGroupSnapshotは、単一のラベルでストレージボリュームを指定し、CSIを介して整合性のある復旧ポイントを要求する仕組みを提供します。調整された実験では、注文と支払いの最後の番号が109169で一致し、両者の関係も正常に検証されました。ただし、サポートはドライバーに依存します。通常のVolumeSnapshotをサポートしていても、グループスナップショットをサポートしているとは限りません。また、ラボで調査した主要なクラウドドライバーの大半は、2026年半ばまで実装していませんでした。さらに、CRD、スナップショット機能、関連するプラグインを明示的に有効化する必要があります。
復旧テストでは何を測定すべきか
- これまで稼働したことのないクリーンなターゲットへアプリケーション全体を復旧すること。Podを削除して再作成を監視するだけでは不十分です。
- リソースの状態やダッシュボードの色だけに頼らず、期待される内容を使ってデータとユーザーのアクセス経路を検証すること。
- 検出、意思決定、トラフィックの切り替え、場合によっては元の環境への復帰を含む実際の復旧時間を認識しながら、プロセス全体を時計で測定すること。
- 本番クラスタと復旧クラスタなど、独立した2つの障害ドメインを使用し、バックアップストアを両方の外部に配置すること。
編集上の見解：ツールと復旧シーケンスの間にあるギャップ
これらの実験が示す実務上の変化は、成功の基準を「バックアップが完了した」から「正しいデータが復旧され、アクセス可能になった」へ移すことです。より広い制約として、基盤となるKubernetesには、データ、アプリケーション、クラスタ、トラフィック、アイデンティティを調整するための共通契約が定義されておらず、アプリケーション全体と外部依存関係を記述する持続可能な標準復旧リソースも提供されていません。そのため、各レイヤーに成熟したツールが存在する場合でも、GitOps、バックアップ、インフラストラクチャ、ユーザーパスの境界は、依然としてチームの責任です。CNCFによると、CNCF TAG Operational ResilienceのCloud Native Business Continuityイニシアチブは、エコシステムのギャップ分析、復旧ガイダンス、リファレンスアーキテクチャに関する貢献を集めることを目指しています。