Kubernetes CSI を通じて Longhorn ボリューム スナップショットのバックアップ、復元、クローン、拡張機能を実装する

前回の記事では、Longhorn UI を使用してボリューム スナップショット、バックアップとリカバリなどの機能を実行できることを紹介しました。さらに、Kubernetes を通じてボリュームを管理することもできます。たとえば、クラスター上で CSI を使用して、スナップショット、バックアップとリカバリ、クローン作成、容量拡張機能を実装できます。

CSI ボリューム スナップショット

Kubernetes はバージョン 1.12 からストレージ ボリューム スナップショット機能を導入し、バージョン 1.17 でベータ版になりました。 2 つのリソース オブジェクト PV と PVC と同様に、Kubernetes はボリューム スナップショット管理用に VolumeSnapshotContent、VolumeSnapshot、および VolumeSnapshotClass の 3 つのリソース オブジェクトを提供します。

コンセプト

VolumeSnapshotContent は、PV のリソース概念に似ており、PV に基づいて作成されたスナップショットです。 VolumeSnapshot は、永続宣言 PVC の概念に似た、ボリューム スナップショットに対するユーザーの要求です。 VolumeSnapshotClass オブジェクトを使用すると、スナップショットの特性を設定し、VolumeSnapshotContent の詳細を保護し、StorageClass の「クラス」概念と同様に、VolumeSnapshot バインディングの動的な管理を提供できます。

ボリューム スナップショット機能は、Kubernetes ユーザーに、完全に新しいボリュームを作成しなくても、指定した時点でボリュームの内容をコピーする標準的な方法を提供します。たとえば、データベース管理者は、編集や削除などの変更を実行する前に、データベースのバックアップを実行できます。

ただし、この機能を使用する場合は、次の点に注意してください。

