Longhorn、エンタープライズレベルのクラウドネイティブコンテナ分散ストレージのバックアップとリカバリ

[[419258]]

スナップショットを作成する
定期的なスナップショットとバックアップ
- Longhorn UI を使用して定期的なスナップショットを設定する
- StorageClass を使用した定期ジョブの設定
- ボリュームをデタッチするときに繰り返しジョブを許可する
災害復旧ボリューム
- 災害復旧 (DR) ボリュームの作成
バックアップ先の設定
- AWS S3 バックアップストレージの設定
- ローカルテストバックアップストレージの設定
- S3通信に自己署名SSL証明書を使用する
- S3互換バックアップストレージへの仮想ホストスタイルのアクセスを有効にする
- NFS バックアップストレージ
バックアップを作成する
バックアップからの復元
Kubernetes StatefulSets のボリュームの復元
クラスターでCSIスナップショットのサポートを有効にする
- デフォルトのVolumeSnapshotClassを追加する
- エアギャップ環境で以前のLonghornリリースからアップデートする場合
- Kubernetesディストリビューションにスナップショットコントローラがバンドルされていない場合
CSI によるバックアップの作成
CSIメカニズムによるバックアップの作成
- CSIメカニズムの仕組み
- バックアップを表示
- VolumeSnapshotの例
CSI 経由でバックアップを復元する
VolumeSnapshot オブジェクトを使用してバックアップを復元する
- 関連するボリュームスナップショットなしでバックアップを復元する

スナップショットを作成する

スナップショットは、特定の時点での Kubernetes ボリュームの状態です。

既存のクラスターのスナップショットを作成するには、

Longhorn UI の上部のナビゲーションバーで、[ボリューム] をクリックします。
スナップショットを作成するボリュームの名前をクリックします。ボリュームの詳細ページが表示されます。
「スナップショットを撮る」ボタンをクリックします。

スナップショットを作成すると、ボリュームヘッダーの前のボリュームのスナップショットのリストに表示されます。

定期的なスナップショットとバックアップ

Longhorn UI から、定期的なスナップショットとバックアップをスケジュールできます。

スケジュールを設定するには、Longhorn のボリューム詳細ビューに移動します。次に、次のように設定します。

スケジュールの種類、バックアップまたはスナップショット
バックアップまたはスナップショットを作成する時間（CRON 式形式）
保存するバックアップまたはスナップショットの数
バックアップまたはスナップショットに適用するラベル

Longhorn は、ボリュームがノードに接続されるたびに、現在のユーザーのスナップショットまたはバックアップを自動的に作成します。

定期的なスナップショットは、Longhorn UI または Kubernetes StorageClass を使用して構成できます。

注: ボリュームに長期間新しいデータがない場合、定期的なジョブによって古いバックアップ/スナップショットが同じバックアップと空のスナップショットで上書きされるという問題を回避するために、Longhorn は次の処理を実行します。

定期バックアップジョブでは、ボリュームに前回のバックアップ以降に新しいデータがある場合にのみ、新しいバックアップが作成されます。
定期的なスナップショットジョブは、ボリュームヘッドに新しいデータ (ライブデータ) がある場合にのみ新しいスナップショットを取得します。

Longhorn UI を使用して定期的なスナップショットを設定する

定期的なスナップショットとバックアップは、ボリュームの詳細ページから設定できます。このページに移動するには、「ボリューム」をクリックし、ボリュームの名前をクリックします。

StorageClass で定期的なジョブを設定する

スケジュールされたバックアップとスナップショットは、StorageClass の recurringJobs パラメータで設定できます。

この StorageClass を使用して今後作成されるボリュームには、これらの定期的なジョブが自動的に設定されます。

recurringJobs フィールドは次の JSON 形式に従う必要があります。

種類: ストレージクラス
    APIバージョン: storage.k8s.io/v1
    メタデータ:
