Kubernetes の新しいブログシリーズの4回目へようこそ！
　　→第3回目はこちら

このシリーズでは、Zadara でのKubernetes デプロイの世界と、Zadara の AWS 互換クラウドでコンテナ化されたアプリケーションを管理するために Kubernetes をどのように使用できるかを探ります。

Kubernetes が初めての方にも経験豊富な方にも、Zadara クラウドでコンテナ化されたアプリケーションを管理するための貴重な洞察とベストプラクティスを提供します。さらなるコンテンツにご期待ください✨

第4回目のブログポストは、最も基本的なスナップショット機能から成熟したバックアップとリストアソリューションの使用、そして Kubernetes コントロールプレーンの DR 準備手順まで、Kubernetes ワークロードの継続性を確保することに焦点を当てます。

【7/23（水）15:30–16:30 開催　無料ウェビナー】
VMware代替やクラウド移行を検討中の方、AI活用を視野に入れた最新インフラにご興味のある方へのご案内です

Terraform・Kubernetesを活用したクラウドマイグレーションの実演や、マルチテナント型AIインフラの設計例など、技術的な観点から学べるワークショップを開催します。
段階移行・ハイブリッド運用のヒントをお探しの方はぜひご参加ください！

形式：オンライン（Zoom）
ご参加のお申し込みはこちらから！※ご登録後、当日のZoomリンクをお送りします。
→過去のウェビナーの様子はこちら

基本的なスナップショット

通常のブロックストレージ機能に加えて、我々の EKS-D ソリューションは EBS CSI デプロイメントにマッチするように、Kubernetes スナップショット機能も事前に設定されています。 VolumeSnapshotClass ebs-vsc CRD がデフォルトのスナップショッターとして設定されています（以下のアノテーション注目してください。k10 アノテーションについては後で説明します）。

以下のような YAML 仕様の snapshotter をデプロイを使用して、任意の PVC の VolumeSnapshot を手動で作成できます。

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
name: ebs-volume-snapshot
spec:
source:
persistentVolumeClaimName: ebs-claim

このようにします（実際のスナップショットの時間は元のボリュームサイズに依存します）。設定は既存の ebs-claim PVC リソースのスナップショットを作成し、すぐに使用できる

スナップショットは以下の YAML 仕様を使用して、この内容に基づいて PVC を再作成するために使用することができます。（dataSource セクションに注目してください。）

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: ebs-snapshot-restored-claim
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 4Gi
dataSource:
name: ebs-volume-snapshot
kind: VolumeSnapshot
apiGroup: snapshot.storage.k8s.io

VolumeSnapshot がクラウド上の実際のスナップショット・リソースを参照する VolumeSnapshotContent リソースにバインドされていることに言及する価値があります。

私たちは、AWS API、Symp API、または zCompute GUI コンソールを使用して、スナップショットのクラウドリソースを確認できます。

Kasten K10 を利用したバックアップとリストア

より高度なバックアップとリストア機能については、Kasten K10 の利用を検討しても良いでしょう。Kasten K10 は、アプリケーションのボリュームだけでなく、Kubernetes 全体（Pod、シークレットなど）を扱う Veeam の製品であるため、データだけでなくアプリケーション全体のバックアップとリストアが可能です。

K10 は、前章の簡単な例で説明したのと同じスナップショット・プラクティスを使用します（同じ VolumeSnapshot リソースなどを見ることができる）。しかし、kanister エンジンを利用することで様々なデータベース指向のユースケースを支援し、さらに多くの機能を追加する事ができます。これはワークロードを簡単にバックアップとリストアする方法を探している Kubernetes の管理者にとって大きな価値を生み出します。

我々の EKS-D ソリューション では、デプロイ自動化の一環として K10 をインストールすることもできますし、シンプルな Helm チャートのインストールによって後から追加することもできます。いずれにせよ VolumeSnapshotClass の前提条件はすでに K10 アノテーションで満たされているので、インストール前にクラスタを変更する必要はありません。K10 を自分でインストールする場合はダッシュボードへのアクセス方法に関する Helm メッセージに注意してください。

基本的なクラスタ内のバックアップとリストア操作は、これ以上の設定は必要ありません。すべての Pod の準備ができたらゲートウェイ・サービスをポートフォワードして K10 にアクセスするだけです。