• VolumeSnapshot、VolumeSnapshotContent、および VolumeSnapshotClass リソース オブジェクトは CRD であり、コア API の一部ではありません。
• VolumeSnapshot サポートは CSI ドライバーでのみ利用可能です。
• VolumeSnapshot のデプロイメント プロセスの一環として、Kubernetes チームは、コントロール プレーンにデプロイされるスナップショット コントローラーと、CSI ドライバーと一緒にデプロイされる csi-snapshotter と呼ばれるサイドカー コンテナーを提供します。スナップショット コントローラーは、VolumeSnapshot オブジェクトと VolumeSnapshotContent オブジェクトをリッスンし、VolumeSnapshotContent オブジェクトの作成と削除を担当します。 csi-snapshotter は VolumeSnapshotContent オブジェクトをリッスンし、CSI エンドポイントで CreateSnapshot および DeleteSnapshot 操作をトリガーしてスナップショットを作成または削除します。
• CSI ドライバーはボリューム スナップショットを実装する場合と実装しない場合があります。 CSI ドライバーは、ボリューム スナップショットのサポートを提供するために csi-snapshotter を使用する場合があります。詳細については、CSI ドライバーのドキュメント (https://kubernetes-csi.github.io/docs/external-snapshotter.html) を参照してください。

VolumeSnapshotContents と VolumeSnapshots のライフサイクルには、リソースのプロビジョニング、リソースのバインディング、PVC を使用するための保護メカニズム、リソースの削除など、さまざまな段階が含まれます。これら 2 つのオブジェクトは、次のライフサイクルに従います。

リソースのプロビジョニング: PV リソースのプロビジョニングと同様に、VolumeSnapshotContent でも静的または動的な方法でリソースをプロビジョニングできます。

• 静的プロビジョニング: クラスタ管理者は、PVを手動で作成するのと同様に、VolumeSnapshotContentリソースのセットを事前に作成します。
• 動的プロビジョニング: VolumeSnapshotClass リソースに基づいて、StorageClass が PV を動的に作成する方法と同様に、ユーザーが VolumeSnapshot アプリケーションを作成すると、VolumeSnapshotContent が自動的に作成されます。

リソース バインディング:スナップショット コントローラーは、静的プロビジョニングと動的プロビジョニングの両方を含む、VolumeSnapshot を適切な VolumeSnapshotContent にバインドする役割を担います。 VolumeSnapshot と VolumeSnapshotContent も 1 対 1 でバインドされており、1 対多の状況は発生しません。

使用中の PVC の保護メカニズム:ストレージ スナップショット VolumeSnapshot が作成中でまだ完了していない場合、関連する PVC は使用中としてマークされます。ユーザーが PVC を削除した場合、スナップショットが完了しないことによるデータ損失を回避するために、システムは PVC をすぐには削除しません。削除操作は、VolumeSnapshot が作成される (readyToUse ステータス) か終了する (aborted ステータス) まで遅延されます。

リソースの削除: VolumeSnapshot で削除操作が開始されると、バインドされたバックエンド VolumeSnapshotContent での削除操作は、削除ポリシー DeletionPolicy の設定に基づいて決定されます。設定可能な削除ポリシーは次のとおりです。

• 削除: VolumeSnapshotContent リソース オブジェクトとスナップショットの内容を自動的に削除します。
• 保持: VolumeSnapshotContent リソース オブジェクトとスナップショットの内容は保持され、手動でクリーンアップする必要があります。

当社の Longhorn システムは、デプロイメント後に 3 つの csi-snapshotter Pod を作成します。

 ➜ kubectl get pods - n longhorn - システム
名前準備完了ステータス再起動年齢
csi - snapshotter - 86f 65 d8bc - 9 t7dd 1 / 1 実行中5 ( 126 分前) 2 d17h
 csi - snapshotter - 86f 65 d8bc - d6xbj 1 / 1 実行中5 ( 126 分前) 2 d17h
 csi - snapshotter - 86f 65 d8bc - dncwv 1 / 1 実行中5 ( 126 分前) 2 d17h
 ......

これらは実際に開始される 3 つのレプリカです。同時にサービスを提供できるのは 1 つの Pod のみです。リーダー選出は高可用性を実現するために使用されます。たとえば、現在ここでサービスを提供しているのは csi-snapshotter-86f65d8bc-dncwv です。対応するログ情報を表示できます。

 ➜ kubectl ログ- f csi - スナップショット- 86f 65 d8bc - dncwv - n longhorn - システム
......
 E0223 04 : 36 : 33.570567 1 反射鏡。 行く： 127 ] github 。 com / kubernetes - csi / external - snapshotter / client / v3 / informers / externalversions / factory 。 go : 117 : * v1beta1 の監視に失敗しました。 VolumeSnapshotClass : * v1beta1のリストに失敗しました。 VolumeSnapshotClass : サーバーは要求されたリソースを見つけることができませんでした( volumesnapshotclasses.snapshot.storage.k8s.io を取得)
 E0223 04 : 37 : 03.773447 1 反射鏡。 行く： 127 ] github 。 com / kubernetes - csi / external - snapshotter / client / v3 / informers / externalversions / factory 。 go : 117 : * v1beta1 の監視に失敗しました。 VolumeSnapshotContent : * v1beta1のリストに失敗しました。 VolumeSnapshotContent : サーバーは要求されたリソースを見つけることができませんでした ( volumesnapshotcontents.snapshot.storage.k8s.io を取得)

VolumeSnapshotClass リソースと VolumeSnapshotContent リソースがないことがわかります。これは、これら 2 つのリソースが Kubernetes の組み込みリソース オブジェクトではなく、CRD であるためです。 Longhorn のインストール時にこれら 2 つの CRD をインストールしなかったため、見つかりません。 CSI を介してボリューム スナップショット機能を実装するには、当然ながら、まず CRD をインストールする必要があります。これらは https://github.com/kubernetes-csi/external-snapshotter プロジェクトから取得できます。

 ➜ git clone https://github.com/kubernetes-csi/external-snapshotter
 ➜ cd 外部- スナップショット&& git チェックアウトv5 .0 .1
 ➜ kubectl kustomize クライアント/ config / crd | kubectl 作成-f -

上記のコマンドは、上記の 3 つのスナップショット CRD をインストールします。

 ➜ kubectl でcrd を取得します| grep スナップショット
ボリュームスナップショットクラス。 スナップショット。 ストレージ。 k8s 。 2022-02-23 T05 : 31 : 34Z 2022-02-23 T05 : 31 : 34Z
 ボリュームスナップショットコンテンツ。 スナップショット。 ストレージ。 k8s 。 2022-02-23 T05 : 31 : 34Z 2022-02-23 T05 : 31 : 34Z
 ボリュームスナップショット。 スナップショット。 ストレージ。 k8s 。 2022-02-23 T05 : 31 : 34Z 2022-02-23 T05 : 31 : 34Z