名前: ロングホーン
    プロビジョナー: driver.longhorn.io
    パラメータ:
      レプリカ数: "3"  
      古いレプリカタイムアウト: "30"  
      バックアップから: ""  
      定期的ジョブ: '[
        {
 「名前」 : 「スナップ」 、
 「タスク」 : 「スナップショット」 、
 「cron」 : 「*/1 * * * *」 、
 「保持する」 :1
        },
        {
 「名前」 : 「バックアップ」 、
 「タスク」 ： 「バックアップ」 、
 「cron」 : 「*/2 * * * *」 、
 「保持する」 :1
        }
      ]'

定期的なジョブごとに次のパラメータを指定する必要があります。

name: ジョブの名前。 recurringJob では重複する名前を使用しないでください。名前の長さは 8 文字を超えることはできません。
タスク: ジョブの種類。スナップショット (スナップショットの定期的な作成) またはバックアップ (スナップショットの定期的な作成とバックアップ) のみをサポートします。
cron: Cron 式。ジョブの実行時間を示します。
保持: Longhorn がジョブに対して保持するスナップショット/バックアップの数。 1 未満であってはいけません。

ボリュームをデタッチするときに繰り返しジョブを許可する

Longhorn には allow-recurring-job-while-volume-detached 設定が用意されており、ボリュームが切断されている場合でも定期的なバックアップを実行できます。この設定は Longhorn UI にあります。

この設定を有効にすると、Longhorn はボリュームを自動的に接続し、必要に応じて定期的なスナップショット/バックアップを実行します。

ボリュームは自動的に接続されますが、まだワークロードを処理する準備ができていないことに注意してください。定期的なジョブが完了するまでワークロードは待機する必要があります。

災害復旧ボリューム

ディザスタリカバリ (DR) ボリュームは、プライマリクラスター全体に障害が発生した場合にバックアップクラスターにデータを保存するために使用される特別なボリュームです。災害復旧ボリュームは、Longhorn ボリュームの回復力を高めるために使用されます。

災害復旧ボリュームの場合、「最終バックアップ」は元のバックアップボリュームの最新のバックアップを示します。

災害ボリュームを表すアイコンが灰色の場合、ボリュームが最後のバックアップを回復中であり、ボリュームをアクティブ化できないことを意味します。アイコンが青色の場合、ボリュームが最後のバックアップに復元されたことを意味します。

災害復旧 (DR) ボリュームの作成

前提条件: 2 つの Kubernetes クラスターをセットアップします。これらは、クラスター A およびクラスター B と呼ばれます。両方のクラスターに Longhorn をインストールし、両方のクラスターに同じバックアップ先を設定します。

クラスター A で、元のボリューム X にバックアップが作成されているか、定期的なバックアップがスケジュールされていることを確認します。
クラスター B のバックアップページで、バックアップボリューム X を選択し、ディザスタリカバリボリューム Y を作成します。バックアップボリューム名をディザスタリカバリボリューム名として使用することを強くお勧めします。
Longhorn は DR ボリューム Y をランダムなノードに自動的に接続します。その後、Longhorn はボリューム X の最後のバックアップのポーリングを開始し、それをボリューム Y に増分的に復元します。

バックアップ先の設定

バックアップターゲットは、Longhorn のバックアップストアにアクセスするために使用されるエンドポイントです。 backupstore は、Longhorn ボリュームのバックアップを保存する NFS サーバーまたは S3 互換サーバーです。バックアップ対象は、「設定/一般/バックアップ対象」で設定できます。

AWS S3 にアクセスできない場合、または最初にバックアップストレージを試してみたい場合は、MinIO を使用してローカル S3 テストバックアップストレージをセットアップする方法も提供しています。

Longhorn は、Longhorn UI または Kubernetes ストレージクラスを介してボリュームの定期的なスナップショット/バックアップジョブの設定もサポートします。

AWS S3 バックアップストレージの設定

AWS S3 に新しいバケットを作成します。

Longhorn の権限を設定します。資格情報を設定するには 2 つのオプションがあります。まず、AWS IAM ユーザーの認証情報を使用して Kubernetes シークレットを設定できます。 2 つ目は、AWS 認証情報を使用して操作するのではなく、サードパーティのアプリケーションを使用して、アノテーションを通じてポッドの一時的な AWS IAM 権限を管理できることです。

