Kubernetesインフラを確実にバックアップするための5つのポイント：何を考慮すればいいのか？

Kubernetesが普及するにつれ、バックアップの重要性が増している。だが、「何を」「どのように」バックアップすればいいのか。

[Stephen Pritchard，Computer Weekly]

iStock.com/5432action

　コンテナの普及により、コンテナをどのように管理・保護するか、コンテナのデータをどのようにバックアップするかといった疑問が浮き彫りになった。

　コンテナは本来マイクロサービスと関連付けられていたが、今でははるかに広範囲のプロセスを運用するように拡張され、本格的なアプリケーションさえ運用するようになっている。

関連記事

Dockerのバックアップ戦略――Dockerの何を保護すべきか？

コンテナ用の永続ストレージに要求される3つの要件

基礎から分かるコンテナのネットワーク接続性

Kubernetesによるコンテナストレージの管理

Dockerで永続ストレージを実現するDockerボリュームとバインドマウント

　初期のコンテナはステートレスな設計だった。デプロイが迅速、移動が容易、廃棄が簡単だからだ。だがコンテナの使い方が進化するにつれ、ステートフルなコンテナが増えてきた。ステートフルなコンテナには永続ストレージが必要だ。そして永続ストレージにはバックアップが不可欠だ。

　ミッションクリティカルなアプリケーションを実行するコンテナのクラスタは復元も可能でなければならない。つまりコンテナの状態、コンテナのデータ、コンテナのオーケストレーション方法を復元できる必要がある。

バックアップのギャップ

　コンテナは、バックアップにとってかなり問題になり得る存在だ。DevOpsチームがコンテナを管理していると、バックアップとリカバリーを担当するITチームには見えないことがある。

　コンテナはローカルやクラウドなどさまざまな場所で運用されるため、仮想マシン（VM）をバックアップする従来のツールはコンテナには適さない。VMをバックアップするツールは依然としてドライブやボリュームをバックアップするよう設計されている。

　ESGのアナリスト、クリストフ・ベルトラン氏は次のように話す。「コンテナで実行されるアプリケーションが極めて重要なデータを生成する可能性がある。この事実が、バックアップとリカバリーの必要性を強く示している」

　本稿では、Kubernetesインフラを保護するに当たって最も重要な5つの事項を解説する。

1．常にバックアップする必要があるか

　現時点での答えは、ほぼ常に「必要がある」だ。初期のステートレスなコンテナは、コンテナに与えられたタスク（データセットの処理など）が終わると破棄されていた。こうしたユースケースもまだ存在するが、企業はコンテナやクラスタが停止した後、それを作り直し、そのデータにアクセスできるようにしたいと考える傾向が強くなっている。

　ベルトラン氏によると、開発中のコンテナと運用中のコンテナをサポートする強力なバックアップポリシーが必要だという。データ保護ツールはKubernetesインフラを認識する必要がある。例えばコンテナやクラスタが開発段階から運用段階へと昇格する際にポリシーの調整が必要だ。

2．Kubernetesインフラで保護すべきもの

　コンテナのユーザーは、オーケストレーションしているクラスタを保護する必要がある。これにはオンプレミスの操作、「Linux」や「Windows」での操作、クラウドでの操作、さらにはKubernetes PaaSのマネージドインスタンス（「Google Cloud Platform」「Amazon Web Services」「Microsoft Azure」など）を利用した操作が含まれる。オーケストレーションを保護できないと、ビジネスプロセスやアプリケーションを再構築できなくなるというリスクが生じる。

　ステートフルコンポーネントはキー／バリューデータベース「etcd」に保持される。そのため、コンテナに永続ストレージがリンクされている場合や環境の状態を記録している場合は、etcdコントロールプレーンが最も重要な部分になる。

　その後、ポッド、デプロイメント、ステートフルセット、ワークロードを含めてアプリケーションを保護する必要がある。

　永続ボリュームは、PVC（Persistent Volume Claim）と共に保護する必要がある。最後に、Kubernetes内部で運用されるカスタムリソース定義、名前空間定義、コンテナイメージレジストリのバックアップも必要だ。

　ワーカーノードは容易にスピンアップするように設計されている。特にローカルハードウェアでコンテナを実行している場合は、停止後にこれが運用環境でも動作することを確認する必要がある。

3．Kubernetesインフラを保護する主な手法

　ローレベルな方法としては、開発者が「cron」（訳注：UNIX系OSの実行スケジュール管理コマンド）を使ってetcdのスナップショットを作成し、構成とデータをキャプチャーすることができる。Kubernetesデプロイメントはgitリポジトリから再作成することも可能だ。

　オープンソースツールの「kube-backup」はKubernetesの構成済みのリソースをgitリポジトリにエクスポートする。ただしこのアプローチは拡張性がほとんどなく、永続ボリュームもサポートしない。

　スナップショットは運用環境のKubernetesをバックアップする主なツールになる。ただし、コンテナのバックアップ要件が他と異なるのはその頻度だ。Commvault Ventureの「Metallic」は完全バックアップと増分バックアップを提供する。Commvault Ventureはこのアプローチを「永久増分バックアップ」と説明している。これを完全バックアップの構築に使うことができる。

　重要なデータをノードのローカルドライブ外に確実に保存することで、リカバリーの信頼性も高くなる。

4．Kubernetesの主要バックアップツール

　大手ストレージサプライヤーの大半が、何らかの形式でコンテナの保護をサポートしている。だがKubernetesインフラ全体のバックアップにはより特殊なツールが必要だ。

　Commvault VentureはSaaSの「Metallic VM & Kubernetes Backup」を通じてKubernetesをサポートする。このサービスは「AKS」（Azure Kubernetes Service）、「Amazon EKS」（Elastic Kubernetes Service）、「Red Hat OpenShift」「VMware Tanzu」と連携する。

　Kasten（Veeam Software傘下）は、Kubernetesデータ管理サプライヤーだ。同社の「K10」はクラウドとオンプレミスで動作する。

　Portworx（Pure Storage傘下）の「PX-Backup」はコンテナ、クラスタ、Kubernetes名前空間全体をバックアップできる。

　Trilioの「TrilioVault」はクラウドネイティブのデータ保護アプリケーションで、OpenShiftおよびKubernetesと連携する。このアプリケーションはクラウドプラットフォームに依存しない。

　オープンソースツールの「Velero」（旧「Heptio ARK」）は、オンプレミスでもクラウドでもKubernetesクラスタと永続ストレージのバックアップとリカバリーを可能にする。

5．既存の災害復旧およびバックアッププロセスにどう組み込むか

　Kubernetes用のバックアップ＆リカバリーインフラを全く新たに構築するとリソースが大量に必要になり、保護にギャップが残る恐れがある。

　ESGのベルトラン氏は次のように助言する。「現在付き合いのあるバックアップベンダーがソリューションを保有しているならプロセスが簡略化されるため、それをチェックする価値はある。だが、大規模に機能することを確認する必要がある。ネイティブコンテナバックアップを既存の災害復旧に統合できれば役に立つ」

　Kubernetesが主流になるにつれ、運用環境での保護も容易になるだろう。