インストールが完了したら、上記の csi-snapshotter 関連の Pod ログを確認すると、すべてが正常であることがわかります。 CRD をインストールした後では、それだけでは不十分です。 VolumeSnapshot および VolumeSnapshotContent オブジェクトをリッスンするためのスナップショット コントローラーも必要です。同様に、external-snapshotter プロジェクトも Common Snapshot Controller を提供します。ワンクリックでインストールするには、次のコマンドを実行します。

 # deploy / kubernetes / snapshot - controller / setup - snapshot - controller .yaml を変更します。 イメージアドレスはcnych / csi - snapshot - controller : v5.0.0 です。 デフォルトはgcr イメージです。
 ➜ kubectl -n kube -system kustomize deploy / kubernetes / snapshot - controller | ​ ​ kubectl 作成-f - ​

ここでは、スナップショット コントローラーを kube-system 名前空間にインストールし、2 つのコピーを開始します。繰り返しますが、一度にサービスを提供できるのは 1 つの Pod だけです。

 ➜ kubectl get pods - n kube - system - l app = snapshot - controller
 名前準備完了ステータス再起動年齢
スナップショット- コントローラー- 677 b65dc6c - 288 w9 1 / 1 実行中0 3 m22s
 スナップショット- コントローラー- 677 b65dc6c - zgdcm 1 / 1 実行中0 39 秒

この時点で、CSI を使用してスナップショットを構成するための環境が準備されました。

テスト

ボリューム スナップショット機能の使用方法を説明するために、前の mysql-pvc ボリュームを例に挙げてみましょう。

 ➜ kubectl でpvc を取得- pvc
 名前ステータスボリューム容量アクセスモードストレージクラス 年齢
mysql - pvc バウンドpvc - ec17a7e4 - 7bb4 - 4456 - 9380 - 353 db3ed4307 1 Gi RWO longhorn 2 d18h

mysql-pvc のスナップショット要求を作成するには、まず VolumeSnapshot オブジェクトを作成する必要があります。

 # スナップショット- mysql 。 ヤム
apiVersion : スナップショット。 ストレージ。 k8s 。 io / v1
 種類: ボリュームスナップショット
メタデータ:
 名前: mysql - スナップショット- デモ
仕様:
 ボリュームスナップショットクラス名: longhorn
 ソース：
 永続ボリュームクレーム名: mysql - pvc
 # volumeSnapshotContentName : テスト- コンテンツ

主な構成パラメータは 2 つあります。

• volumeSnapshotClassName: VolumeSnapshotClass の名前を指定します。これにより、対応する VolumeSnapshotContent を動的に作成してバインドできます。このパラメータが指定されていない場合は静的メソッドとなり、VolumeSnapshotContent を手動で作成する必要があります。
• persistentVolumeClaimName: データ ソースの PVC 名を指定します。
• volumeSnapshotContentName: 静的ストレージ スナップショットを申請する場合は、このパラメータを使用して VolumeSnapshotContent を指定する必要があります。

上記ではストレージ スナップショット クラス longhorn を指定しましたが、もちろんこのオブジェクトを作成する必要があります。

 # スナップショットクラス.yaml
 apiVersion : スナップショット。 ストレージ。 k8s 。 io / v1
 種類: VolumeSnapshotClass
 メタデータ:
 名前: ロングホーン
# アノテーション: # デフォルトのスナップショットクラスを指定する場合
# スナップショット。 ストレージ。 Kubernetes 。 io / is - デフォルト- クラス: "true"
 ドライバー： ドライバー。 ロングホーン。 io
 削除ポリシー: 削除

各 VolumeSnapshotClass には、driver、deletionPolicy、およびparameters フィールドが含まれており、このクラスに属する VolumeSnapshot を動的に構成する必要がある場合に使用されます。