オプション 1: IAM ユーザー認証情報を使用して Kubernetes シークレットを作成する
オプション 2: AWS STS AssumeRole (kube2iam または kiam) 経由で IAM 一時認証情報を使用して権限を設定する

kube2iam または kiam は、AWS 認証情報を操作するのではなく、注釈を通じてポッドの AWS IAM 権限を管理できる Kubernetes アプリケーションです。 kube2iam または kiam の GitHub リポジトリの指示に従って、Kubernetes クラスターにインストールします。

ガイドに従って、AWS S3 サービス用の新しい AWS IAM ロールを作成し、次の権限を設定します。

 {
 「バージョン」 : 「2012-10-17」 、
 "声明" ： [
    {
 「シド」 : 「GrantLonghornBackupstoreAccess0」 、
 「効果」 ： 「許可」 、
 "アクション" ： [
 "s3:PutObject" 、
 "s3:GetObject" 、
 "s3:ListBucket" 、
 "s3:オブジェクトの削除"  
      ]、
 "リソース" ： [
 "arn:aws:s3:::<バケット名>" ,
 "arn:aws:s3:::<バケット名>/*"  
      ]
    }
  ]
 }

次の信頼関係を持つ AWS IAM ロールを編集します。

 {
 「バージョン」 : 「2012-10-17」 、
 "声明" ： [
    {
 「効果」 ： 「許可」 、
 "主要" ： {
 「サービス」 : 「ec2.amazonaws.com」  
      },
 「アクション」 : 「sts:AssumeRole」  
    },
    {
 「効果」 ： 「許可」 、
 "主要" ： {
 「AWS」 : 「arn:aws:iam::<AWS_ACCOUNT_ID>:role/<AWS_EC2_NODE_INSTANCE_ROLE>」  
      },
 「アクション」 : 「sts:AssumeRole」  
    }
  ]
 }

Longhorn 名前空間 (デフォルトでは longhorn-system) に aws-secret という名前の Kubernetes シークレットを作成します。 Longhorn がアクセスできるようにするには、シークレットを longhorn-system 名前空間に作成する必要があります。

 kubectl は、ジェネリックなシークレットを作成します<aws-secret> \
 --from-literal=AWS_IAM_ROLE_ARN=<あなたのaws-iam-role-arn> \  
    -n ロングホーンシステム

ガイドに従って新しい AWS IAM ユーザーを作成し、次の権限を設定します。 S3 バケット名を使用するようにリソースセクションを編集します。

 {
 「バージョン」 : 「2012-10-17」 、
 "声明" ： [
    {
 「シド」 : 「GrantLonghornBackupstoreAccess0」 、
 「効果」 ： 「許可」 、
 "アクション" ： [
 "s3:PutObject" 、
 "s3:GetObject" 、
 "s3:ListBucket" 、
 "s3:オブジェクトの削除"  
      ]、
 "リソース" ： [
 "arn:aws:s3:::<バケット名>" ,
 "arn:aws:s3:::<バケット名>/*"  
      ]
    }
  ]
 }

Longhorn が配置されている名前空間 (デフォルトでは longhorn-system) に aws-secret という名前の Kubernetes シークレットを作成します。 Longhorn がアクセスできるようにするには、シークレットを longhorn-system 名前空間に作成する必要があります。

 kubectl は、ジェネリックなシークレットを作成します<aws-secret> \
 --from-literal=AWS_ACCESS_KEY_ID=<AWS アクセスキー ID> \  
 --from-literal=AWS_SECRET_ACCESS_KEY=<AWS シークレットアクセスキー> \  
    -n ロングホーンシステム

Longhorn UI に移動します。上部のナビゲーションバーで、[設定] をクリックします。バックアップセクションで、バックアップターゲットを次のように設定します。

 s3://<バケット名> @ <aws リージョン>/

最後に / があることを確認してください。そうでない場合はエラーが報告されます。サブディレクトリ (プレフィックス) を使用できます:

 s3://<バケット名> @ <aws リージョン>/mypath/

また、。

