
Kubernetesが最初に注目されだした頃、ワークロードはステートレスという想定でした。アプリケーションのスケールイン、スケールアウトはいたって簡単で、コンテナがシャットダウンされても何も問題なく、また別のコンテナが起動されれば、アプリケーションの実行に一切支障はありませんでした。
しかし、その後、状況は変わり、Kubernetesで実行されるソリューションの大半は永続的データを運用するものとなりました。データベース、メッセージキュー、アナリティクス ツールなど、ワークロードはコンテナやノードがシャットダウンされた後も引き続きデータを必要とします。当然ながら、バックアップとリカバリの重要性も一段と増しています。
永続的データの課題
Kubernetesはアプリケーション自体の管理には非常に優れています。しかし、永続的データを保護するとなると、独自のバックアップ手段を持ち合わせてはいません。Persistent Volume(PV:永続ボリューム)とPersistent Volume Claim(PVC:永続ボリュームクレーム)によって、安定したストレージを確保することは可能ですが、ストレージ自体が破損または削除されたり、人的エラーで失われてしまったりした場合はどうすることもできません。
これは、Kubernetesを大規模な環境に導入している企業などには、大きなリスクとなります。データを失うことは絶対に許されないので、可用性はKubernetesで効率よく保たれるものの、バックアップ ソリューションは別に用意しなければなりません。
Kastenを使用した永続的データの保護
そこで、Kubernetesの運用には、Kubernetes用に設計されたバックアップ/障害復旧(DR)ソリューションの活用が成功への重要な鍵となります。そのようなソリューションの代表格として、本稿ではVeeam Kastenの機能を解説します。
Kastenの機能は、以下の三つの柱からなります。
● バックアップ ― 永続ボリュームとそれにともなうKubernetesリソースをバックアップします。
● リストア ― 何らかの理由でデータが破損されたり、失われたりした場合にデータを復元できるようにします。
● マイグレーション ― アプリケーションやデータをクラスタやクラウドプロバイダをまたがって移行できるようにします。
Kastenの最大の特長は、Kubernetesの存在を丸ごとそのまま理解することです。ストレージをバックアップするだけでなく、アプリケーションのメタデータ、ネームスペース、シークレット、設定の詳細など、アプリケーションを実行するために必要なすべてのリソースを丸ごとキャプチャーするので、部分的な対応ではなく、全体の管理を一任することができます。
Azure環境でのKastenのセットアップ
Kastenのセットアップ方法は、使用している仮想化環境やクラウドプロバイダによって多少異なります。たとえば、Azure環境にセットアップするもっとも簡単な方法は、AzureのService Principal(サービスプリンシパル)を使用して、Helmからインストールすることです。
なお、Azureでのアプリケーション登録は事前に完了している必要があります。インストールする際に、アプリケーションIDやディレクトリIDなどの情報をそこから取得することになります。

必要な情報が取得できたら、以下のHelmコマンドを実行します。これにより、ネームスペース“kasten-io”にKastenがインストールされます。
helm install k10 kasten/k10 --namespace=kasten-io \ --set secrets.azureTenantId=<tenantID> \ --set secrets.azureClientId=<azureclient_id> \ --set secrets.azureClientSecret=<azureclientsecret>
KastenがPodのデプロイメントを行っている間に、以下のコマンドでインストールの進捗状況を確認できます。
kubectl get pods--namespacekasten-io--watch
Kasten K10ダッシュボードは、デフォルトではクラスタ外に公開されていません。以下のコマンドを使用してローカルポートを割り当てる必要があります。
kubectl--namespacekasten-io port-forward service/gateway8080:80
After running it,openyour browser at the following address and you will access the dashboard.http://127.0.0.1:8080/k10/#/
以下の画面が表示されたら、構成画面に進む前に、いくつかユーザー情報を入力する必要があります。

ダッシュボードにログインしたら、Kubernetes内のネームスペースに直接マッピングされたすべてのアプリケーションが表示されます。さらに、Pods、VirtualMachines、StatefulSets、Deployments、DeploymentConfigsがワークロードとして分類されます。

