Kubernetesでのボリュームスナップショットのアルファバージョンの紹介

ご注意 perev。 ：元の記事は最近Kubernetesブログに公開され、GoogleとHuaweiの従業員（Jing Xu、Xing Yang、Saad Ali）によって書かれました。K8sの機能とデータストレージ付き。 エンジニアは、ボリュームスナップショットの目的、現在の機能、およびそれらの操作の基本について話します。

Kubernetes v1.12は、ボリュームのスナップショットをサポートするアルファ版を導入しました。 この機能を使用すると、Kubernetes APIを使用して、システムの「ネイティブ」手段を使用して、スナップショットから新しいボリュームを作成できるだけでなく、ボリュームのスナップショットを作成および削除できます。

スナップショットとは何ですか？

多くのストレージシステム（Google Cloud Persistent Disk、Amazon Elastic Block Storage、多数のオンプレミスストレージシステムなど）は、永続ボリュームのスナップショット（「スナップショット」）を作成する機能を提供します。 スナップショットは、特定の時点でのボリュームのコピーです。 新しいボリュームを提供する（スナップショットのデータで既に満たされている）か、既存のボリュームを以前の状態に復元する（スナップショットに表示される）ために使用できます。

Kubernetesにスナップショットを追加する理由

Kubernetesボリュームプラグインシステムでは、ブロックとファイルストレージのプロビジョニング、接続、マウントを自動化する強力な抽象化が既に利用可能です。

これらのすべての機能を提供することはKubernetesワークロードトレランスの目標の一部です。Kubernetesは、アプリケーションが実行中の特定のクラスターに依存せず、アプリケーションの展開が必要としないように、分散システムとして機能するアプリケーションと基盤となるクラスターの間に抽象レイヤーを作成しようとしていますクラスター固有の知識。

Kubernetes Storage SIGは 、多くのステートフルワークロードの重要な機能としてスナップショット操作を定義しています。 たとえば、データベース管理者は、操作を実行する前にデータベースのスナップショットを作成できます。

Kubernetes APIでスナップショット操作を呼び出すための標準的な方法を受け取ったKubernetesユーザーは、回避策（およびストレージシステムに固有の操作の手動呼び出し）を必要とせずに操作できます。 代わりに、ユーザーは、基盤となるストレージに関係なく、すべてがKubernetesクラスターで機能することを穏やかに理解しながら、ツールとポリシーにスナップショット操作を組み込む機会を与えられました。

さらに、これらのKubernetesプリミティブは基本的な構成要素として機能し、ストレージ管理（保護、複製、データ移行など）のためのより高度なエンタープライズレベルの機能を開発する機会を開きます。

Kubernetesでスナップショットをサポートするボリュームプラグインは何ですか？

Kubernetesは、ツリー内、Flex、およびCSIの3種類のボリュームプラグインをサポートしています。 詳細については、 Kubernetes Volume Plugin FAQを参照してください。

スナップショットはCSIドライバーでのみサポートされています（ツリー内またはFlexのいずれでもサポートされていません）。 この機能を利用するには、スナップショットサポートを実装するCSIドライバーがKubernetesクラスターに展開されていることを確認してください。

このブログ投稿の時点（2018年10月9日- 約Transl。 ）までに 、スナップショットは次のCSIドライバーでサポートされています。

• GCE永続ディスク ;
• OpenSDS
• セフrbd
• Portworx

他のドライバーのスナップショットのサポートは開発中であり、まもなく利用可能になるはずです。 CSIの詳細とCSIドライバーの展開方法については、出版物「 Kubernetes Goes BetaのContainer Storage Interface（CSI） 」に説明があります（「 Kubernetesなどでの」コンテナストレージインターフェイスの理解 」の翻訳も参照してください） - 約Transl。 ） 。

スナップショット用のKubernetes API

スナップショットを管理するために、Kubernetes Volume SnapshotsはKubernetes Persistent Volumes APIと同じ方法で3つの新しいAPIオブジェクトを導入します。