• ドライバー: CSI ストレージ プラグイン ドライバーの名前を示します。ここではdriver.longhorn.ioという名前のLonghornプラグインを使用します。
• deletionPolicy: 削除ポリシー。Delete または Retain に設定できます。削除ポリシーが Delete の場合、基盤となるストレージ スナップショットは VolumeSnapshotContent オブジェクトとともに削除されます。削除ポリシーが Retain の場合、基礎となるスナップショットと VolumeSnapshotContent オブジェクトの両方が保持されます。
• パラメータ: ストレージ プラグインが構成する必要があるパラメータ。 CSI ドライバーは特定の構成パラメータを提供します。

現在のスナップショット クラスをデフォルトとして設定する場合は、 snapshot.storage.kubernetes.io/is-default-class: "true" などのアノテーションを追加する必要があります。

ここで、上記の 2 つのリソース オブジェクトを直接作成します。

 ➜ kubectl apply -f スナップショットクラス.yaml
 ボリュームスナップショットクラス。 スナップショット。 ストレージ。 k8s 。 io / longhorn 作成
➜ kubectl apply -f スナップショット- mysql .yaml
 ボリュームスナップショット。 スナップショット。 ストレージ。 k8s 。 io / mysql - スナップショット- デモが作成されました
➜ kubectl ボリュームスナップショットクラスを取得する
名前ドライバー削除ポリシー年齢
ロングホーンドライバー。 ロングホーン。 io 削除43 秒
➜ kubectl ボリュームスナップショットを取得する
名前READYTOUSE ソース PVC ソース スナップショット コンテンツ復元 サイズスナップショット クラススナップショット コンテンツ作成時間 経過時間
mysql - スナップショット- デモtrue mysql - pvc 1 Gi longhorn snapcontent - 1119649 a - d4f2 - 447f - a21a - e527f202e43e 43 秒43 秒

この時点で、VolumeSnapshotContent オブジェクトが動的に作成されます。

 ➜ kubectl ボリュームスナップショットコンテンツを取得する
名前READYTOUSE RESTORESIZE DELETIONPOLICY ドライバーボリューム スナップショット クラスボリューム スナップショットボリューム スナップショット 名前空間 年齢
snapcontent - 1119649 a - d4f2 - 447f - a21a - e527f202e43e true 1073741824 ドライバーを削除します。 ロングホーン。 io longhorn mysql - スナップショット- デモデフォルト97 秒

自動的に作成された VolumeSnapshotContent オブジェクトの内容は次のとおりです。

 apiVersion : スナップショット。 ストレージ。 k8s 。 io / v1
 種類: VolumeSnapshotContent
 メタデータ:
 名前: snapcontent - 1119649a - d4f2-447f - a21a - e527f202e43e
 仕様:
 削除ポリシー: 削除
ドライバー： ドライバー。 ロングホーン。 io
 ソース：
 ボリュームハンドル: pvc - ec17a7e4-7bb4-4456-9380-353db3ed4307
 ボリュームスナップショットクラス名: longhorn
 ボリュームスナップショット参照:
 apiVersion : スナップショット。 ストレージ。 k8s 。 io / v1
 種類: ボリュームスナップショット
名前: mysql - スナップショット- デモ
名前空間: デフォルト
リソースバージョン: "4967456"
 uid : 1119649a - d4f2-447f - a21a - e527f202e43e
 状態：
 作成時間: 16455975460000000000
 使用可能: true
 復元サイズ: 1073741824
 スナップショットハンドル: bs : //pvc-ec17a7e4-7bb4-4456-9380-353db3ed4307/backup-f5f28fd624a148ed

source.volumeHandle フィールドの値は、バックエンド ストレージ上に作成され、ストレージ ボリュームの作成中に CSI ドライバーによって返されるボリュームの一意の識別子です。このフィールドは動的プロビジョニング モードで必須であり、スナップショットのソース ボリューム情報を指定します。 volumeSnapshotRef の下には、関連付けられている VolumeSnapshot オブジェクトに関する関連情報があります。もちろん、この時点では、上記で作成したスナップショットを Longhorn UI インターフェイスで確認することもできます。スナップショット名は snapshot-1119649a-d4f2-447f-a21a-e527f202e43e であり、その背後にある ID は上記の VolumeSnapshotContent 名と一致しています。

対応するバックアップ操作も実行されます。バックアップ情報は、bs://backup-/backup- の形式で snapshotHandle によって指定されます。