たとえば、AWS の場合、リージョンコードは https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.RegionsAndAvailabilityZones.html で確認できます。

Google Cloud Storage の場合、リージョンコードは https://cloud.google.com/storage/docs/locations で確認できます。

バックアップセクションで、バックアップターゲット資格情報シークレットを次のように設定します。

 aws シークレット

これは、AWS 認証情報または AWS IAM ロールを持つシークレットの名前です。

結果: Longhorn は S3 にバックアップを保存できます。バックアップを作成するには、このセクションを参照してください。

注: プロキシの背後で Longhorn を操作していて、AWS S3 をバックアップストレージとして使用する場合は、次のように aws-secret でプロキシに関する Longhorn 情報を提供する必要があります。

 kubectl は、ジェネリックなシークレットを作成します<aws-secret> \
 --from-literal=AWS_ACCESS_KEY_ID=<AWS アクセスキー ID> \  
 --from-literal=AWS_SECRET_ACCESS_KEY=<AWS シークレットアクセスキー> \  
 --from-literal=HTTP_PROXY=<プロキシのIPとポート> \  
 --from-literal=HTTPS_PROXY=<プロキシのIPとポート> \  
 --from-literal=NO_PROXY=<除外IPリスト> \  
    -n ロングホーンシステム

NO_PROXY に、プロキシを使用しないネットワークアドレス、ネットワークアドレス範囲、およびドメインが含まれていることを確認します。 Longhorn が動作するために必要な NO_PROXY の最小値は次のとおりです。

ローカルホスト
127.0.0.1
0.0.0.0
10.0.0.0/8 (K8s コンポーネントの IP)
192.168.0.0/16 (クラスター内の内部 IP)

ローカルテストバックアップストレージの設定

NFS サーバーと MinIO S3 サーバーに基づいて、./deploy/backupstores にテスト用の 2 つのバックアップストア (backupstore) を提供します。

longhorn-system を作成した後、次のコマンドを使用して、バックアップストレージ用の MinIO S3 サーバーを設定します。

 kubectl create -f https://raw.githubusercontent.com/longhorn/longhorn/master/deploy/backupstores/minio-backupstore.yaml

Longhorn UI に移動します。上部のナビゲーションバーで、[設定] をクリックします。バックアップセクションで、バックアップターゲットを

s3://バックアップバケット@us-east-1/

バックアップターゲット資格情報シークレットを次のように設定します。

ミニオシークレット

minio-secret yaml は次のとおりです。

 APIバージョン: v1
種類: 秘密
メタデータ:
名前: minio-secret
  名前空間: longhorn-system
タイプ: 不透明
データ：
  AWS_ACCESS_KEY_ID: bG9uZ2hvcm4tdGVzdC1hY2Nlc3Mta2V5 # longhorn-test-access -key  
  AWS_SECRET_ACCESS_KEY: bG9uZ2hvcm4tdGVzdC1zZWNyZXQta2V5 # longhorn-test-secret -key  
  AWS_ENDPOINTS: aHR0cHM6Ly9taW5pby1zZXJ2aWNlLmRlZmF1bHQ6OTAwMA== # https://minio-service.default : 9000
  AWS_CERT: ==

シークレットの作成の詳細については、Kubernetes のドキュメントを参照してください。 Longhorn がアクセスするには、シークレットを longhorn-system 名前空間に作成する必要があります。

注意: base64 エンコーディングを生成するときは必ず echo -n を使用してください。そうしないと、文字列の末尾に新しい行が追加され、S3 にアクセスするときにエラーが発生します。

UI の「バックアップ」タブをクリックします。エラーなしで空のリストが報告されるはずです。

結果: Longhorn は S3 にバックアップを保存できます。

S3通信に自己署名SSL証明書を使用する

自己署名 SSL 証明書を使用する場合は、Longhorn に提供される Kubernetes シークレットに AWS_CERT を指定できます。ローカルテストバックアップストアの設定の例を参照してください。証明書は PEM 形式である必要があり、独自の CA である必要があることに注意することが重要です。または、CA 証明書を含む証明書チェーンを含める必要があります。複数の証明書を含めるには、異なる証明書 (PEM ファイル) を連結するだけです。