ロードバランサー経由でダッシュボードを公開したい場合は、Helm チャートの使い方に関する公式ドキュメントに従ってください（認証を有効にする必要があることに注意してください）。ここでは EULA（使用許諾）に同意して、 http://localhost:8080/k10/# を経由してダッシュボードを利用することにします。K10 は 5 つのワーカーノード未満の Kubernetes クラスタでのみ無料で利用できます（詳細は料金ページを参照してください）。

このデモで、私は Helm 経由で “pg” ネームスペースにインストールした PostgreSQL データベースを利用することにします。

このチャートには複数の異なるリソースが含まれています。Helm は、StatefulSet の他に PVC もデプロイしています。Secret（管理ユーザーの認証情報）、およびデータベースにアクセスするための 2つのサービスもデプロイしています。

K10 はこれらのすべてのリソースを pg 配下の “unmanaged ” アプリケーションに統合します。

pg アプリケーションのバックアップポリシーを作成してみましょう。デフォルトでは、アプリケーション全体（データボリュームを含むすべてのリソース）のスナップショットを 1時間ごとに取得するポリシーを作成します。

これで有効なポリシーが作成でき（アプリケーションが K10 によって “管理 “され）ました。また、私たちはオンデマンドでの実行も可能です。

こちらが作成した実際のバックアップジョブになります（このシンプルな例は 40秒以内に完了します）。

そしていよいよ正念場です。アプリケーションは K10 によって管理されている（バックアップポリシーに準拠）ので、Helm のアンインストールコマンドを使用してアプリケーションを Kubernetes クラスタから完全に削除します。StatefulSet PVC はデフォルトでは削除されないので手動で PVC を削除し、すべてのリソースがなくなったことを確認します。

アプリケーションは K10 によって管理されているので、ダッシュボードから簡単にリストアすることができます。

リストアポイントを使用して、同じネームスペースにバックアップした内容をリストアしてみます（他のネームスペースでもかまいません）。

リストアが完了するとアプリケーションは元のコンテンツ（スナップショットに基づく新しい PVC）と元の設定でオンラインに戻ります。 Helm のアノテーションも残っているため、Helm は実際にデプロイしたと理解するので Helm を使用してアプリケーションを管理し続けることもできます。

バックアップのエクスポート

スナップショットからデータベースのデプロイメントをリストアすることができましたが、このスナップショットはクラスタ内で作成、保存、リストアされたものです。リストアの用途によっては問題ありませんが、クラスタ自体が危険にさらされた場合のためには、クラスタの外部にバックアップをエクスポートすることを検討した方が良いでしょう。

このような高度なユースケースの場合は、K10 とリモートオブジェクトストレージの統合を検討してください。例えば、K10 認定のリモートオブジェクトストレージプロバイダーである Zadara のオブジェクトストレージを検討できるでしょう。リストアポイントをクラスタの外部にエクスポートすることで、クラスタレベルの障害からアプリケーションを保護し、ホット/コールド DR を可能にし、さらにあるクラスタから別のクラスタにアプリケーションを移行することもできます。

K10 を Zadara のオブジェクトストレージと統合するには、まずオブジェクトストレージのアカウントとユーザー認証情報（S3 アクセスキーとシークレットキー、リージョン、API エンドポイントなど）が必要です。

これらの情報と指定されたバケットを使用して、K10 の新しい S3 互換のロケーションプロファイルを作成することができます。

ロケーションプロフィールが認証され使用できるようになりました。

新しいエクスポートポリシーを作成するか、既存のものを編集してスナップショットのエクスポート機能を新しいロケーションプロファイルに含めることができます。

こうすることでリストアポイントはローカル保存されるだけでなく、エクスポートされているので必要な場合にクラスタ外から取得することができます。

前で述べたように、外部へのバックアップを必要とする様々なユースケースがあります。例えば、DR シナリオ、ランサムウェア対策（イミュータブルなバックアップ）、アプリケーションの移行などです。Kasten 自身の外部 DR も含め、Kasten はこれら全てのユースケースに対応することが可能です。これらの使用例はすべて先ほど定義した外部バックアップロケーションと同じロケーションプロファイルに基づいています。

コントロールプレーンの DR

