|
| 1 | +--- |
| 2 | +title: ボリュームのスナップショット |
| 3 | +content_type: concept |
| 4 | +weight: 60 |
| 5 | +--- |
| 6 | + |
| 7 | +<!-- overview --> |
| 8 | + |
| 9 | +Kubernetesでは、*VolumeSnapshot*はストレージシステム上のボリュームのスナップショットを表します。このドキュメントは、Kubernetes[永続ボリューム](/ja/docs/concepts/storage/persistent-volumes/)に既に精通していることを前提としています。 |
| 10 | + |
| 11 | +<!-- body --> |
| 12 | + |
| 13 | +## 概要 {#introduction} |
| 14 | + |
| 15 | +APIリソース`PersistentVolume`と`PersistentVolumeClaim`を使用してユーザーと管理者にボリュームをプロビジョニングする方法と同様に、`VolumeSnapshotContent`と`VolumeSnapshot`APIリソースは、ユーザーと管理者のボリュームスナップショットを作成するために提供されます。 |
| 16 | + |
| 17 | +`VolumeSnapshotContent`は、管理者によってプロビジョニングされたクラスター内のボリュームから取得されたスナップショットです。PersistentVolumeがクラスターリソースであるように、これはクラスターのリソースです。 |
| 18 | + |
| 19 | +`VolumeSnapshot`は、ユーザーによるボリュームのスナップショットの要求です。PersistentVolumeClaimに似ています。 |
| 20 | + |
| 21 | +`VolumeSnapshotClass`を使用すると、`VolumeSnapshot`に属するさまざまな属性を指定できます。これらの属性は、ストレージシステム上の同じボリュームから取得されたスナップショット間で異なる場合があるため、`PersistentVolumeClaim`の同じ`StorageClass`を使用して表現することはできません。 |
| 22 | + |
| 23 | +ボリュームスナップショットは、完全に新しいボリュームを作成することなく、特定の時点でボリュームの内容をコピーするための標準化された方法をKubernetesユーザーに提供します。この機能により、たとえばデータベース管理者は、編集または削除の変更を実行する前にデータベースをバックアップできます。 |
| 24 | + |
| 25 | +この機能を使用する場合、ユーザーは次のことに注意する必要があります。 |
| 26 | + |
| 27 | +- APIオブジェクト`VolumeSnapshot`、`VolumeSnapshotContent`、および`VolumeSnapshotClass`は{{< glossary_tooltip term_id="CustomResourceDefinition" text="CRD" >}}であり、コアAPIの一部ではありません。 |
| 28 | +- `VolumeSnapshot`のサポートは、CSIドライバーでのみ利用できます。 |
| 29 | +- `VolumeSnapshot`の展開プロセスの一環として、Kubernetesチームは、コントロールプレーンに展開されるスナップショットコントローラーと、CSIドライバーと共に展開されるcsi-snapshotterと呼ばれるサイドカーヘルパーコンテナを提供します。スナップショットコントローラーは、`VolumeSnapshot`および`VolumeSnapshotContent`オブジェクトを管理し、`VolumeSnapshotContent`オブジェクトの作成と削除を担当します。サイドカーcsi-snapshotterは、`VolumeSnapshotContent`オブジェクトを監視し、CSIエンドポイントに対して`CreateSnapshot`および`DeleteSnapshot`操作をトリガーします。 |
| 30 | +- スナップショットオブジェクトの厳密な検証を提供するvalidation Webhookサーバーもあります。これは、CSIドライバーではなく、スナップショットコントローラーおよびCRDと共にKubernetesディストリビューションによってインストールする必要があります。スナップショット機能が有効になっているすべてのKubernetesクラスターにインストールする必要があります。 |
| 31 | +- CSIドライバーは、ボリュームスナップショット機能を実装している場合と実装していない場合があります。ボリュームスナップショットのサポートを提供するCSIドライバーは、csi-snapshotterを使用する可能性があります。詳細については、[CSIドライバーのドキュメント](https://kubernetes-csi.github.io/docs/)を参照してください。 |
| 32 | +- CRDとスナップショットコントローラーのインストールは、Kubernetesディストリビューションの責任です。 |
| 33 | + |
| 34 | +## ボリュームスナップショットとボリュームスナップショットのコンテンツのライフサイクル |
| 35 | + |
| 36 | +`VolumeSnapshotContents`はクラスター内のリソースです。`VolumeSnapshots`は、これらのリソースに対するリクエストです。`VolumeSnapshotContents`と`VolumeSnapshots`の間の相互作用は、次のライフサイクルに従います。 |
| 37 | + |
| 38 | +### プロビジョニングボリュームのスナップショット |
| 39 | + |
| 40 | +スナップショットをプロビジョニングするには、事前プロビジョニングと動的プロビジョニングの2つの方法があります。 |
| 41 | + |
| 42 | +#### 事前プロビジョニング{#static} |
| 43 | + |
| 44 | +クラスター管理者は、多数の`VolumeSnapshotContents`を作成します。それらは、クラスターユーザーが使用できるストレージシステム上の実際のボリュームスナップショットの詳細を保持します。それらはKubernetesAPIに存在し、消費することができます。 |
| 45 | + |
| 46 | +#### 動的プロビジョニング |
| 47 | + |
| 48 | +既存のスナップショットを使用する代わりに、スナップショットをPersistentVolumeClaimから動的に取得するように要求できます。[VolumeSnapshotClass](/ja/docs/concepts/storage/volume-snapshot-classes/)は、スナップショットを作成するときに使用するストレージプロバイダー固有のパラメーターを指定します。 |
| 49 | + |
| 50 | +### バインディング |
| 51 | + |
| 52 | +スナップショットコントローラーは、事前プロビジョニングされたシナリオと動的にプロビジョニングされたシナリオの両方で、適切な`VolumeSnapshotContent`オブジェクトを使用した`VolumeSnapshot`オブジェクトのバインディングを処理します。バインディングは1対1のマッピングです。 |
| 53 | + |
| 54 | +事前プロビジョニングされたバインディングの場合、要求されたVolumeSnapshotContentオブジェクトが作成されるまで、VolumeSnapshotはバインドされないままになります。 |
| 55 | + |
| 56 | +### スナップショットソース保護としてのPersistentVolumeClaim |
| 57 | + |
| 58 | +この保護の目的は、スナップショットがシステムから取得されている間、使用中の{{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}}APIオブジェクトがシステムから削除されないようにすることです(これにより、データが失われる可能性があります)。 |
| 59 | + |
| 60 | +PersistentVolumeClaimのスナップショットが作成されている間、そのPersistentVolumeClaimは使用中です。スナップショットソースとしてアクティブに使用されているPersistentVolumeClaim APIオブジェクトを削除しても、PersistentVolumeClaimオブジェクトはすぐには削除されません。代わりに、PersistentVolumeClaimオブジェクトの削除は、スナップショットがReadyToUseになるか中止されるまで延期されます。 |
| 61 | + |
| 62 | +### 削除 |
| 63 | + |
| 64 | +削除は`VolumeSnapshot`オブジェクトの削除によってトリガーされ、`DeletionPolicy`に従います。`DeletionPolicy`が`Delete`の場合、基になるストレージスナップショットは`VolumeSnapshotContent`オブジェクトとともに削除されます。`DeletionPolicy`が`Retain`の場合、基になるスナップショットと`VolumeSnapshotContent`の両方が残ります。 |
| 65 | + |
| 66 | +## ボリュームスナップショット |
| 67 | + |
| 68 | +各VolumeSnapshotには、仕様とステータスが含まれています。 |
| 69 | + |
| 70 | +```yaml |
| 71 | +apiVersion: snapshot.storage.k8s.io/v1 |
| 72 | +kind: VolumeSnapshot |
| 73 | +metadata: |
| 74 | + name: new-snapshot-test |
| 75 | +spec: |
| 76 | + volumeSnapshotClassName: csi-hostpath-snapclass |
| 77 | + source: |
| 78 | + persistentVolumeClaimName: pvc-test |
| 79 | +``` |
| 80 | +
|
| 81 | +`persistentVolumeClaimName`は、スナップショットのPersistentVolumeClaimデータソースの名前です。このフィールドは、スナップショットを動的にプロビジョニングするために必要です。 |
| 82 | + |
| 83 | +ボリュームスナップショットは、属性`volumeSnapshotClassName`を使用して[VolumeSnapshotClass](/ja/docs/concepts/storage/volume-snapshot-classes/)の名前を指定することにより、特定のクラスを要求できます。何も設定されていない場合、利用可能な場合はデフォルトのクラスが使用されます。 |
| 84 | + |
| 85 | +事前プロビジョニングされたスナップショットの場合、次の例に示すように、スナップショットのソースとして`volumeSnapshotContentName`を指定する必要があります。事前プロビジョニングされたスナップショットには、`volumeSnapshotContentName`ソースフィールドが必要です。 |
| 86 | + |
| 87 | +```yaml |
| 88 | +apiVersion: snapshot.storage.k8s.io/v1 |
| 89 | +kind: VolumeSnapshot |
| 90 | +metadata: |
| 91 | + name: test-snapshot |
| 92 | +spec: |
| 93 | + source: |
| 94 | + volumeSnapshotContentName: test-content |
| 95 | +``` |
| 96 | + |
| 97 | +## ボリュームスナップショットコンテンツ |
| 98 | + |
| 99 | +各VolumeSnapshotContentには、仕様とステータスが含まれています。動的プロビジョニングでは、スナップショット共通コントローラーが`VolumeSnapshotContent`オブジェクトを作成します。以下に例を示します。 |
| 100 | + |
| 101 | +```yaml |
| 102 | +apiVersion: snapshot.storage.k8s.io/v1 |
| 103 | +kind: VolumeSnapshotContent |
| 104 | +metadata: |
| 105 | + name: snapcontent-72d9a349-aacd-42d2-a240-d775650d2455 |
| 106 | +spec: |
| 107 | + deletionPolicy: Delete |
| 108 | + driver: hostpath.csi.k8s.io |
| 109 | + source: |
| 110 | + volumeHandle: ee0cfb94-f8d4-11e9-b2d8-0242ac110002 |
| 111 | + sourceVolumeMode: Filesystem |
| 112 | + volumeSnapshotClassName: csi-hostpath-snapclass |
| 113 | + volumeSnapshotRef: |
| 114 | + name: new-snapshot-test |
| 115 | + namespace: default |
| 116 | + uid: 72d9a349-aacd-42d2-a240-d775650d2455 |
| 117 | +``` |
| 118 | + |
| 119 | +`volumeHandle`は、ストレージバックエンドで作成され、ボリュームの作成中にCSIドライバーによって返されるボリュームの一意の識別子です。このフィールドは、スナップショットを動的にプロビジョニングするために必要です。これは、スナップショットのボリュームソースを指定します。 |
| 120 | +事前プロビジョニングされたスナップショットの場合、(クラスター管理者として)次のように`VolumeSnapshotContent`オブジェクトを作成する必要があります。 |
| 121 | + |
| 122 | +```yaml |
| 123 | +apiVersion: snapshot.storage.k8s.io/v1 |
| 124 | +kind: VolumeSnapshotContent |
| 125 | +metadata: |
| 126 | + name: new-snapshot-content-test |
| 127 | +spec: |
| 128 | + deletionPolicy: Delete |
| 129 | + driver: hostpath.csi.k8s.io |
| 130 | + source: |
| 131 | + snapshotHandle: 7bdd0de3-aaeb-11e8-9aae-0242ac110002 |
| 132 | + sourceVolumeMode: Filesystem |
| 133 | + volumeSnapshotRef: |
| 134 | + name: new-snapshot-test |
| 135 | + namespace: default |
| 136 | +``` |
| 137 | + |
| 138 | +`snapshotHandle`は、ストレージバックエンドで作成されたボリュームスナップショットの一意の識別子です。このフィールドは、事前プロビジョニングされたスナップショットに必要です。この`VolumeSnapshotContent`が表すストレージシステムのCSIスナップショットIDを指定します。 |
| 139 | + |
| 140 | +`sourceVolumeMode`は、スナップショットが作成されるボリュームのモードです。`sourceVolumeMode`フィールドの値は、`Filesystem`または`Block`のいずれかです。ソースボリュームモードが指定されていない場合、Kubernetesはスナップショットをソースボリュームのモードが不明であるかのように扱います。 |
| 141 | + |
| 142 | +`volumeSnapshotRef`は、対応する`VolumeSnapshot`の参照です。`VolumeSnapshotContent`が事前プロビジョニングされたスナップショットとして作成されている場合、`volumeSnapshotRef`で参照される`VolumeSnapshot`がまだ存在しない可能性があることに注意してください。 |
| 143 | + |
| 144 | +## スナップショットのボリュームモードの変換 {#convert-volume-mode} |
| 145 | + |
| 146 | +クラスターにインストールされている`VolumeSnapshots`APIが`sourceVolumeMode`フィールドをサポートしている場合、APIには、権限のないユーザーがボリュームのモードを変換するのを防ぐ機能があります。 |
| 147 | + |
| 148 | +クラスターにこの機能の機能があるかどうかを確認するには、次のコマンドを実行します。 |
| 149 | + |
| 150 | +```yaml |
| 151 | +$ kubectl get crd volumesnapshotcontent -o yaml |
| 152 | +``` |
| 153 | + |
| 154 | +ユーザーが既存の`VolumeSnapshot`から`PersistentVolumeClaim`を作成できるようにしたいが、ソースとは異なるボリュームモードを使用する場合は、`VolumeSnapshot`に対応する`VolumeSnapshotContent`にアノテーション`snapshot.storage.kubernetes.io/allowVolumeModeChange: "true"`を追加する必要があります。 |
| 155 | +
|
| 156 | +事前プロビジョニングされたスナップショットの場合、クラスター管理者が`spec.sourceVolumeMode`を入力する必要があります。 |
| 157 | + |
| 158 | +この機能を有効にした`VolumeSnapshotContent`リソースの例は次のようになります。 |
| 159 | + |
| 160 | +```yaml |
| 161 | +apiVersion: snapshot.storage.k8s.io/v1 |
| 162 | +kind: VolumeSnapshotContent |
| 163 | +metadata: |
| 164 | + name: new-snapshot-content-test |
| 165 | + annotations: |
| 166 | + - snapshot.storage.kubernetes.io/allowVolumeModeChange: "true" |
| 167 | +spec: |
| 168 | + deletionPolicy: Delete |
| 169 | + driver: hostpath.csi.k8s.io |
| 170 | + source: |
| 171 | + snapshotHandle: 7bdd0de3-aaeb-11e8-9aae-0242ac110002 |
| 172 | + sourceVolumeMode: Filesystem |
| 173 | + volumeSnapshotRef: |
| 174 | + name: new-snapshot-test |
| 175 | + namespace: default |
| 176 | +``` |
| 177 | + |
| 178 | +## スナップショットからのボリュームのプロビジョニング |
| 179 | + |
| 180 | +`PersistentVolumeClaim`オブジェクトの*dataSource*フィールドを使用して、スナップショットからのデータが事前に取り込まれた新しいボリュームをプロビジョニングできます。 |
| 181 | + |
| 182 | +詳細については、[ボリュームのスナップショットとスナップショットからのボリュームの復元](/ja/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support)を参照してください。 |
0 commit comments