これにより、CSI によるボリューム スナップショット管理機能が完成しました。

CSIボリュームリカバリ

Kubernetes は、バージョン 1.17 でスナップショットに基づいてストレージ ボリュームを作成するベータ バージョンを更新しました。この機能を有効にするには、kube-apiserver、kube-controller-manager、および kubelet の Feature Gate で --feature-gates=...,VolumeSnapshotDataSource を有効にする必要があります (バージョン 1.22 ではデフォルトで有効になっています)。その後、スナップショットに基づいて新しい PVC ストレージ ボリュームを作成できます。たとえば、上記で作成した mysql-snapshot-demo オブジェクトに基づいて新しい PVC を作成します。

 # 復元- mysql 。 ヤム
APIバージョン: v1
 種類: PersistentVolumeClaim
 メタデータ:
 名前: mysql - 復元- pvc
 仕様:
 ストレージクラス名: longhorn
 アクセスモード:
 -ReadWriteOnce
 リソース：
 リクエスト:
 ストレージ: 1 Gi
 データソース:
 apiGroup : スナップショット。 ストレージ。 k8s 。 io
 種類: ボリュームスナップショット
名前: mysql - スナップショット- デモ

上記の PVC オブジェクトは、基本的に通常の宣言方法と同じです。唯一の違いは、dataSource フィールドを通じて、mysql-snapshot-demo という名前のストレージ スナップショットに基づいて作成されることです。上記のリソース オブジェクトを作成すると、PV が自動的に作成され、それにバインドされます。

 ➜ kubectl get pvc mysql - 復元- pvc
 名前ステータスボリューム容量アクセスモードストレージクラス 年齢
mysql - 復元- pvc バインドされたpvc - e4ddd985 - 31 a8 - 4570 - b393 - dcedec3b0d95 1 Gi RWO longhorn 17 s

Longhorn UI でボリュームを確認すると、ボリュームの実際のサイズが 0 ではないことがわかります。これは、スナップショットからボリュームを作成したためです。これは、上記のスナップショットからデータを復元することと同じです。

ボリュームのクローン作成

CSI ストレージは、スナップショットに基づいて新しい PVC オブジェクトを作成するだけでなく、既存の PVC に基づいて新しい PVC を複製できるストレージ クローンもサポートしています。これは、dataSource フィールドにソース PVC を設定することによっても実現されます。

PVC のクローン作成は、実際には既存のストレージ ボリュームのコピーを作成することです。唯一の違いは、システムがクローンされた PVC にバックエンド ストレージ リソースを提供するときに、新しい空の PV を作成せず、元の PVC にバインドされた PV とまったく同じ PV をコピーすることです。

Kubernetes API の観点から見ると、クローンの実装は、新しい PVC を作成するときに既存の PVC をデータ ソースとして指定する機能を追加するだけです。ソース PVC はバインドされた状態にあり、使用可能 (使用されていない) である必要があります。

この機能を使用する場合、ユーザーは以下の事項に注意する必要があります。

• クローン作成はCSIドライバーでのみ利用可能です
• クローン作成は動的プロビジョニングにのみ適しています
• クローン機能は、特定の CSI ドライバーがこの機能を実現しているかどうかによって異なります。
• ターゲット PVC とソース PVC は同じ名前空間に存在する必要があります。
• 同じ StorageClass でのみサポートされます (デフォルトを使用できます)
• 2つのストレージボリュームのストレージモード（VolumeMode）は一致している必要があります

同様に、以前の mysql-pvc ストレージ ボリュームをクローンしてみましょう。対応する PVC 宣言は次のとおりです。

 APIバージョン: v1
 種類: PersistentVolumeClaim
 メタデータ:
 名前: mysql - クローン- pvc
 仕様:
 アクセスモード:
 -ReadWriteOnce
 ストレージクラス名: longhorn
 リソース：
 リクエスト:
 ストレージ: 1 Gi # ソース値以上である必要があります
データソース:
 種類: PersistentVolumeClaim
 名前: mysql - pvc