S3互換バックアップストレージへの仮想ホストスタイルのアクセスを有効にする

次の状況では、S3 互換バックアップストレージに対してこの新しいアドレス指定方法を有効にすることが必要な場合があります。

Amazon S3 パスの廃止計画について心配する必要がないように、この新しいアクセス方法にすぐに切り替えたい場合。
使用しているバックアップストアは、仮想ホスト形式のアクセスのみをサポートしています。例: Alibaba Cloud (Aliyun) OSS。
MinIO サーバーへの仮想ホストスタイルのリクエストを有効にするために MINIO_DOMAIN 環境変数を設定しました。
このエラー...... エラー: AWS エラー: SecondLevelDomainForbidden アクセスするには仮想ホストスタイルを使用してください。 .....が発動します。

仮想ホスト形式のアクセスを有効にする方法

バックアップ先のシークレットに、値が true の新しいフィールド VIRTUAL_HOSTED_STYLE を追加します。例えば：

 APIバージョン: v1
種類: 秘密
メタデータ:
名前: s3 互換バックアップターゲットシークレット
  名前空間: longhorn-system
タイプ: 不透明
データ：
  AWS_ACCESS_KEY_ID: bG9uZ2hvcm4tdGVzdC1hY2Nlc3Mta2V5
  AWS_SECRET_ACCESS_KEY: bG9uZ2hvcm4tdGVzdC1zZWNyZXQta2V5
  AWS_ENDPOINTS: aHR0cHM6Ly9taW5pby1zZXJ2aWNlLmRlZmF1bHQ6OTAwMA==
  VIRTUAL_HOSTED_STYLE: dHJ1ZQ== #真

シークレットをデプロイ/更新し、Settings/General/BackupTargetSecret に設定します。

NFS バックアップストレージ

NFS サーバーをバックアップストレージとして使用するには、NFS サーバーが NFSv4 をサポートしている必要があります。

ターゲット URL は次のようになります。

 nfs://longhorn-test-nfs-svc.default : /opt/backupstore

結果: Longhorn は NFS にバックアップを保存できます。

バックアップを作成する

Longhorn のバックアップは、クラスター外のバックアップストレージ内のオブジェクトです。スナップショットのバックアップはバックアップストレージにコピーされ、バックアップストレージにアクセスするエンドポイントがバックアップの対象になります。

前提条件: バックアップ先を設定する必要があります。詳細については、「バックアップ先の設定」を参照してください。 BackupTarget が設定されていない場合はエラーが発生します。

バックアップを作成するには、

音量メニューに移動します。
バックアップするボリュームを選択します。
「バックアップの作成」をクリックします。
適切なタグを追加し、「OK」をクリックします。

結果: バックアップが作成されました。表示するには、上部のナビゲーションバーの [バックアップ] をクリックします。

バックアップからの復元

Longhorn では、ボリュームへのバックアップを簡単に復元できます。

バックアップを復元すると、デフォルトで同じ名前のボリュームが作成されます。バックアップと同じ名前のボリュームがすでに存在する場合、バックアップは復元されません。

バックアップを復元するには、

バックアップメニューに移動します
復元したいバックアップを選択し、「最新のバックアップを復元」をクリックします。
名前フィールドで、復元するボリュームを選択します
OKをクリック

結果: 復元されたボリュームはボリュームページで利用できるようになります。

Kubernetes StatefulSets のボリュームの復元

Longhorn はバックアップの復元をサポートしています。この機能のユースケースの 1 つは、Kubernetes StatefulSet で使用されるデータを復元することです。このためには、バックアップされたレプリカごとにボリュームを復元する必要があります。

復元するには、以下の手順に従ってください。次の例では、各ポッドに 1 つのボリュームと 2 つのレプリカが接続された StatefulSet を使用します。

Web ブラウザで Longhorn UI ページに接続します。 [バックアップ] タブで、StatefulSet ボリュームの名前を選択します。ボリュームエントリのドロップダウンメニューをクリックして復元します。後で簡単に参照できるように、ボリュームに「永続ボリューム」という名前を付けます。

