Kubernetesのバックアップ：クラウドネイティブワークロードの保護

すべてのノードをバックアップしていたお客様

お客様がVMのバックアップからKubernetesクラスターをVMのバックアップから復元しようとする様子を初めて目にしたとき、今後1年間は「コンテナがVMと同じように機能しない理由」を説明することに費やすことになるだろうと確信しました。 私たちは、バックアップに実際に何が含まれているか、何が欠けているか、そしてそれが彼らのRTOにとって何を意味するのかを、一つひとつ説明しなければなりませんでした。

顧客は、自分たちは保護されていると考えていました。クラスター内のすべてのノードのバックアップはありました。しかし、ワークロードを復旧させる手段は一切ありませんでした。 そのバックアップは、Kubernetes を実行している基盤となる VM をキャプチャしたものでした。しかし、ネームスペースの設定、YAML マニフェスト、ConfigMap や Secret、あるいは存在すべき状態を記録した etcd の状態などはキャプチャされていませんでした。基盤はあったものの、アプリケーションそのものが欠けていたのです。 

この記事は、もし時間を巻き戻してインシデント発生前にそのチームと話し合うことができるなら、私が伝えたい内容です。

Kubernetesのバックアップとは実際何なのか

Kubernetesのバックアップとは、コンテナ化されたアプリケーション、その永続的な状態、 およびそれらの実行方法を定義するKubernetesの設定を、完全なワークロードを同じクラスター、別のクラスター、あるいは別のクラウドに復元できるようにする形で、キャプチャおよび復元することです。

この区別が重要なのは、Kubernetesにおけるワークロードが単に実行中のコンテナだけではないからです。 これには、ステートフルなアプリケーションがデータを保存する永続ボリューム（PV）、ワークロードが存在するネームスペース、Deployments や StatefulSets を定義する YAML マニフェスト、環境固有の設定を保持する ConfigMaps や Secrets、 APIを拡張するカスタムリソース定義（CRD）、そしてクラスターが存在すべきと認識している状態を記録するetcdの状態などが含まれます。パーシステントボリュームのみをキャプチャするバックアップでは、データは復元できても、実行中のアプリケーションを復元することはできません。YAMLマニフェストのみをキャプチャするバックアップでは、構造は復元できても、状態は復元できません。どちらも一般的な手法です。 どちらも不十分です。

コンテナ化された本番ワークロードの導入は、もはや仮定の話ではありません。Googleは自社のインフラストラクチャ全体で、毎週数十億個のコンテナを起動しています。ほとんどのエンタープライズプラットフォームチームにとって、問題はもはや「Kubernetesワークロードにバックアップが必要かどうか」ではなく、「どのように正しくアーキテクチャを設計するか」となっています。 

コンテナにVMとは異なるバックアップが必要な理由

VMとコンテナには共通点が多いため、一部のバックアップ原則は適用可能です。どちらも仮想化された抽象化であり、スナップショット操作のためのAPIを公開しています。バックアップデータは、ソースに関わらずバックアップデータです。バックアッププラットフォームは、両方のバックアップを同じ保管庫に保存することが合理的です。

運用モデルには、データ保護の設計において重要な3つの違いがあります：

1. VMのストレージはシャットダウン後も保持されます。 コンテナのストレージは、多くの場合、シャットダウン後も保持されません。VMがシャットダウンしても、割り当てられたストレージは残ります。 Kubernetes ポッドがシャットダウンすると、kubelet はその emptyDir ボリュームや、非永続的なストレージを回収する場合があります。
2. VMは比較的安定しています。ポッドは設計上、一時的なものです。 Kubernetes は、ポッドの起動、停止、および再スケジューリングを通常の運用パターンとして行うように構築されています。 予測可能なスケジュールで長期間稼働するワークロードを前提としたバックアップは、Kubernetes には適していません。
3. VM は 1 つのアプリケーションを実行します。 Podはアプリケーションの一部を実行します。Kubernetesにおいて意味のあるアプリケーションの境界は、個々のPodではなく、ネームスペースまたはHelmリリースです。Podレベルのバックアップでは、アプリケーションが断片化されてしまいます。 

