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

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 は次の処理を実行します。

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

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

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

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

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

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

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

  1. 種類: ストレージクラス
  2.     APIバージョン: storage.k8s.io/v1
  3.     メタデータ:
  4. 名前: ロングホーン
  5.     プロビジョナー: driver.longhorn.io
  6.     パラメータ:
  7.       レプリカ数: "3"  
  8.       古いレプリカタイムアウト: "30"  
  9.       バックアップから: ""  
  10.       定期的ジョブ: '[
  11.         {
  12.  「名前」 : 「スナップ」 、
  13.  「タスク」 : 「スナップショット」 、
  14.  「cron」 : 「*/1 * * * *」 、
  15.  「保持する」 :1
  16.         },
  17.         {
  18.  「名前」 : 「バックアップ」 、
  19.  「タスク」 ： 「バックアップ」 、
  20.  「cron」 : 「*/2 * * * *」 、
  21.  「保持する」 :1
  22.         }
  23.       ]'

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

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

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

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

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

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

災害復旧ボリューム

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

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

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

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

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

  1. クラスター A で、元のボリューム X にバックアップが作成されているか、定期的なバックアップがスケジュールされていることを確認します。
  2. クラスター B のバックアップ ページで、バックアップ ボリューム X を選択し、ディザスタ リカバリ ボリューム Y を作成します。バックアップ ボリューム名をディザスタ リカバリ ボリューム名として使用することを強くお勧めします。
  3. 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 ロールを作成し、次の権限を設定します。

  1.  {
  2.  「バージョン」 : 「2012-10-17」 、
  3.  "声明" ： [
  4.     {
  5.  「シド」 : 「GrantLonghornBackupstoreAccess0」 、
  6.  「効果」 ： 「許可」 、
  7.  "アクション" ： [
  8.  "s3:PutObject" 、
  9.  "s3:GetObject" 、
  10.  "s3:ListBucket" 、
  11.  "s3:オブジェクトの削除"  
  12.       ]、
  13.  "リソース" ： [
  14.  "arn:aws:s3:::<バケット名>" ,
  15.  "arn:aws:s3:::<バケット名>/*"  
  16.       ]
  17.     }
  18.   ]
  19.  }

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

  1.  {
  2.  「バージョン」 : 「2012-10-17」 、
  3.  "声明" ： [
  4.     {
  5.  「効果」 ： 「許可」 、
  6.  "主要" ： {
  7.  「サービス」 : 「ec2.amazonaws.com」  
  8.       },
  9.  「アクション」 : 「sts:AssumeRole」  
  10.     },
  11.     {
  12.  「効果」 ： 「許可」 、
  13.  "主要" ： {
  14.  「AWS」 : 「arn:aws:iam::<AWS_ACCOUNT_ID>:role/<AWS_EC2_NODE_INSTANCE_ROLE>」  
  15.       },
  16.  「アクション」 : 「sts:AssumeRole」  
  17.     }
  18.   ]
  19.  }

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

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

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

  1.  {
  2.  「バージョン」 : 「2012-10-17」 、
  3.  "声明" ： [
  4.     {
  5.  「シド」 : 「GrantLonghornBackupstoreAccess0」 、
  6.  「効果」 ： 「許可」 、
  7.  "アクション" ： [
  8.  "s3:PutObject" 、
  9.  "s3:GetObject" 、
  10.  "s3:ListBucket" 、
  11.  "s3:オブジェクトの削除"  
  12.       ]、
  13.  "リソース" ： [
  14.  "arn:aws:s3:::<バケット名>" ,
  15.  "arn:aws:s3:::<バケット名>/*"  
  16.       ]
  17.     }
  18.   ]
  19.  }

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

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

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

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

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

  1.  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 で確認できます。

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

  1.  aws シークレット

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

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

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

  1.  kubectl は、ジェネリックなシークレットを作成します<aws-secret> \
  2.  --from-literal=AWS_ACCESS_KEY_ID=<AWS アクセスキー ID> \  
  3.  --from-literal=AWS_SECRET_ACCESS_KEY=<AWS シークレットアクセスキー> \  
  4.  --from-literal=HTTP_PROXY=<プロキシのIPとポート> \  
  5.  --from-literal=HTTPS_PROXY=<プロキシのIPとポート> \  
  6.  --from-literal=NO_PROXY=<除外IPリスト> \  
  7.     -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 サーバーを設定します。

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

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

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

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

  1. ミニオシークレット

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

  1.  APIバージョン: v1
  2. 種類: 秘密
  3. メタデータ:
  4. 名前: minio-secret
  5.   名前空間: longhorn-system
  6. タイプ: 不透明
  7. データ：
  8.   AWS_ACCESS_KEY_ID: bG9uZ2hvcm4tdGVzdC1hY2Nlc3Mta2V5 # longhorn-test-access -key  
  9.   AWS_SECRET_ACCESS_KEY: bG9uZ2hvcm4tdGVzdC1zZWNyZXQta2V5 # longhorn-test-secret -key  
  10.   AWS_ENDPOINTS: aHR0cHM6Ly9taW5pby1zZXJ2aWNlLmRlZmF1bHQ6OTAwMA== # https://minio-service.default : 9000
  11.   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 互換バックアップ ストレージに対してこの新しいアドレス指定方法を有効にすることが必要な場合があります。

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

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

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

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

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

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

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

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

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

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