バックアップ名	復元されたボリューム
PVC-01A	ステートフルセット-vol-0
PVC-02B	ステートフルセット-vol-1

回復する必要があるボリュームごとにこの手順を繰り返します。

たとえば、pvc-01a と pvc-02b という名前のボリュームを持つ 2 つのレプリカを含む StatefulSet を復元する場合、復元は次のようになります。

Kubernetes では、作成された Longhorn ボリュームごとに永続ボリュームが作成されます。後で簡単に参照できるように、ボリュームに「Persistent Volume Claim」という名前を付けます。以下のストレージ容量、numberOfReplicas、storageClassName、volumeHandle を置き換える必要があります。この例では、Longhorn の statefulset-vol-0 と statefulset-vol-1 を参照し、storageClassName として longhorn を使用しました。

 APIバージョン: v1
種類: 永続ボリューム
メタデータ:
名前: statefulset-vol-0
仕様:
  容量：
    ストレージ: <サイズ> #サイズと一致する必要があります ロングホーンボリューム
  ボリュームモード: ファイルシステム
  アクセスモード:
    -一度だけ読み書き可能
  persistentVolumeReclaimPolicy:削除 
  シーエスアイ：
    ドライバー: driver.longhorn.io # ドライバーはこれに一致する必要があります
    ファイルタイプ: ext4
    ボリューム属性:
      numberOfReplicas: <レプリカ> # Longhorn ボリューム値と一致する必要があります
      staleReplicaTimeout: '30' #分単位
    volumeHandle: statefulset-vol-0 # ボリューム名と一致する必要があります ロングホーンより
  storageClassName: longhorn #後で使用する名前と同じである必要があります
---  
 APIバージョン: v1
種類: 永続ボリューム
メタデータ:
名前: statefulset-vol-1
仕様:
  容量：
    ストレージ: <サイズ> #サイズと一致する必要があります ロングホーンボリューム
  ボリュームモード: ファイルシステム
  アクセスモード:
    -一度だけ読み書き可能
  persistentVolumeReclaimPolicy:削除 
  シーエスアイ：
    ドライバー: driver.longhorn.io # ドライバーはこれに一致する必要があります
    ファイルタイプ: ext4
    ボリューム属性:
      numberOfReplicas: <レプリカ> # Longhorn ボリューム値と一致する必要があります
      古いレプリカタイムアウト: '30'  
    volumeHandle: statefulset-vol-1 # ボリューム名と一致する必要があります ロングホーンより
  storageClassName: longhorn #後で使用する名前と同じである必要があります

名前空間では、StatefulSet がデプロイされ、各永続ボリュームに対して PersistentVolume Claims が作成されます。永続ボリューム要求の名前は、次の命名規則に従う必要があります。

 <名前 ボリュームクレームテンプレート>-<名前  StatefulSetの>-<インデックス>

StatefulSet Pod はゼロインデックスです。この例では、ボリュームクレームテンプレートの名前は data、StatefulSet の名前は webapp で、インデックス 0 と 1 の 2 つのレプリカがあります。

 APIバージョン: v1
種類: PersistentVolumeClaim
メタデータ:
名前: data-webapp-0
仕様:
  アクセスモード:
  -一度だけ読み書き可能
  リソース：
    リクエスト:
      ストレージ: 2Gi #サイズと一致する必要があります 以前から
storageClassName: longhorn #名前と一致する必要があります 以前から
volumeName: statefulset-vol-0 # 永続ボリュームを参照する必要があります
---  
 APIバージョン: v1
種類: PersistentVolumeClaim
メタデータ:
名前: data-webapp-1
仕様:
  アクセスモード:
  -一度だけ読み書き可能
  リソース：
    リクエスト:
      ストレージ: 2Gi #サイズと一致する必要があります 以前から
storageClassName: longhorn #名前と一致する必要があります 以前から
volumeName: statefulset-vol-1 # 永続ボリュームを参照する必要があります

StatefulSet を作成します。

 APIバージョン: アプリ/v1beta2