”Unmanaged”は、ネームスペース内のサービスで、まだバックアップポリシーが定義されていないアプリケーションを示します(つまり、アプリケーションは当初はUnmanagedに含まれます)。
ロケーション プロファイルとインフラストラクチャ プロファイル
KastenによるKubernetesデータ保護の仕組みはいたってシンプルで、宣言型の設定をモジュール式で適用する設計になっています。その二大構成要素はロケーション プロファイルとインフラストラクチャ プロファイルです。
ロケーション プロファイルは、バックアップデータをどこに送信すべきかを指定します。通常は、以下のような外部のオブジェクト ストレージのロケーションが指定されます。
● AWS S3
● Azure Blob Storage
● Google Cloud Storage
ロケーション プロファイルにデータの保存先を一度指定するだけで、Kastenはそれをデフォルトのストレージ ロケーションとして使用して、データ転送を処理します。Azureの場合は、ネイティブのBlobストレージ アカウントとそこに含まれるコンテナを事前に作成しておく必要があります。
それらが準備できたら、ストレージ アカウント名と認証用のプライマリーアクセスキーを入力します。


インフラストラクチャ プロファイルは、ストレージクラスとボリュームプロバイダのスナップショット処理の方法を指定します。言い換えると、Kastenが以下のようなインフラストラクチャのスナップショットAPIと通信できるように、設定を定義するのがインフラストラクチャ プロファイルです。
● クラウドネイティブ スナップショットAPI(AWS EBS、Azure Managed Disks、GCP Persistent Disksなど)
● CSIスナップショット ドライバ(コンテナ ストレージ インターフェース)
クラウドベースのデプロイメントでは通常、CSIスナップショット ドライバを使用するのが最善とされています。Azureの場合、Kubernetesが異なるストレージサービス用に独自のCSIドライバを適用するので、インストール時に自動的にセットされます。
ロケーションとインフラストラクチャのプロフィールが準備できたら、アプリケーションのための保護ポリシーを設定します。
Kastenのユーザーインターフェースでは、PoliciesページとApplicationsページのどちらを使用しても、新しいポリシーを作成することができます。Applicationsページから始めた場合は、ポリシー名やネームスペースなどのフィールドにデフォルト値が表示されます。
Applicationsページで保護ポリシーを設定する手順は以下のとおりです。
1. メインダッシュボードのApplicationsカードをクリックしてApplicationsページを開きます。サイドバーのApplicationsリンクをクリックしても、Applicationsページを開くことができます。
2. Applicationsテーブルから、ポリシーを設定したい“unmanaged”アプリケーションを選択します。
3. メニューを開いて、Create a Policyを選択します。

次に、ポリシーで使用するデータ保護スケジュールを定義します。

Kastenがデータをキャプチャーする仕組みは「スナップショット」が基盤となっています。そして、スナップショットは通常、ディスクボリューム(PVC/PV)と結び付けられています。クラウド(AWS、Azure、Google Cloud)では、スナップショットはオブジェクト ストレージに保存されるので、仮に元のボリュームが削除されても、スナップショットは保持されます。
スナップショットから一段進化したのが「バックアップ」です。アプリケーションやボリュームのスナップショットを、特定のインフラストラクチャに縛られない形式に変換し、指定のバックアップ ロケーションに保存するものをKastenではバックアップと呼んでいます。
スナップショットからバックアップへの変換は、ポリシー設定でBackups via Snapshot Exportsを有効にすると自動化されます。
ウィザードに沿ってバックアップ ポリシーの作成が完了したら、バックアップは設定されたスケジュールで自動作成されるようになりますが、手動で単一のバックアップをダッシュボードから直接作成することも可能です。
アプリケーションをバックアップからリストアしたい場合は、ダッシュボードでアプリケーションを選択して、Restoreをクリックするだけです。

リストアウィザードによってリストポイントの選択肢が表示されるので、そこから任意のリストアポイントを選択します。

Restoreボタンをクリックしてリストアを実行すると、アプリケーション スタックが丸ごと指定のネームスペースに復元されます。つまり、アプリケーション データだけでなく、各バージョンのコンテナイメージが丸ごと全部復元されます。
まとめ
Kubernetesは、ステートフル アプリケーションと永続的データのデプロイメントで使用されることが増えています。それにともない、信頼できる安定したデータ保護ソリューションへのニーズも高まっています。Kubernetesは優れた高可用性をもたらすツールですが、PV(永続ボリューム)やPVC(永続ボリュームクレーム)を保護するバックアップ ソリューションを欠いているため、Veeam KastenのようなKubernetesに特化されたバックアップ ソリューションの併用が不可欠です。Kastenを使用すれば、アプリケーションとその関連データ、各種設定、メタデータをKubernetesネイティブなアプローチでバックアップ、レポート、マイグレートすることができます。
Kubernetes+Kastenの活用について、ご不明な点やご関心があれば、いつでもお気軽にクライムまでお問い合わせください。

RSSフィードを取得する