この PVC は、ソース PVC と同じ構成を宣言します。唯一の違いは、ソース PVC の名前が dataSource を通じて指定されることです。このリソース オブジェクトは直接作成されます。その結果、新しい PVC mysql-clone-pvc にはソース mysql-pvc と同じデータが含まれます。

 ➜ kubectl get pvc mysql - クローン- pvc
 名前ステータスボリューム容量アクセスモードストレージクラス 年齢
mysql - クローン- pvc バインドされたpvc - 58 eab5f0 - a386 - 435 c - 91f 4 - 0 c26f7935695 1 Gi RWO longhorn 31 s

対応するボリュームは、Longhorn UI ページでも確認できます。

新しい PVC が使用可能になると、複製された PVC は他の PVC と同様に使用でき、複製、スナップショット、削除などを行うことができます。

ダイナミックボリューム拡張

容量の拡張はストレージにとって非常に重要な要件であることは承知しています。 Kubernetes における動的ボリューム拡張も基本機能です。 PV 拡張には、基盤となるストレージのサポートが必要です。 Longhorn の基盤となるストレージはボリューム拡張をサポートしていますが、拡張されたボリュームはデタッチされた状態である必要があります。 Longhorn ボリュームを拡張するには、PVC を変更する方法と Longhorn UI を使用する方法の 2 つがあります。

Longhorn UI を使用すると操作は比較的簡単です。操作を実行するには、ページで拡張するボリュームを選択し、操作でボリュームの拡張を選択するだけです。

PVC を通じて容量を拡張するには、まず PVC を Longhorn StorageClass によって動的にプロビジョニングし、StorageClass の allowVolumeExpansion プロパティを true に設定する必要があります。この方法は、PVC と PV が自動的に更新され、拡張後も一貫性が維持されるため、推奨されます。たとえば、上記で使用した mysql-clone-pvc ボリューム (デタッチ状態) で使用される longhorn StorageClass は、すでに allowVolumeExpansion: true に設定されています。次に、mysql-pvc ボリュームの下の spec.resources.requests.storage 値を直接変更できます。

 ➜ kubectl get pvc mysql - クローン- pvc
 名前ステータスボリューム容量アクセスモードストレージクラス 年齢
mysql - クローン- pvc バウンドpvc - 58 eab5f0 - a386 - 435 c - 91f 4 - 0 c26f7935695 1 Gi RWO ロングホーン40 m
 ➜ kubectl patch pvc mysql - clone - pvc - p '{"spec":{"resources":{"requests":{"storage":"2Gi"}}}}}'

変更後、PVC のイベント情報を表示できます。

 ➜ kubectl はpvc mysql を記述します- クローン- pvc
 ......
 イベント:
 タイプ理由年齢送信元 メッセージ
---- ------ ---- ---- -------
 ......
 通常のサイズ変更14 s 外部リサイズドライバー。 ロングホーン。 io 外部リサイザーがボリュームのサイズを変更していますpvc - 58 eab5f0 - a386 - 435 c - 91f 4 - 0 c26f7935695
 警告ExternalExpanding 14 s volume_expand PVC を無視します: ボリュームを拡張できるプラグインが見つかりませんでした。 外部コントローラーがこの PVC を処理するのを待機しています。
 通常のVolumeResizeSuccessful 2 秒外部リサイズドライバー。 ロングホーン。 io ボリュームのサイズ変更に成功しました

サイズ変更操作は、external-resizer コンポーネントを通じて実装されていることがわかります。 PVC および PV のサイズ検証を確認します。

 ➜ kubectl get pvc mysql - クローン- pvc
 名前ステータスボリューム容量アクセスモードストレージクラス 年齢
mysql - クローン- pvc バウンドpvc - 58 eab5f0 - a386 - 435 c - 91f 4 - 0 c26f7935695 2 Gi RWO ロングホーン43 m
 ➜ kubectl get pv pvc - 58 eab5f0 - a386-435 c - 91f 4-0 c26f7935695
 名前容量アクセスモード回収ポリシーステータス請求ストレージクラス理由年齢
pvc - 58 eab5f0 - a386-435 c - 91f 4-0 c26f7935695 2 Gi RWO 削除バインドデフォルト/ mysql - クローン- pvc longhorn 43 m

PVC、PVともに容量が2Giになっており、拡張が成功していることがわかります。 Longhorn UI を通じてボリューム拡張の成功を確認することもできます。