種類: ステートフルセット
メタデータ:
 name : webapp # PersistentVolumeClaim の命名規則と一致させます
仕様:
  セレクタ：
    一致ラベル:
      app: nginx # .spec.template.metadata.labels と一致する必要があります
  サービス名: "nginx"  
  レプリカ: 2 #  デフォルト  1です
  テンプレート：
    メタデータ:
      ラベル:
        app: nginx # .spec.selector.matchLabels と一致する必要があります
    仕様:
      終了猶予期間秒数: 10
      コンテナ:
      -名前: nginx
        イメージ: k8s.gcr.io/nginx-slim:0.8
        ポート:
        - コンテナポート: 80
名前: ウェブ
        ボリュームマウント:
        -名前:データ
          マウントパス: /usr/share/nginx/html
  ボリュームクレームテンプレート:
  - メタデータ:
 name : data # これをPersistentVolumeClaim の命名スキームと一致させます
    仕様:
      アクセスモード: [ "ReadWriteOnce" ]
      storageClassName: longhorn #名前と一致する必要があります 以前から
      リソース：
        リクエスト:
          ストレージ: 2Gi #サイズと一致する必要があります 以前から

結果: 復元されたデータは、StatefulSet Pod 内からアクセスできるようになります。

クラスターでCSIスナップショットのサポートを有効にする

前提条件

CSI スナップショットのサポートは、Kubernetes バージョン 1.17 以上で利用できます。

Kubernetes ディストリビューションは、スナップショットコントローラーと関連するカスタムリソース定義のデプロイを担当します。

詳細については、「CSI ボリュームスナップショット」を参照してください。

デフォルトのVolumeSnapshotClassを追加する

スナップショットベータ CRD の可用性を確認します。次に、デフォルトの VolumeSnapshotClass を作成します。

種類: VolumeSnapshotClass
 APIバージョン: snapshot.storage.k8s.io/v1beta1
メタデータ:
名前: ロングホーン
ドライバー: driver.longhorn.io
削除ポリシー:削除

エアギャップ環境で以前のLonghornリリースからアップデートする場合

csi-provisioner イメージを longhornio/csi-provisioner:v1.6.0 に更新します。
csi-snapshotter イメージを longhornio/csi-snapshotter:v2.1.1 に更新します

Kubernetesディストリビューションにスナップショットコントローラがバンドルされていない場合

以下の手順に従って、これらのコンポーネントを手動でインストールできます。

以下に示すスナップショットコントローラー YAML ファイルは、デフォルトの名前空間にデプロイされることに注意してください。

前提条件

一般的な使用では、インストールする前に、スナップショットコントローラー YAML を適切な名前空間で更新します。

たとえば、標準の Kubernetes クラスターでは、kubectl create コマンドを発行する前に、名前空間を default から kube-system に更新します。

スナップショットベータ CRD をインストールします。

https://github.com/kubernetes-csi/external-snapshotter/tree/release-4.0/client/config/crd からファイルをダウンロードします。

kubectl create -f client/config/crd を実行します。

クラスターごとに 1 回実行します。

共通スナップショットコントローラーをインストールします。

https://github.com/kubernetes-csi/external-snapshotter/tree/release-4.0/deploy/kubernetes/snapshot-controller からファイルをダウンロードします。

名前空間を環境に適した値に更新します（例：kube-system）

kubectl create -f deploy/kubernetes/snapshot-controllerを実行します。

クラスターごとに 1 回実行します。

詳細については、kubernetes-external-snapshotter git リポジトリの使用法セクションを参照してください。

CSI によるバックアップの作成

Longhorn のバックアップはクラスター外のバックアップストア内のオブジェクトであり、バックアップストアにアクセスするためのエンドポイントがバックアップターゲットです。

プログラムでバックアップを作成するには、汎用の Kubernetes CSI スナップショットメカニズムを使用できます。

前提条件: クラスターで CSI スナップショットサポートを有効にする必要があります。 Kubernetes ディストリビューションが Kubernetes スナップショットコントローラーとスナップショット関連のカスタムリソース定義を提供しない場合は、それらを手動でデプロイする必要があります。詳細については、「CSI スナップショットサポートを有効にする」を参照してください。

