仮想化

2023.10.25

こんにちは。SB C&Sの村上です。

この記事ではTanzu Mission Control（TMC）のData Protection機能を用いて、Kubernetes上のPersistentVolume（PV）のバックアップからリストアを実施するまでの手順についてご紹介します。

TMCではData ProtectionというKubernetes上のデータのバックアップを行う機能が提供されています。
Kubernetes環境では、Podの頻繁な作成と削除をすることが一般的ですが、PVのようなデータの保持が必要なものに関してはバックアップを考慮する必要があります。
そのようなPVのバックアップをTMCの管理コンソール上での操作で実現できる機能として、Data Protectionを用いることができます。

なお、現在TMCのData Protection機能では以下2種類のバックアップ手法が提供されています。

バックアップ手法	概要	対応環境
File System Backup（FSB）	- ファイルシステム単位でデータをバックアップ - 簡易的に実行可能	TKG, EKS, AKS
Container Storage Interface （CSI） Volume Snapshot	- ボリューム単位でデータをバックアップ - データの一貫性を保つのに優れている - 専用のストレージプラグインが必要	EKS, AKS

本記事ではAmazon Elastic Kubernetes Service （EKS）上で稼働しているMySQLをターゲットとして、Data Protectionの機能を実施してみます。

環境情報

本手順ではTMCで2台のEKSが管理対象として登録済みの状態から進めます。
TMCでのEKS作成に関しては以下をご参照ください。
Tanzu Mission ControlでEKSのライフサイクル管理

本手順実施前の環境イメージは以下となります。
赤枠の箇所は本手順上で作成していきます。

本手順実施後の完成イメージは以下となります。
eks-1のMySQLのリソースをバックアップして、eks-2にリストアが実施できた状態となります。

1. Target Locationの作成

Data Protection機能の利用にあたり、バックアップ先の情報をクラスタに登録する必要があります。
TMCではTarget Locationという機能にてその点を担っているため、あらかじめ作成をしておきます。

1.1 Credentialの作成

まずバックアップ先をTMC上に登録します。
TMCでは以下3つのバックアップ先が登録でき、今回はEKSを用いるためAmazon Simple Storage Service（S3）で進めます。
なお、S3に関してはTMC上から作成できるため、AWSでは事前に作成せずに進めます。

AWS S3
AWS S3互換ストレージ（MinIO等）
Azure Blob

TMCにアクセスを行い、[Administration]-[Accounts]-[CREATE CREDENTIAL]-[AWS S3]を選択します。

Credentialの作成画面が表示されます。
Credential nameは以下パラメータを入力して、[GENERATE TEMPLATE]をクリックします。

Credential name: s3-provisioned-by-tmc

s3-provisioned-by-tmc.templateというファイルがダウンロードされたことを確認したら、[NEXT]をクリックします。

AWS Configurationでは先ほどダウンロードされたtemplateファイルをAWSに適用するよう案内がされています。

AWSマネジメントコンソールでCloudFormationにアクセスをし、[スタックの作成]をクリックします。

スタックの作成画面が表示されます。
[テンプレートファイルのアップロード]を選択し、[ファイルの選択]をクリックしてtemplateファイルのアップロードを行い、[次へ]をクリックします。

スタックの詳細指定では以下パラメータを入力して[次へ]を選択します。

スタック名: cf-s3-provisioned-by-tmc

スタックオプションの設定は何も変更せず、[次へ]をクリックします。

レビュー画面が表示されるため設定を確認後、画面下部の承認のチェックボックスにチェックを入れ、[送信]をクリックします。

作成完了後、[出力]タブに表示されているAmazon Resource Name（ARN）の情報をメモしておきます。

TMCに戻り、AWS Configurationで[NEXT]をクリックするとARNの入力画面が表示されます。
先ほどメモをしたARNの情報を入力して[CREATE]をクリックします。

StatusがCreatedになっていたら完了となります。

1.2 Target Locationの作成

作成したCredentialをクラスタに割り当てるためのTarget Locationの作成を行います。

[Administration]-[Target locations]-[CREATE TARGET LOCATION]-[AWS S3]を選択します。

Target Locationの作成画面が表示されます。
Credentialは先ほど作成した[s3-provisoned-by-tmc]を選択して、[NEXT]をクリックします。

Assign Clustersでは適用するクラスタの指定を行います。
[SELECT CLUSTERS]をクリックして、今回利用する「eks-1」「eks-2」を選択して[NEXT]をクリックします。

最後にNameに「s3-target-location」を入力して[CREATE]をクリックします。

作成完了後[Clusters]列に選択したクラスタが反映されていれば完了となります。

以上でバックアップ先の準備が整いました。
補足として、AWS S3として登録はされていますが、バックアップ種別によってはAmazon EBSなども使われます。