バックアップを作成する

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

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

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

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

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

バックアップからの復元

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

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

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

  1. バックアップメニューに移動します
  2. 復元したいバックアップを選択し、「最新のバックアップを復元」をクリックします。
  3. 名前フィールドで、復元するボリュームを選択します
  4. 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 を使用しました。

  1.  APIバージョン: v1
  2. 種類: 永続ボリューム
  3. メタデータ:
  4. 名前: statefulset-vol-0
  5. 仕様:
  6.   容量：
  7.     ストレージ: <サイズ> #サイズと一致する必要があります ロングホーンボリューム
  8.   ボリュームモード: ファイルシステム
  9.   アクセスモード:
  10.     -一度だけ読み書き可能
  11.   persistentVolumeReclaimPolicy:削除 
  12.   シーエスアイ：
  13.     ドライバー: driver.longhorn.io # ドライバーはこれに一致する必要があります
  14.     ファイルタイプ: ext4
  15.     ボリューム属性:
  16.       numberOfReplicas: <レプリカ> # Longhorn ボリューム値と一致する必要があります
  17.       staleReplicaTimeout: '30' #分単位
  18.     volumeHandle: statefulset-vol-0 # ボリューム名と一致する必要があります ロングホーンより
  19.   storageClassName: longhorn #後で使用する名前と同じである必要があります
  20. ---  
  21.  APIバージョン: v1
  22. 種類: 永続ボリューム
  23. メタデータ:
  24. 名前: statefulset-vol-1
  25. 仕様:
  26.   容量：
  27.     ストレージ: <サイズ> #サイズと一致する必要があります ロングホーンボリューム
  28.   ボリュームモード: ファイルシステム
  29.   アクセスモード:
  30.     -一度だけ読み書き可能
  31.   persistentVolumeReclaimPolicy:削除 
  32.   シーエスアイ：
  33.     ドライバー: driver.longhorn.io # ドライバーはこれに一致する必要があります
  34.     ファイルタイプ: ext4
  35.     ボリューム属性:
  36.       numberOfReplicas: <レプリカ> # Longhorn ボリューム値と一致する必要があります
  37.       古いレプリカタイムアウト: '30'  
  38.     volumeHandle: statefulset-vol-1 # ボリューム名と一致する必要があります ロングホーンより
  39.   storageClassName: longhorn #後で使用する名前と同じである必要があります

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

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

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

  1.  APIバージョン: v1
  2. 種類: PersistentVolumeClaim
  3. メタデータ:
  4. 名前: data-webapp-0
  5. 仕様:
  6.   アクセスモード:
  7.   -一度だけ読み書き可能
  8.   リソース：
  9.     リクエスト:
  10.       ストレージ: 2Gi #サイズと一致する必要があります 以前から
  11. storageClassName: longhorn #名前と一致する必要があります 以前から
  12. volumeName: statefulset-vol-0 # 永続ボリュームを参照する必要があります
  13. ---  
  14.  APIバージョン: v1
  15. 種類: PersistentVolumeClaim
  16. メタデータ:
  17. 名前: data-webapp-1
  18. 仕様:
  19.   アクセスモード:
  20.   -一度だけ読み書き可能
  21.   リソース：
  22.     リクエスト:
  23.       ストレージ: 2Gi #サイズと一致する必要があります 以前から
  24. storageClassName: longhorn #名前と一致する必要があります 以前から
  25. volumeName: statefulset-vol-1 # 永続ボリュームを参照する必要があります