このブログポストで説明したい最後の継続性の機能があります。それは Kubernetes のコントロールプレーン自体に関するものです。K10 のバックアップとリカバリのユースケースとは異なり、このシナリオは Kubernetes の管理レイヤーが何らかの理由でダメージを受けたケースになります。Kubernetes の内部データベース（すべての Kubernetes コンフィギュレーションを保存する ETCD）が最小限のクォーラムを失ったケースです。

マスターノード（それぞれが ETCD のコピーを保持）を専用のオートスケーリンググループ（デフォルトは 1 ですが、高可用性デプロイメントでは 3 ノードに設定する必要があります）で管理することで、Kubernetes のコントロールプレーンを保護できます。マスターノードを一時的に失われると、たとえオートスケーリンググループがマスターノードを修復したとしてもクラスタの管理レイヤーを永久にブリックしてしまうリスクがあります。

このような状況では、クラスタ自体を復旧するために ETCD をリストアする必要があるため、手動による介入が必要になります。このような場合に備えて、当社の EKS-D ソリューションには ETCD バックアップの仕組みが組み込まれており、Kubernetes データベースの定期的なスナップショットは、万が一の際にコントロールプレーンを復旧するために使用できます。

デフォルトでは、バックアップは EKS-D ソリューションに関するすべてを保存するのと同じローカルディレクトリ /etc/kubernetes/zadara （各マスターノード内）にのみ保存されます。ファイル名にはホスト名とインスタンスIDが含まれ、 etcdctl snapshot status コマンドでその内容を確認できます。

このローカルバックアップは、いくつかのユースケース（例えば、3つのマスターノードのうち2つのマスターノードを失った場合、3つ目のマスターノードのクォーラムの復元に使用）には十分かもしれませんが、DR ユースケースに対する唯一の正しいソリューションは、これらのバックアップファイルをクラスタの外部に保存することです。K10 のエクスポート例で行ったのと似ています。

この要件に対応するため、我々の EKS-D ソリューションはローカルの ETCD バックアップを Zadara オブジェクトストレージや AWS S3 などのリモートのオブジェクトストレージにエクスポートするように設定されています。インストール時のオートデプロイ変数の一部として設定するか（詳細は次回のブログ記事で）、デプロイのあとに Kubernetes シークレットの zadara-backup-export 認証情報を利用してリモートロケーションを指定することもできます（詳しくはこちら）。

とりあえず Kubernetes のシークレットを作成し、ETCD の継続的バックアップにどのように影響するかを見てみましょう。

これで、2時間ごとのバックアップから、ローカルバックアップの作成に加えて Zadara のオブジェクトストレージにエクスポートするようになりました。各マスターノードの etcd-backup.log でも確認できます（ローカルバックアップのログエントリとエクスポートのログエントリも含むことに注意してください）。

オブジェクトストレージ側（Zadara のオブジェクトストレージでも AWS の S3 でも）から、すべてのマスターノードからのエクスポートファイルを見ることができます。これらは、クラスタ名の前に一意な識別子（同じ名前のクラスタが他にもある場合に備えて）が付いた名前のフォルダの下に表示されることに注目してください。

このソリューションはすべてのマスターノードの ETCD バックアップを保持します。保持のしきい値（デフォルトで 100バックアップファイル）があるため、3つのマスターノードのセットアップの場合は通常約 2～3日分の ETCD バックアップが取得されますが、1つのマスターノードのバックアップは 1週間以上保持されていることに注意してください。

これらのバックアップを使用する必要がないことを望みますが、リストア作業は非常に簡単で行えます（操作方法はこちらのドキュメントにあります）。etcdctl snapshot restore コマンドを使用してデータベースをリストアし、リセットフラグを付けて ETCD Pod を再起動します。これでクラスタに再びアクセスできるようになるので、フラグを立てずに ETCD を再起動し、マスターノードの ASG を通常の容量までスケールアウトします。

最後の考察

このブログ記事では Zadara で Kubernetes を使用して本番グレードのワークロードを実行するために不可欠な、EKS-D の様々なバックアップとリストアのオプションについて説明しましたが、実際の本番グレードのクラスタを設定したわけではありません。すぐに使えるボックス・セットアップを使っただけです。

次回のブログでは、本番グレードの Kubernetes クラスタに必要なデフォルト以外の設定やその他のオプションのカスタマイズ機能について説明します。乞うご期待ください！