• VolumeSnapshot
  
  • 指定されたボリュームのスナップショットを要求するためにKubernetesユーザーによって作成されます。 スナップショットを削除するためのタイムスタンプや、スナップショットを使用する準備ができているかどうかなど、スナップショット操作に関する情報が含まれています。
  • PersistentVolumeClaimオブジェクトと同様に、このオブジェクトの作成と削除は、クラスターリソース（スナップショット）を作成または削除するというユーザーの要望を表しています。
• VolumeSnapshotContent
  
  • スナップショットが正常に作成されたときにCSIドライバーによって作成されます。 IDを含むスナップショットに関する情報が含まれます。
  • PersistentVolumeオブジェクトと同様に、これはクラスター（スナップショット）によって既にサービスされているリソースを表します。
  • PersistentVolumeClaimおよびPersistentVolumeオブジェクトと同様に、スナップショットが作成されると、 VolumeSnapshotContentオブジェクトは作成元のVolumeSnapshotContentされます（1対1のマッピングが使用されます）。
• VolumeSnapshotClass
  
  • 作成できるスナップショットを記述するためにクラスター管理者によって定義されます。 ドライバー情報、スナップショットにアクセスするための秘密などが含まれます。

-Kubernetesのメインの永続ボリュームオブジェクトとは異なり、これらのスナップショットオブジェクトはCustomResourceDefinitions（CRD）として定義されていることに注意することが重要です。 Kubernetesプロジェクトは、APIサーバーがAPIオブジェクトから独立しているモデルに近づいて、APIサーバーの事前定義されたリソースタイプから徐々に遠ざかりつつあります。 このアプローチにより、（Kubernetes以外の）他のプロジェクトでAPIサーバーを再利用でき、消費者（Kubernetesなど）は必要なリソースのタイプをCRDとして設定できます。

スナップショットをサポートするCSIドライバーは、必要なCRDを自動的にインストールします。 Kubernetesのエンドユーザーは、スナップショットをサポートするCSIドライバーがクラスターに展開されていることを確認するだけです。

これらの新しいオブジェクトに加えて、既存のPersistentVolumeClaimは新しいDataSourceフィールドがあります：

 type PersistentVolumeClaimSpec struct { AccessModes []PersistentVolumeAccessMode Selector *metav1.LabelSelector Resources ResourceRequirements VolumeName string StorageClassName *string VolumeMode *PersistentVolumeMode DataSource *TypedLocalObjectReference } 

このフィールド（アルファバージョンステータス）を使用すると、新しいボリュームを作成するときに、既存のスナップショットのデータを自動的に入力できます。

Kubernetesのスナップショット要件

Kubernetesでボリュームスナップショットを使用する前に、以下を行う必要があります。

• スナップショットを実装するCSIドライバーが展開され、クラスターで実行されていることを確認してください。
• 新しい機能ゲートを介してKubernetesボリュームスナップショット機能を有効にします（アルファ版ではデフォルトで無効になっています）：
  
  • API Server --feature-gates=VolumeSnapshotDataSource=true次のフラグを設定します--feature-gates=VolumeSnapshotDataSource=true

スナップショットを作成する前に、使用するCSIドライバーも決定する必要があります。これは、 VolumeSnapshotClassオブジェクトを作成し、 snapshotterフィールドでCSIドライバーを指定することによって行われます。 以下のVolumeSnapshotClass例では、このドライバーはcom.example.csi-driverです。 各スナップショットプロバイダーには、少なくとも1つのVolumeSnapshotClassオブジェクトが必要です。 各CSIドライバーのデフォルトのVolumeSnapshotClassを定義することもできます-これは、クラス定義でsnapshot.storage.kubernetes.io/is-default-class: "true"アノテーションを設定することで実行されます。

 apiVersion: snapshot.storage.k8s.io/v1alpha1 kind: VolumeSnapshotClass metadata: name: default-snapclass annotations: snapshot.storage.kubernetes.io/is-default-class: "true" snapshotter: com.example.csi-driver apiVersion: snapshot.storage.k8s.io/v1alpha1 kind: VolumeSnapshotClass metadata: name: csi-snapclass snapshotter: com.example.csi-driver parameters: fakeSnapshotOption: foo csiSnapshotterSecretName: csi-secret csiSnapshotterSecretNamespace: csi-namespace 