StatefulSet を作成します。

  1.  APIバージョン: アプリ/v1beta2
  2. 種類: ステートフルセット
  3. メタデータ:
  4.  name : webapp # PersistentVolumeClaim の命名規則と一致させます
  5. 仕様:
  6.   セレクタ：
  7.     一致ラベル:
  8.       app: nginx # .spec.template.metadata.labels と一致する必要があります
  9.   サービス名: "nginx"  
  10.   レプリカ: 2 #  デフォルト  1です
  11.   テンプレート：
  12.     メタデータ:
  13.       ラベル:
  14.         app: nginx # .spec.selector.matchLabels と一致する必要があります
  15.     仕様:
  16.       終了猶予期間秒数: 10
  17.       コンテナ:
  18.       -名前: nginx
  19.         イメージ: k8s.gcr.io/nginx-slim:0.8
  20.         ポート:
  21.         - コンテナポート: 80
  22. 名前: ウェブ
  23.         ボリュームマウント:
  24.         -名前:データ
  25.           マウントパス: /usr/share/nginx/html
  26.   ボリュームクレームテンプレート:
  27.   - メタデータ:
  28.  name : data # これをPersistentVolumeClaim の命名スキームと一致させます
  29.     仕様:
  30.       アクセスモード: [ "ReadWriteOnce" ]
  31.       storageClassName: longhorn #名前と一致する必要があります 以前から
  32.       リソース：
  33.         リクエスト:
  34.           ストレージ: 2Gi #サイズと一致する必要があります 以前から

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

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

前提条件

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

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

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

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

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

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

エアギャップ環境で以前の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 というデフォルト クラスを作成しました。

  1.  APIバージョン: snapshot.storage.k8s.io/v1beta1
  2. 種類: VolumeSnapshot
  3. メタデータ:
  4. 名前: テストスナップショットPVC
  5. 仕様:
  6.   ボリュームスナップショットクラス名: longhorn
  7.   ソース：
  8.     永続ボリュームクレーム名: 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 オブジェクトを指す必要があります。

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

関連するボリュームスナップショットなしでバックアップを復元する

CSI メカニズムを使用して作成されなかった Longhorn バックアップを復元するには、まずバックアップの VolumeSnapshot オブジェクトと VolumeSnapshotContent オブジェクトを手動で作成する必要があります。

VolumeSnapshotContent オブジェクトを作成し、snapshotHandle フィールドを bs://backup-volume/backup-name に設定します。

バックアップ ボリュームとバックアップ名の値は、Longhorn UI のバックアップ ページから取得できます。

  1.  APIバージョン: snapshot.storage.k8s.io/v1beta1
  2. 種類: VolumeSnapshotContent
  3. メタデータ:
  4. 名前: テスト既存バックアップ
  5. 仕様:
  6.   ボリュームスナップショットクラス名: longhorn
  7.   ドライバー: driver.longhorn.io
  8.   削除ポリシー:削除 
  9.   ソース：
  10.     # 注意: これをバックアップストア上の既存のバックアップを指すように変更します
  11.     スナップショットハンドル: bs://test-vol/backup-625159fb469e492e
  12.   ボリュームスナップショット参照:
  13. 名前: テストスナップショットの既存のバックアップ
  14.     名前空間:デフォルト 

関連する VolumeSnapshot オブジェクトを作成し、name フィールドを test-snapshot-existing-backup に設定します。ここで、source フィールドは volumeSnapshotContentName フィールドを通じて VolumeSnapshotContent オブジェクトを参照します。