Kubernetesのバックアップをアーキテクチャ的に異なるものにする5つの課題

Data Center Intelligence Group (DCIG)のアナリストたちは、Kubernetes環境を保護するためにバックアップソフトウェアが解決しなければならない5つの具体的な課題を特定しました。 このフレームワークは説得力があり、Kubernetes ネイティブの保護と、VM 時代から流用されたバックアップツールとの違いを明確にしています。

1. 一時的なストレージ

ポッドがシャットダウンすると、Kubernetes はそのストレージを解放することがあります。その結果、データは事実上失われてしまいます。 バックアップにとってこれには2つの意味があります。まず、プラットフォームはコンテナ化されたアプリケーションが存在することを最初から把握している必要があります（手動登録ではなく自動検出）。また、バックアップはアプリケーションが実行されている間に実行されなければなりません。その期間は数日ではなく、数時間程度である可能性があります。 毎晩の時間帯を想定して設定されたバックアップスケジュールは、翌朝には存在しなくなる可能性のあるワークロードには適していません。

2. 予測不可能性

kube-schedulerは、リソースの可用性、アフィニティルール、テインツ、およびトレラランスに基づいて、Podの実行場所を決定します。オペレーターの好みに基づいて決定されるわけではありません。 ポッドは、いつでも、どのクラスターのどのノードでも実行される可能性があります。バックアッププラットフォームは、固定された場所を前提とするのではなく、ワークロードを追跡し、ワークロードごとに保護の判断を行う必要があります。すべてのコンテナにバックアップが必要なわけではありません。シャットダウン前など、特定のライフサイクルイベントでのみ保護が必要なコンテナもあります。

3. スケーラビリティ

本番環境の Kubernetes デプロイメントでは、数百のネームスペースにまたがり、数千のポッドが実行される場合があります。マルチクラスター環境では、その数は数百万に達することもあります。 コンテナは、VMよりもはるかに高い頻度で起動・停止を繰り返します。オペレーターの作業負荷、手動での登録、手動でのポリシー割り当て、手動での検証に比例してスケールするバックアッププラットフォームは、ボトルネックとなってしまいます。 Kubernetesのバックアップには、ワークロードに合わせて拡張・縮小する、クラウドネイティブで動的にスケーリングするバックアップインフラストラクチャが必要です。

4. 範囲：アプリケーションに加え、コントロールプレーン

コンテナ化されたアプリケーションは重要ですが、それらをオーケストレーションするコントロールプレーンの状態がなければ無意味です。 etcdは、クラスターの「真実の源」を保持しています。どのDeploymentが存在するか、どのConfigMapやSecretがどのワークロードに紐付けられているか、どのCRDがAPIを拡張しているか、どのRBACルールがアクセスを管理しているかといった情報です。Kubernetesの運用が成熟した環境では、GitOpsを通じてコントロールプレーンをスクリプト化し、オンデマンドで再構築することができます。 成熟度の低い環境では、両方のレイヤーをキャプチャするためにバックアッププラットフォームに依存しています。

5. リカバリの複雑さ

リカバリでは、これまでの課題がすべて一度に表面化します。 プラットフォームは、どのバックアップを復元すべきか（日付、クラスター、ネームスペース、アプリケーションコンテキスト）を特定し、同時に起動する必要がある可能性のあるコンテナ化されたアプリケーション間の相互依存関係を処理し、さらに、バックアップされたものとは異なるKubernetesデプロイメントへの復元もますます求められるようになっています。 異なるクラスター、異なるクラウド、異なる K8s バージョン、場合によっては異なるディストリビューション（EKS 対 AKS 対 GKE 対オンプレミス）などです。バックアッププラットフォームは、ソースと宛先の双方について十分な情報を把握し、それらを相互に変換できる必要があります。 

完全なKubernetesバックアップが保護すべきもの