2. リソースの準備

この後の手順にてバックアップを行う際に対象とするリソース等の準備を行います。
本手順では以下を準備します。

項目	目的
MySQLデプロイ（pod, svc, pv, pvc）	今回バックアップの対象とするリソース
Adminer（pod, svc）デプロイ	MySQLのGUIツールとして利用
MySQLにデータ作成	データのバックアップが動作していることの確認用

※本章は「eks-1」のKubernetesクラスタにアクセスして操作を行っております

2.1 MySQLデプロイ

以下コマンドでMySQL用に「mysql」というnamespaceを作成します。

$ kubectl create namespace mysql

続いてMySQLの各リソースをデプロイするために以下のようなマニフェストを用意します。
※ Deploymentで指定している「value: test_pass」はMySQLのrootパスワードです
※ PVCで指定している「storageClassName: gp2」はEKSでデフォルトで用意されているStorageClassです

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
        - name: mysql
          image: mysql:latest
          env:
            - name: MYSQL_ROOT_PASSWORD
              value: test_pass
          ports:
            - containerPort: 3306
          volumeMounts:
            - name: mysql-persistent-storage
              mountPath: /var/lib/mysql
      volumes:
        - name: mysql-persistent-storage
          persistentVolumeClaim:
            claimName: mysql-pv-claim
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pv-claim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: gp2
---
apiVersion: v1
kind: Service
metadata:
  name: mysql-service
spec:
  selector:
    app: mysql
  ports:
    - protocol: TCP
      port: 3306
      targetPort: 3306
  type: ClusterIP

以下コマンドで作成したマニフェストをapplyします。

$ kubectl apply -f mysql_resources.yaml -n mysql

apply 完了後、以下コマンドで各リソースが作成されていることを確認します。

$ kubectl get pods,svc,pv,pvc -n mysql

## 出力
NAME                                    READY   STATUS    RESTARTS   AGE
pod/mysql-deployment-55f78f5756-h72tm   1/1     Running   0          12s
NAME                    TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
service/mysql-service   ClusterIP   10.100.119.142   ZnoneZ        3306/TCP   12s
NAME                                                        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                  STORAGECLASS   REASON   AGE
persistentvolume/pvc-f07b4789-91c5-4225-b1c4-28ef62b8ba1e   1Gi        RWO            Delete           Bound    mysql/mysql-pv-claim   gp2                     7s
NAME                                   STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
persistentvolumeclaim/mysql-pv-claim   Bound    pvc-f07b4789-91c5-4225-b1c4-28ef62b8ba1e   1Gi        RWO            gp2            12s

2.2 Adminerデプロイ

続いてMySQLをGUIから接続して操作できるようにAdminerのデプロイを行います。

以下コマンドでAdminer用に「adminer」というnamespaceを作成します。

$ kubectl create namespace adminer

以下コマンドで作成したAdminerのデプロイを行います。

$ kubectl create deployment --image=adminer:latest adminer -n adminer
$ kubectl create service loadbalancer adminer --tcp=8080:8080 -n adminer

以下コマンドで各リソースが作成されていることを確認します。

$ kubectl get pod,svc -n adminer

## 出力
NAME                           READY   STATUS    RESTARTS   AGE
pod/adminer-6b85794986-nmh4d   1/1     Running   0          13s
NAME              TYPE           CLUSTER-IP      EXTERNAL-IP                                                                    PORT(S)          AGE
service/adminer   LoadBalancer   10.100.218.14   {〇〇〇〇}   8080:32356/TCP   12s

EXTERNAL IPの8080ポートにブラウザから接続を行うとAdminerのGUIが表示されることが確認できます。

2.3 MySQLにデータを挿入

最後にAdminerからMySQLに接続を行い、データの挿入を行っておきます。

Adminerのログイン画面に以下パラメータを入力して[ログイン]をクリックします。

サーバ: mysql-service.mysql.svc.cluster.local
ユーザ名: root
パスワード: test_pass

左メニューの[SQLコマンド]をクリックして、SQLコマンドのエディタを開きます。

サンプルデータとして以下SQLを入力して[実行]をクリックします。

CREATE DATABASE tmc_dp_test;
CREATE TABLE tmc_dp_test.users (
  id INT AUTO_INCREMENT PRIMARY KEY,
  name VARCHAR(50) NOT NULL
);
INSERT INTO tmc_dp_test.users (name) VALUES ('taro'), ('jiro');

実行完了後以下のようにデータが追加されていることを確認します。

以上でeks-1上にバックアップ用のMySQLの準備ができました。
また、MySQLをGUIで操作するためのツールとしてAdminerも合わせてデプロイが完了しています。