これはバックアップの作成とは異なります。バックアップの作成の場合、ソース フィールドは persistentVolumeClaimName フィールドを通じて PerstistentVolumeClaim を参照します。

VolumeSnapshot オブジェクトに設定できる参照の種類は 1 つだけです。

  1.  APIバージョン: snapshot.storage.k8s.io/v1beta1
  2. 種類: VolumeSnapshot
  3. メタデータ:
  4. 名前: テストスナップショットの既存のバックアップ
  5. 仕様:
  6.   ボリュームスナップショットクラス名: longhorn
  7.   ソース：
  8.     ボリュームスナップショットコンテンツ名: テスト既存のバックアップ

これで、新しく作成された VolumeSnapshot オブジェクトを参照する PerstistentVolumeClaim オブジェクトを作成できます。

<<:  HarmonyOS サンプル DistributedMusicPlayer 分散音楽プレーヤー

>>:  エンタープライズクラウド戦略におけるクラウド導入成熟度モデルの重要性

推薦する

11のグループの関係により、JVMを明確に把握できます。

[[358883]]では、早速本題に入りましょう。グループ 1: JDK、JRE、JVM の関係JD...

Bilibiliは「中国のYouTube」になりつつある

今日はビリビリについてお話しましょう。 1.ステーションBは水平方向と垂直方向の両方でサークルを突破...

才能ある人物がウェブサイトを構築してから 1 年で 1 日あたり 70 万 IP を達成し、SEO が単なる夢物語であることを証明しました。

最近、誰もがオリジナリティの問題について語っています。多くのウェブマスターは、オリジナリティは外部リ...

百度とテンセントが共同で安全検索同盟を構築

原題: 百度とテンセントが共同で安全検索同盟を構築深セン特区日報（王暁青記者）フィッシングや詐欺など...

120人の商人の視点から見たWeChatマーケティングに関する10の真実

はじめに: WeChat マーケティングはどれほど優れているのでしょうか? どれほど悪いのでしょうか...

VMware 仮想マシン (Linux) でディスク デバイスに対応するハード ディスクを見つける方法

[[373364]]この記事はWeChatの公開アカウント「DBA Random Thoughts ...

Hupuはドメイン名hupu.comを取得し、ゲリラは正規軍に変身した

ドメイン名ニュース：本日、国内の有名なスポーツコミュニティHupu.comは、新しいドメイン名hup...

hostmybytes - 新しいマシン/CN2ラインVPSの年間支払いは12ドルから、AliPay

hostmybytes から最新のプロモーション メールを送信しました: 元の割引 VPS マシンは...

swedendeddicated: スウェーデンの苦情に強い VPS と専用サーバー。月額 5 ユーロから

swedendedicated について紹介します。同社は 2006 年にゲーム サーバーと仮想ホス...

中国のスマートヘルスケア産業に関する洞察

政策の推進、情報構築の改善、革新技術の強化により、医療はインテリジェント化の段階に入りました。市場規...

ウェブサイト構築プロセスにおける効果的なキーワード拡張方法の簡単な分析

キーワードはウェブサイトの魂です。適切なキーワード拡張作業が行われないと、多くのキーワードはランキン...

大企業から採用されたアーキテクトは、Kafka パラメータのチューニングを非常にエレガントにこなしました。たくさんのことを学びました。

1. 背景紹介: 多くの学生はKafkaパラメータを理解していない今日は非常に興味深い話題について...

サーバーレス クラウド セキュリティ: サーバーレス コンピューティングを保護する方法

サーバーレス コンピューティングは、クラウド コンピューティングの開発トレンドの 1 つであり、最も...

VSTSがAzure DevOpsサービスとして利用可能になりました。新機能は次のとおりです。

9月10日、マイクロソフトの公式ブログでAzure DevOpsサービスの開始が発表されました。 A...

Linodeはどうですか?日本大阪データセンタークラウドサーバーレビュー

Linodeはどうですか? Linode Japanはどうですか？日本の大阪Linodeはどうですか...