すべての必須パラメーターは、CSIドライバーのドキュメントに従って設定する必要があります。 上記の例では、スナップショットの作成および削除中に、 fakeSnapshotOption: fooパラメーターと前述のすべてのシークレットがCSIドライバーに渡されます。 CSI external-snapshotterは 、デフォルトでcsiSnapshotterSecretNameおよびcsiSnapshotterSecretNamespaceパラメーターキーを保存します。

最後に、スナップショットを作成する前に、CSIドライバーを使用してボリュームを作成し、そこに表示するデータを入力する必要があります（CSIボリュームの使用方法の詳細については、 この資料を参照してください）。

Kubernetesで新しいスナップショットを作成する

VolumeSnapshotClassオブジェクトVolumeSnapshotClass定義され、スナップショットを削除するボリュームになったら、 VolumeSnapshotオブジェクトを作成してこの操作を実行できます。

スナップショットのソースは、2つのパラメーターによって決定されます。

• kind - PersistentVolumeClaimここに示されています。
• name -PVCオブジェクトの実際の名前。

スナップショットが作成されるボリュームの名前空間は、 VolumeSnapshotオブジェクトの名前空間によって決定されることが理解されます。

 apiVersion: snapshot.storage.k8s.io/v1alpha1 kind: VolumeSnapshot metadata: name: new-snapshot-demo namespace: demo-namespace spec: snapshotClassName: csi-snapclass source: name: mypvc kind: PersistentVolumeClaim 

VolumeSnapshot仕様では、スナップショットの作成に使用されるCSIドライバーに関する情報を含むVolumeSnapshotClassをVolumeSnapshotできVolumeSnapshot 。 以前に報告したように、 VolumeSnapshot objectを作成した後、 fakeSnapshotOption: fooパラメーターと前述のすべてのVolumeSnapshotClassシークレットは、 CreateSnapshot呼び出しでCSIプラグインcom.example.csi-driverに渡されます。

このような要求に応じて、CSIドライバーはボリュームのスナップショットをVolumeSnapshotContent 、新しいスナップショットを表すVolumeSnapshotContentオブジェクトを自動的に作成し、このオブジェクトをVolumeSnapshotアタッチして使用可能にします。 CSIドライバーがスナップショットを作成できず、エラーを返す場合、スナップショットコントローラーはVolumeSnapshotオブジェクトのステータスでこのエラーを報告し、新しい試行を行いません （この動作はKubernetesの他のコントローラーとは異なります-予測できない時間にスナップショットを作成しないために実装されています） 。

スナップショットクラスが指定されていない場合、external-snapshotterはデフォルトクラスを検索し、作成されたスナップショットに使用しようとします。 この場合、デフォルトクラスのsnapshotterが指すCSIドライバーは、PVCストレージクラスのprovisioner者が指すCSIドライバーに対応する必要があります。

Kubernetesのスナップショットのアルファリリースでは、一貫性が保証されないことに注意してください。 スナップショットの完全なデータを確保するには、削除する前にアプリケーションを適切に準備する（アプリケーションを停止する、ファイルシステムをフリーズするなど）必要があります。

VolumeSnapshotオブジェクトが作成VolumeSnapshotれ、 VolumeSnapshotContentに関連付けられてVolumeSnapshotことをVolumeSnapshotには、 kubectl describe volumesnapshot使用できます。