3. バックアップ & リストア（FSB）

先ほど用意したMySQLに対してFSBを用いてバックアップとリストアを実施します。

3.1 Data Protectionの有効化（FSB）

TMCでeks1の管理画面を開き、[ENABLE DATA PROTECTION]をクリックします。

表示されたポップアップ画面にて[Enable FSB for volume backup]のみ選択して、[ENABLE]をクリックします。

リストア先でも有効化が必要なため、eks-2でも同様の手順を実施しておきます。

それぞれ有効化が完了すると新しく[Data Protection]タブが表示されるようになります。

3.2 バックアップの作成

eks-1クラスタの[Data Protection]-[CREATE BACKUP]をクリックします。

バックアップの作成画面が表示されます。
バックアップ対象の選択を求められるため、以下のように[mysql]のnamespaceを選択して[NEXT]をクリックします。

Back up Kubernetes resources
- ラジオボタン: Back up selected namespaces
- チェックボックス: mysql

How to backup volumesではバックアップ手法の選択を行います。
今回は変更をせずに[NEXT]をクリックします。

Where to store the backupではバックアップ先の選択を行います。
前手順にて作成しておいたTarget Locationの[s3-target-location]を選択して[NEXT]をクリックします。

Where to backupは、変更せずに[NEXT]をクリックします。

Back up retentionも、変更せずに[NEXT]をクリックします。

最後にNameに[eks-fsb-mysql-1]を入力して[CREATE]をクリックします。

作成が完了すると[Data protection]タブ内の[Backups]に表示されます。

中身を確認すると、バックアップされたPVの容量等も確認できます。

3.3 リストアの実施

最後にeks-1でバックアップしたMySQLをeks-2へリストアします。

eks-2の[Data protection]-[RESTORE FROM ANOTHER CLUSTER]をクリックします。

リストアの設定画面が表示されます。
Select backup to restoreでは以下パラメータを選択して[NEXT]をクリックします。

Select a cluster: eks.eks-credential.ap-northeast-1.eks-1
Choose a backup from the list below: eks-fsb-mysql-1

What Kubernetes resources to restoreは、変更せずに[NEXT]をクリックします。

What volumes to restoreも、変更せずに[NEXT]をクリックします。

最後にNameに[eks-fsb-mysql-1]を入力して[RESTORE]をクリックします。

完了すると[Data protection]タブ内の[Restores]に表示されます。

3.4 リストアされたデータの確認

最後にリストアされたデータを確認していきます。

eks-2に対して以下コマンドを実行して、バックアップしたMySQLのリソースが作成されていることを確認します。

$ kubectl get pods,svc,pv,pvc -n mysql
   
## 出力
NAME                                    READY   STATUS    RESTARTS   AGE
pod/mysql-deployment-55f78f5756-h72tm   1/1     Running   0          6m17s
NAME                    TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
service/mysql-service   ClusterIP   10.100.215.189   <none>        3306/TCP   6m16s
NAME                                                        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                  STORAGECLASS   REASON   AGE
persistentvolume/pvc-974171c1-0d9d-4be0-b260-e1be8f761c43   1Gi        RWO            Delete           Bound    mysql/mysql-pv-claim   gp2                     6m13s
NAME                                   STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
persistentvolumeclaim/mysql-pv-claim   Bound    pvc-974171c1-0d9d-4be0-b260-e1be8f761c43   1Gi        RWO            gp2            6m17s

MySQL内のデータを確認するため、eks-1と同様の手順でAdminerをデプロイしてログインまで実施します。

[tmc_dp_test]-[users]-[データ]にアクセスして確認すると無事にMySQL内のデータもリストアされていることが確認できました。

以上でFSBを用いてのバックアップ&リストアを確認できました。
eks-1に作成していたMySQLをPV含めた形でeks-2にも適用することができました。

4. CSIの準備

続いてCSIを用いたバックアップを実施するための準備を行います。
CSIを利用するためにはCSIドライバーの導入やSnapshotterの導入、CSIドライバーを用いたPVが必要などいくつか条件があります。
今回利用するEKSにおいては初めからAmazon EBS CSIドライバーがあるため、それ以外の各必要な準備を進めていきます。

4.1 CSI Snapshotterの導入

OSSとして提供されているCSI Snapshotterの導入を行います。
※ 本手順では各リソースの説明を省略するため、詳細は以下公式GitHubをご参照ください
https://github.com/kubernetes-csi/external-snapshotter/tree/master

以下コマンドを「eks-1」「eks-2」に対して実行してSnapshotterの導入を完了させます。

$ kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshotclasses.yaml
$ kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshotcontents.yaml
$ kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshots.yaml
$ kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/deploy/kubernetes/snapshot-controller/rbac-snapshot-controller.yaml
$ kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/deploy/kubernetes/snapshot-controller/setup-snapshot-controller.yaml

以下マニフェストを作成して「eks-1」「eks-2」にapply します。

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: ebs-snapshot-class
  labels:
    velero.io/csi-volumesnapshot-class: "true"
driver: ebs.csi.aws.com
deletionPolicy: Delete

4.2 StorageClassの作成

CSIドライバーを用いたPV作成にあたり、StorageClassを新しく作成する必要があります。

CSIドライバーを指定した以下マニフェストを作成して「eks-1」「eks-2」にapplyします。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ebs-csi-sc
allowVolumeExpansion: true
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Delete
parameters:
  type: gp2

4.3 MySQLの再デプロイ

新しく作成したStorageClassを用いてPVを作成するために、MySQLを再デプロイします。

まず「eks-1」「eks-2」で以下コマンドを実行して既存MySQLリソースを削除します。
※ eks-2に関しては後ほどリストアをするため、このタイミングで合わせて削除

$ kubectl delete -f mysql_resources.yaml -n mysql

続いて手順2.1で使用したmysql_resources.yaml内のPVCの以下パラメータを変更します。

変更前: storageClassName: gp2
変更後: storageClassName: ebs-csi-sc

最後に変更したmysql.yamlを「eks-1」にapplyします。

$ kubectl apply -f mysql_resources.yaml -n mysql

以下コマンドで作成されたPVのStorageClassが作成したものになっていることを確認します。

$ kubectl get pv

## 出力
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                  STORAGECLASS   REASON   AGE
pvc-0b2a6b8b-8314-416d-b4e4-374193916125   1Gi        RWO            Delete           Bound    mysql/mysql-pv-claim   ebs-csi-sc              2m39s

最後に再デプロイをしなおしたため、Adminerから前手順と同様にSQLを用いてデータの挿入を完了しておきます。

以上でCSIのバックアップに対応したEKSの準備ができました。

5. バックアップ & リストア（CSI）

EKS側のCSIの準備が完了したため、TMCからバックアップとリストアの実施を行います。

5.1 DataProtectionの有効化（CSI）

eks-1とeks-2ともに、Data protectionタブにてFSBを[DISABLE]、CSIを[ENABLE]をクリックしておきます。

5.2 バックアップの作成

バックアップの作成を行います。
基本的にはFSBと同様な手順のため、差分がある1か所のみここでは紹介します。

How to backup volumesの設定にて今回はCSIを用いるため、
[Use CSI snapshot backup for persistent volumes]にチェックを入れる必要があります。

上記1点以外は本手順上では同じため、Nameを[eks-csi-mysql-1]にして作成します。
作成が完了後確認すると、Volume BackupがCSI snapshotになっていることが確認できます。

5.3 リストアの実施

リストアの実施をします。
こちらも基本的にはFSBと同様な手順のため、差分がある1か所のみここでは紹介します。

What volumes to restoreの設定にて今回はCSIを用いるため、
[Restore persistent volume using CSI snapshot]にチェックを入れる必要があります。

上記1点以外は本手順上では同じため、Nameを[eks-csi-mysql-1]にして作成します。
作成が完了後確認すると、VolumeRestoreがFile system and CSI snapshotになっていることが確認できます。

最後にAdminerからMySQLのデータを確認して、無事リストアされていれば完了となります。

以上でCSIを用いたバックアップ&リストアを確認できました。
CSIでもFSBと同様にPVを含めた形でリストアまで完了できました。

完成図

本手順完了時の構成イメージは以下となります。
AWS上にTMCからバックアップ先が新しく用意され、その認証情報はTMC上で持っている形となります。そしてData Protectionを有効化したEKSからバックアップ&リストアが実施できるようになっています。
また、EKSはCSIに対応できるようにしたため、現在TMCで利用可能な2種のバックアップどちらでも実施ができる形となりました。

まとめ

今回はTMCのData Protectionを用いてPV含めたバックアップ&リストアを実施しました。準備段階さえ完了してしまえば実際にバックアップ&リストアを実施するのはTMC上から簡易的に実施できます。
TMCを用いれば、PVのバックアップ&リストアをクラスタ間で行う場合も1つのGUIを用いて実施できます。そして管理コンソールから複数クラスタのバックアップ状況を確認できることも、大きなメリットかと思われます。

他のおすすめ記事はこちら

Tanzu Mission ControlでEKSのライフサイクル管理

著者紹介

SB C&S株式会社
ICT事業本部技術本部技術統括部
第1技術部 1課
村上正弥 - Seiya.Murakami -

VMware vExpert

Tanzu Mission ControlのData Protection利用手順