CSIメカニズムによるバックアップの作成

CSI メカニズムを使用してバックアップを作成するには、kubectl 経由で Kubernetes VolumeSnapshot オブジェクトを作成します。

結果: バックアップが作成されました。 VolumeSnapshot オブジェクトを作成すると、VolumeSnapshotContent Kubernetes オブジェクトが作成されます。

VolumeSnapshotContent は、VolumeSnapshotContent.snapshotHandle フィールドで bs://backup-volume/backup-name という名前の Longhorn バックアップを参照します。

CSIメカニズムの仕組み

kubectl を使用して VolumeSnapshot オブジェクトを作成する場合、VolumeSnapshot.uuid フィールドを使用して、Longhorn スナップショットと関連する VolumeSnapshotContent オブジェクトを識別します。

これにより、snapshot-uuid という名前の新しい Longhorn スナップショットが作成されます。

次に、スナップショットのバックアップを開始し、CSI 要求を返します。

次に、snapcontent-uuid という名前の VolumeSnapshotContent オブジェクトを作成します。

CSI スナップショットサイドカーは定期的に Longhorn CSI プラグインを照会して、バックアップステータスを評価します。

バックアップが完了すると、VolumeSnapshotContent.readyToUse フラグが true に設定されます。

バックアップを表示

バックアップを表示するには、上部のナビゲーションバーで [バックアップ] をクリックし、VolumeSnapshotContent.snapshotHandle に記載されているバックアップボリューム (backup-volume) に移動します。

VolumeSnapshotの例

以下は VolumeSnapshot オブジェクトのサンプルです。ソースは、バックアップを作成する Longhorn ボリュームの PVC を指す必要があります。

volumeSnapshotClassName フィールドは VolumeSnapshotClass を指します。

deletePolicy として Delete を使用する longhorn というデフォルトクラスを作成しました。

 APIバージョン: snapshot.storage.k8s.io/v1beta1
種類: VolumeSnapshot
メタデータ:
名前: テストスナップショットPVC
仕様:
  ボリュームスナップショットクラス名: longhorn
  ソース：
    永続ボリュームクレーム名: test-vol

VolumeSnapshot を削除するときにボリュームに関連付けられたバックアップを保持する場合は、新しい VolumeSnapshotClass を作成し、削除ポリシーとして Retain を設定します。

スナップショットクラスの詳細については、VolumeSnapshotClasses に関する Kubernetes ドキュメントを参照してください。

CSI 経由でバックアップを復元する

Longhorn では、ボリュームへのバックアップを簡単に復元できます。

プログラムでバックアップを復元するには、汎用 Kubernetes CSI スナップショットメカニズムを使用できます。

前提条件

クラスターで CSI スナップショットサポートを有効にする必要があります。

Kubernetes ディストリビューションが Kubernetes スナップショットコントローラーとスナップショット関連のカスタムリソース定義を提供しない場合は、それらを手動でデプロイする必要があります。

VolumeSnapshot オブジェクトを使用してバックアップを復元する

dataSource フィールドが既存の VolumeSnapshot オブジェクトを指す PersistentVolumeClaim オブジェクトを作成します。

csi-provisioner はそれを取得し、関連付けられているバックアップのデータを使用して新しいボリュームをプロビジョニングするように Longhorn CSI ドライバーに指示します。

同じメカニズムを使用して、CSI メカニズムを通じて作成されなかった Longhorn バックアップを復元できます。

以下は PersistentVolumeClaim の例です。 dataSource フィールドは、既存の VolumeSnapshot オブジェクトを指す必要があります。

 APIバージョン: v1
種類: PersistentVolumeClaim
メタデータ:
名前: テスト復元スナップショットPVC
仕様:
  ストレージクラス名: longhorn
  データソース:
名前: テストスナップショットPVC
    種類: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  アクセスモード:
    -一度だけ読み書き可能
  リソース：
    リクエスト:
      ストレージ: 2Gi