• StatusでReadyがtrueになっているはずtrue 。これは、ボリュームスナップショットを使用する準備ができていることを示します。
• [ Creation Timeフィールドには、スナップショットが実際にいつCreation Timeされたかが表示されます。
• Restore Sizeフィールド-スナップショットを復元するための最小ボリュームサイズ。
• 仕様のSnapshot Content Nameフィールドは、このスナップショット用に作成されたVolumeSnapshotContentオブジェクトをVolumeSnapshotContentます。

既存のスナップショットをKubernetesにインポートする

このスナップショットを表すVolumeSnapshotContentオブジェクトを手動で作成することにより、既存のスナップショットをKubernetesにインポートできます。 VolumeSnapshotContentは名前空間に関連付けられていないAPIオブジェクトであるため、システム管理者のみがそれを作成する権限を持っています。

VolumeSnapshotContentオブジェクトVolumeSnapshotContent作成されると、ユーザーはそれを指す別のオブジェクトVolumeSnapshot作成できます。 外部スナップショットコントローラは、 VolumeSnapshotContentとVolumeSnapshotContent間の接続の存在と正確性を確認した後、スナップショットを準備完了としてマークしVolumeSnapshotContent 。 この接続が確立されると、Kubernetesでスナップショットを使用する準備が整います。

VolumeSnapshotContentオブジェクトは、 事前プロビジョニングされたスナップショットを表す次のフィールドを使用して作成する必要があります。

• csiVolumeSnapshotSourceスナップショットを識別する情報：
  
  • snapshotHandle名前/識別子。 必須フィールド。
  • driver-このボリュームを操作するために使用されるCSIドライバー。 必須フィールド。 コントローラー（スナップショットコントローラー）のスナップsnapshotterの名前と一致する必要があります。
  • creationTimeおよびrestoreSize —事前にプロビジョニングされたボリュームの場合、これらのフィールドはオプションです。 外部スナップショットコントローラは、スナップショットの作成後にそれらを自動的に更新します。
• volumeSnapshotRefこのオブジェクト（つまりVolumeSnapshotContent ）をVolumeSnapshotContentするVolumeSnapshotオブジェクトへのポインター：
  
  • nameとnamespace -コンテンツがバインドされているVolumeSnapshotオブジェクトの名前と名前空間。
  • UIDオプション（事前に準備されたボリューム用）フィールド。 外部スナップショットコントローラは、バインド後にこのフィールドを自動的に更新します。 ユーザーがこのフィールドを定義する場合、バインディングが発生するスナップショットのUIDと一致することを確認する必要があります。 そのような対応がない場合、コンテンツは無関係（孤立オブジェクト）とみなされるため、コントローラーはそれと関連するスナップショットの両方を削除します。
• snapshotClassNameはオプションのフィールドです。 外部スナップショットコントローラは、バインド後に自動的に更新します。

 apiVersion: snapshot.storage.k8s.io/v1alpha1 kind: VolumeSnapshotContent metadata: name: static-snapshot-content spec: csiVolumeSnapshotSource: driver: com.example.csi-driver snapshotHandle: snapshotcontent-example-id volumeSnapshotRef: kind: VolumeSnapshot name: static-snapshot-demo namespace: demo-namespace 

ユーザーがスナップショットを操作できるように、 VolumeSnapshotオブジェクトを作成する必要があります。 その中：

• snapshotClassNameボリュームのスナップショットクラスの名前。 オプションのフィールド。 設定する場合、スナップショットクラスのsnapshotterフィールドは、スナップショットコントローラーの名前と一致する必要があります。 設定されていない場合、コントローラーはデフォルトのスナップショットクラスを探します。
• snapshotContentNameショットボリュームのコンテンツの名前。 事前に準備されたボリュームの必須フィールド。

 apiVersion: snapshot.storage.k8s.io/v1alpha1 kind: VolumeSnapshot metadata: name: static-snapshot-demo namespace: demo-namespace spec: snapshotClassName: csi-snapclass snapshotContentName: static-snapshot-content 

これらのオブジェクトが作成されると、スナップショットコントローラーはそれらをバインドし、 Readyフィールド（ Status ）をTrueに設定して、スナップショットが使用可能な状態であることを示します。

Kubernetesのスナップショットから新しいボリュームを準備する

スナップショットオブジェクトからのデータが事前入力された新しいボリュームを作成するには、 PersistentVolumeClaim新しいdataSourceフィールドを使用します。 次の3つのパラメーターがあります。

• VolumeSnapshotソーススナップショットを表すVolumeSnapshotオブジェクトの名前。
• kind - VolumeSnapshotとして設定する必要があります。
• apiGroup必要があります。

ソースの名前空間— VolumeSnapshot —がPersistentVolumeClaim名前空間と一致することを前提としています。

 apiVersion: v1 kind: PersistentVolumeClaim metadata: name: pvc-restore Namespace: demo-namespace spec: storageClassName: csi-storageclass dataSource: name: new-snapshot-demo kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io accessModes: - ReadWriteOnce resources: requests: storage: 1Gi 

PersistentVolumeClaimオブジェクトが作成されると、指定されたスナップショットのデータが事前に入力された新しいボリュームのプロビジョニングを呼び出します。

ストレージ開発者の場合、CSIドライバーにスナップショットサポートを追加するにはどうすればよいですか？

スナップショットのサポートを提供するには、追加のコントローラー機能をCSIドライバーに追加する必要があります： CREATE_DELETE_SNAPSHOTおよびLIST_SNAPSHOTS 、および追加のRPCコントローラー： CreateSnapshot 、 DeleteSnapshot 、 ListSnapshots 。 詳細については、CSI仕様を参照してください。

KubernetesはCSIボリュームドライバーのパッケージ化と展開に関する最も基本的なガイドラインを提供していますが、このプロセスを簡素化するためにKubernetesに任意のコンテナー化されたCSIドライバーを展開する推奨メカニズムがあります。

推奨される展開プロセスの一環として、Kubernetesチームは、 external-snapshotterを備えたサイドカーコンテナーなど、さまざまなサイドカー（つまり、補助）コンテナーの使用を提案しています。

前述の外部スナップショットは、APIサーバーのVolumeSnapshotおよびVolumeSnapshotContentオブジェクトを監視し、CSIエンドポイントのCreateSnapshotおよびDeleteSnapshotを呼び出します。 CSI 外部プロバイダーを備えたサイドカーコンテナーも更新され、新しいPVC dataSourceフィールドを使用したスナップショットからのボリュームの回復がサポートされます。

スナップショット機能をサポートするには、ストレージメーカーは、外部プロビジョナーに加えて外部スナップショットを備えたサイドカーコンテナーを展開し、CSIドライバーをStatefulSetに配置することをお勧めします（下図を参照）。



この展開の例では、2つのサイドカーコンテナー、外部プロビジョニングと外部スナップショットがあり、CSIドライバーはStatefulSetポッド内のCSIホストパスプラグインで展開されます。 CSIホストパスは、実稼働環境での使用を意図していないプラグインの例です。

アルファ版の制限は何ですか？

Kubernetesのスナップショット実装のアルファ版には、次の制限があります。

• スナップショットで表される以前の状態への既存のボリュームのロールバックはサポートされていません（スナップショットからの新しいボリュームのプロビジョニングのみがサポートされています）。
• スナップショットからの既存のPersistentVolumeClaimインプレースリストアはサポートされていません。 スナップショットからの新しいボリュームのプロビジョニングは機能しますが、新しいボリュームを指すように既存のPersistentVolumeClaim更新せず、PVCが以前の状態にロールバックします（スナップショットから作成された新しいボリュームを使用するのは、新しいPV / PVCのみです）。
• スナップショットの一貫性の保証は、ストレージシステムが提供する保証（たとえば、ドロップされたときの整合性）を超えることはありません。

次は？

Kubernetesチームは、CSIのスナップショットの実装を、受け取ったフィードバックとテクノロジーの適応に応じて、リリース1.13または1.14のベータ版に移行する予定です。

詳細を調べる方法は？

k8s.io/docs/concepts/storage/volume-snapshotsおよびkubernetes-csi.imtqy.com/docsにある追加のスナップショットドキュメントを参照してください。

翻訳者からのPS

ブログもご覧ください。

• “ Kubernetes 1.12：主要なイノベーションの概要 ”;
• 「 コンテナストレージインターフェイスを理解しています（Kubernetesだけでなく） 」
• 「 ルークは「セルフサービス」のKubernetesのデータウェアハウスです 。
• 「 小規模プロジェクトでのKubernetesでの経験 」 （レビューおよびビデオレポート） ;
• 「 モニタリングとKubernetes 」 （レビューおよびビデオレポート） 。