完全なKubernetesバックアップは、4つの異なるカテゴリを網羅します。バックアップツールによって、実際に処理できるカテゴリの数は大きく異なります。

コンテナのラベルとメタデータの役割

Kubernetesは、プラットフォームに必要な保護メカニズム、すなわちすべてのワークロードに付随するラベルとメタデータを提供します。 コンテナが起動すると、Kubernetes ノードサービスは既存のメタデータを読み取り、どのリソースが関連しているかを識別するキーと値のペアを追加し、API を監視しているあらゆる対象に対してそれらのラベルを公開します。

適切に設計されたバックアッププラットフォームは、コンテナの起動を監視し、メタデータをリアルタイムで読み取ります。 ラベルは、プラットフォームに対して、何をバックアップすべきか（ワークロードがポリシーの基準を満たしているか）、いつバックアップすべきか（それらのラベルに紐付けられたポリシーに従って）、どのようにバックアップすべきか（どの関連リソースを連携して取得する必要があるか）を伝えます。 その後、プラットフォームは kube-scheduler との統合を通じてバックアップジョブをスケジューリングでき、Kubernetes 自体がポッドの実行場所を決定するのと同じように、バックアップ処理の実行場所を決定できるようになります。

このパターンは、従来のバックアップで使用されるオペレーター主導のモデルとは異なります。従来のモデルでは、人間または設定ファイルによって、何をバックアップするかが宣言されます。 Kubernetesネイティブモデルでは、ワークロードがラベルを通じて自らを宣言し、バックアッププラットフォームがそれに応答します。新しいワークロードは自動的に保護の対象となります。 廃止されたワークロードは、バックアップ負荷を発生させなくなります。オペレーターの役割は、インベントリの管理ではなく、ポリシーの設定となります。

クラスタ間リカバリとマルチクラウド Kubernetes

シングルクラスタのリカバリ（ワークロードを元のクラスタに復元する）は、単純なケースです。 ほとんどのエンタープライズ向けKubernetes導入環境では、この単純なケースが長く続くことはありません。バックアッププラットフォームが現在対応する必要がある、3つの実世界のシナリオがあります。

EKS、AKS、GKE、およびオンプレミスディストリビューション間のワークロード移行。 クラスターのライフサイクルに関する決定（コスト最適化、リージョンの変更、ディストリビューションの選定）により、ワークロードの移動が定期的に必要となります。ディストリビューションを跨いだ復元をサポートするバックアップがあれば、こうした移行作業を数週間かかるプロジェクトから日常的な運用へと変えることができます。

別のリージョンへの災害復旧。 プライマリリージョンに障害が発生した場合、復旧用ワークロードは別のリージョンのクラスターで起動されます。理想的には、運用チームが日常的に使用しているのと同じバックアップデータ、同じポリシー、同じ管理プレーンが維持されることが望まれます。

テストおよび開発環境のクローン作成。 本番ワークロードを（合成データまたは匿名化されたデータを使用して）テストクラスターに復元することは、正確な本番導入前のテストを行う上で一般的な要件です。 DRをサポートする、プロジェクト横断・リージョン横断の復元メカニズムは、環境のクローン作成もサポートします。

Kubernetesバックアップにおけるよくある間違い

Kubernetesデータ保護市場には、機能マトリックス上では十分に見えるものの、本番環境の複雑さに直面すると機能しなくなる製品が溢れています。 注意すべき3つのパターンです。

間違い1：永続ストレージのみのバックアップ

多くの「Kubernetesバックアップ」ツールは、PVのスナップショットを取得するだけで、それだけで完全なバックアップだと主張しています。PVのスナップショットは必要ですが、それだけでは不十分です。 ネームスペースの設定、YAMLマニフェスト、ConfigMap、シークレット、およびオペレーターが定義したカスタムリソースがなければ、復元されたパーシステントボリュームはコンテキストのないデータに過ぎません。ストレージのみのバックアップは有用な基本機能ですが、Kubernetesのバックアップ戦略とは言えません。

間違い2： レガシーなバックアップ製品への後付けプラグイン

2019年から2021年にかけて、既存のバックアップベンダーが「Kubernetesサポート」を追加した際、多くのベンダーが、VM時代のアーキテクチャをKubernetes APIを呼び出すように適応させたプラグインを提供しました。 その結果、コンテナは通常、個別のインフラストラクチャを必要とする独立したワークロードとして扱われ、Kubernetesへの移行によって解消されるはずだったサイロ化されたデータ保護が、まさに生み出されてしまいます。Evaluator GroupのKrista Macomber氏が『Containers Data Protection Fundamentals』の入門書で指摘しているように、Kubernetesを単なる追加機能として扱うことは、プラットフォームチームが期待する運用モデルを実現することはほとんどありません。 

間違い3：コントロールプレーンの見落とし

オンデマンドでソース管理からコントロールプレーンを再構築するGitOps環境では、コントロールプレーンのバックアップを安全に省略できます。 ほとんどのKubernetesデプロイメントは、純粋なGitOpsではありません。クラスターには、手動で適用された設定、kubectlを通じてインストールされたオペレーター、ソース管理に含まれていないCRD、そして（当然のことながら）コミットされたことのないシークレットなどが蓄積されています。 etcdが失われると、クラスターにデプロイされた履歴も失われてしまいます。保護戦略には、コントロールプレーンのバックアップを含めるか、GitOpsに関する運用規律を徹底するかのいずれかが必要です。両方とも行わないという選択肢はありません。

Kubernetesのバックアップに関するよくある質問

ステートレスなワークロードにはバックアップが必要ですか？ 

ステートレスなワークロードにはバックアップすべきアプリケーションデータはありませんが、キャプチャする価値のある構成（Deployment、ConfigMap、Service定義、Ingressルール）が存在します。ネームスペースが破壊された場合、コンテナイメージからステートレスなワークロードを復元するのは迅速ですが、それは構成マニフェストが手元にある場合に限られます。 ほとんどのチームは、クラスターの障害後に記憶を頼りにサービスを再作成しなければならなくなった2回目には、このことに気づきます。

CSIスナップショットについてはどうでしょうか？

CSIスナップショットは、バックアッププラットフォームが内部で活用すべき有用な機能です。これらは、ストレージ層における永続ボリュームの特定時点のコピーをキャプチャします。 しかし、CSIスナップショットだけではバックアップ戦略とはなりません。これらはストレージバックエンドに紐づいており、ネームスペースの設定をキャプチャせず、追加のツールなしではクラスター間で移動できず、通常は存在するクラスターの運命を共にする（クラスターが失われれば、スナップショットも失われる）からです。 CSIスナップショットをオーケストレーションし、ワークロードの残りの部分をキャプチャするバックアッププラットフォームこそが、適切なパターンです。 

あるKubernetesディストリビューションから別のディストリビューションへバックアップを復元することは可能でしょうか？

それはバックアッププラットフォームによって異なります。ディストリビューションごとに、API拡張機能、デフォルトのIngressコントローラー、ストレージクラス、およびセキュリティのデフォルト設定が異なります。 Kubernetes オブジェクトレベル（Deployments、Services、PVC）でワークロードをキャプチャし、復元時にターゲット固有の設定を変換するプラットフォームであれば、EKS、AKS、GKE、およびオンプレミスクラスター間で、管理可能な労力でワークロードを移行できます。 クラウドプロバイダーレベルでストレージスナップショットをキャプチャするプラットフォームでは、これはできません。スナップショットはプロバイダーに紐づいているためです。

どこから始めるか

現在Kubernetesの保護を行っている場合は、今四半期中にテーブルトップ演習を実施してください。 最も重要なコンテナ化アプリケーションを選び、元のクラスターが利用できなくなった場合に、別のリージョンにある別のクラスターへどのように復旧させるかをシミュレーションしてください。シミュレーション中にチームメンバーが「手動で」という言葉を使った場合、そこに課題があるということです。