kubernetesリソース・タイプ:Persistent VolumeおよびPersistent Volume Claimの永続化ストレージ
5792 ワード
コンセプト
ストレージ管理とコンピューティング管理は2つの異なる問題です.各ストレージシステムを理解することは複雑なことであり、特に一般のユーザにとって、様々なストレージ実装に関心を持つ必要がなく、データを安全かつ確実に格納することを望む場合がある.
ストレージのスケジューリングを簡略化するために、K 8 Sはストレージの供給と使用を抽象化し、管理者とユーザーにAPI形式で提供した.このタスクを完了するには、Persistent Volume(以下PVと略す)とPersistent Volume Claim(以下PVCと略す)の2つの新しいAPIリソースが導入されています.
PVはクラスタ内のネットワークストレージであり、ノードと同様にクラスタのリソースでもある.PVはVolume(ボリューム)と似ていますが、Podとは独立したライフサイクルがあります.システム管理者構成によって作成されたデータボリューム(PVタイプ)は、ストレージプラグインの実装のクラスを表します.
PVCはPodと同様にユーザの要求である.Podはノードの資源を消費し、PVCはPVの資源を消費する.Podは特定のリソース(CPUとメモリ)を申請することができる.PVCは、バックエンドの記憶実装を感知することなく、特定のサイズおよびアクセスモード(例えば、1つの読み書き、および複数の読み取り専用インスタンスをロードすることができる)を申請することができる.
PVタイプ
PVタイプはプラグイン形式で実現される.K 8 Sは以下のプラグインをサポートしています.
GCEPersistentDisk
AWSElasticBlockStore
AzureFile
AzureDisk
FC (FibreChannel)
Flocker
NFS
iSCSI
RBD (CephBlock Device)
CephFS
Cinder(OpenStack block storage)
Glusterfs
VsphereVolume
QuobyteVolumes
HostPath
VMware Photon
PortworxVolumes
ScaleIOVolumes
PV、PVCライフサイクル
PVはクラスタのリソースです.PVCはこのリソースに対するリクエストであり、リソースの所有権の検証でもある.PVとPVCの相互作用は以下のライフサイクルに従う.
に供給
クラスタ管理者は一連のPVを作成します.これらのPVには、クラスタユーザに提供される実際のストレージリソースが含まれている.K 8 S APIを利用して消費することができる.
バインディング
ユーザーは、容量とアクセスモードを含むPVCを作成します.MasterはPVCの生成を傍受し,要求内容に応じて一致するPVを検索し,PVとPVCをバインドしようと試みる.ユーザーは、必要なリソースを取得でき、使用中にリクエスト数を超える可能性があります.
適切なボリュームが見つからない場合、この申請は適切なPVが現れるまで非バインド状態が続く.例えば、1つのクラスタには50 Gサイズの永続ボリュームが多く用意されており、(総量は十分であるが)100 GのPVをクラスタに追加しない限り、100 Gの申請に応答することはできない.
使用
PodはPVCをロールとして使用しています.クラスタはPVCでバインドされたPVを検索し、PodにMountを与えます.複数のアクセス方式をサポートするボリュームの場合、ユーザは、PVCをボリュームとして使用する場合に、必要なアクセス方式を指定することができる.
ユーザがバインドされたPVCを持つと、バインドされたPVはそのユーザの所有となる.ユーザのPodsは、Podのボリュームに含まれるPVCを介して、彼らが占有するPVにアクセスすることができる.
レリーズ
ユーザがボリュームの使用を完了すると、APIを利用してPVCオブジェクトを削除することができ、再申請することもできる.PVCを削除すると、対応するボリュームは「解放された」と見なされますが、この場合は他のPVCには使用できません.以前のPVCデータはボリュームに保存されており、ポリシーに従って後続の処理が行われます.
リサイクル
PVの回収戦略は,PVCがボリュームを解放する際に,後続の作業をどのように行うべきかをクラスタに述べた.現在、保存、回収、または削除の3つのポリシーが採用されています.保存ポリシーを使用すると、このリソースを再申請できます.PVCがサポートされている場合、削除ポリシーは、AWS EBS/GCE PDまたはCinderボリュームのストレージコンテンツを同時に削除します.プラグインがサポートされている場合、回収ポリシーはベースの消去操作(rm-rf/thevolume/*)を実行し、このボリュームは再申請されます.
サンプルの作成
PV
各PVは、ボリュームの仕様および状態を記述するためのspecを含む.
Capacity(容量)
一般的に、PVは記憶容量を指定します.ここではPVのcapcityプロパティを使用する必要があります.
現在、ストレージ・サイズは、申請可能な唯一の指標です.
アクセスモード
永続ボリュームは、リソースプロバイダがサポートしている限り、任意の方法でホストにロードできます.それぞれのストレージには異なる能力があり、各PVのアクセスモードもこのボリュームでサポートされている特定のモードに設定されます.例えば、NFSは複数の読み書きクライアントをサポートすることができるが、あるNFS PVはサーバ上で読み取り専用で使用される可能性がある.各PVには独自の一連のアクセスモードがあり、これらのアクセスモードはPVの能力に依存する.
アクセス・モードのオプションは次のとおりです.
ReadWriteOnce:このボリュームは、ノードに読み書きモードでロードできます.
ReadOnlyMany:このボリュームは、読み取り専用モードで複数のノードにロードできます.
ReadWriteMany:このボリュームは、読み書きモードで複数のノードに同時にロードできます.
CLIでは、アクセス・モードは以下のように略されます.
RWO:ReadWriteOnce
ROX:ReadOnlyMany
RWX:ReadWriteMany
重要!1つのボリュームは、複数のアクセス・モードがサポートされているにもかかわらず、1つのアクセス・モードでのみロードできます.例えば、GCEpersistentDiskはReadWriteOnceもReadOnlyManyもサポートできます.
Recycling Policy(リサイクルポリシー)
現在の回収ポリシーのオプション値は次のとおりです.
Retain-手動再申請
Recycle-ベース消去(「rm-rf/thevolume/*」)
Delete-関連ストレージ資産、例えばAWSEBSまたはGCE PDボリュームを一括削除します.
現在、RecycleポリシーはNFSとHostPathのみがサポートされており、AWSEBS、GCE PDはDeleteポリシーをサポートしています.
フェーズ(Phase)
1つのボリュームは次のいずれかの段階になります.
Available:使用可能なリソース、PVCにバインドされていません
Bound:ボリュームはバインドされています
Released:PVCは削除されましたが、このリソースはクラスタによって回収されていません.
Failed:ボリュームの自動回収プロセスに失敗しました.
CLIには、PVにバインドされたPVCが表示されます.
PVC
アクセスモード
PVCはPVと一致するアクセスモードを使用する.
しげん
PVCはPodと同様に特定の数のリソースを要求することができる.ここでのリクエスト内容はストレージです.ResourceModelで説明した内容はPVとPVCにも適用されます.
StatefulSet汎用
PodはPVCを利用してストレージにアクセスできる.PVCはPodと同じネーミングスペースにある必要があります.クラスタはPodネーミングスペースのPVCを見つけ,PVCを用いてPVCを取得する.このボリュームはホストにロードされ、Podが使用できるようになります.
PV、PVC、呼び出しリソースの作成上の注意事項
使用制限
PVC、PVはdeployment、rc、rsなどのシーンでは使用できません
命名規則
上記の例のように、
汎用PVCのStatefulSet:StatefulSet名はtest-sfs、ボリューム名はpvc
PV:pv-test-sfs-{0,1}
PVC:pvc-test-sfs-{0,1}
ルールは次のとおりです.
PVCとPVの命名規則は、リソースタイプ-statefulSet名-コピー数シーケンス番号(0から)
PVとPVCのyaml企画
ネーミングルールに加えて、accessModes、resourcesの両方にアクセスすることを保証する必要があります.
以上のルールに従って作成すると、PVとPVCが関連付けられていることがわかります
ストレージ管理とコンピューティング管理は2つの異なる問題です.各ストレージシステムを理解することは複雑なことであり、特に一般のユーザにとって、様々なストレージ実装に関心を持つ必要がなく、データを安全かつ確実に格納することを望む場合がある.
ストレージのスケジューリングを簡略化するために、K 8 Sはストレージの供給と使用を抽象化し、管理者とユーザーにAPI形式で提供した.このタスクを完了するには、Persistent Volume(以下PVと略す)とPersistent Volume Claim(以下PVCと略す)の2つの新しいAPIリソースが導入されています.
PVはクラスタ内のネットワークストレージであり、ノードと同様にクラスタのリソースでもある.PVはVolume(ボリューム)と似ていますが、Podとは独立したライフサイクルがあります.システム管理者構成によって作成されたデータボリューム(PVタイプ)は、ストレージプラグインの実装のクラスを表します.
PVCはPodと同様にユーザの要求である.Podはノードの資源を消費し、PVCはPVの資源を消費する.Podは特定のリソース(CPUとメモリ)を申請することができる.PVCは、バックエンドの記憶実装を感知することなく、特定のサイズおよびアクセスモード(例えば、1つの読み書き、および複数の読み取り専用インスタンスをロードすることができる)を申請することができる.
PVタイプ
PVタイプはプラグイン形式で実現される.K 8 Sは以下のプラグインをサポートしています.
GCEPersistentDisk
AWSElasticBlockStore
AzureFile
AzureDisk
FC (FibreChannel)
Flocker
NFS
iSCSI
RBD (CephBlock Device)
CephFS
Cinder(OpenStack block storage)
Glusterfs
VsphereVolume
QuobyteVolumes
HostPath
VMware Photon
PortworxVolumes
ScaleIOVolumes
PV、PVCライフサイクル
PVはクラスタのリソースです.PVCはこのリソースに対するリクエストであり、リソースの所有権の検証でもある.PVとPVCの相互作用は以下のライフサイクルに従う.
に供給
クラスタ管理者は一連のPVを作成します.これらのPVには、クラスタユーザに提供される実際のストレージリソースが含まれている.K 8 S APIを利用して消費することができる.
バインディング
ユーザーは、容量とアクセスモードを含むPVCを作成します.MasterはPVCの生成を傍受し,要求内容に応じて一致するPVを検索し,PVとPVCをバインドしようと試みる.ユーザーは、必要なリソースを取得でき、使用中にリクエスト数を超える可能性があります.
適切なボリュームが見つからない場合、この申請は適切なPVが現れるまで非バインド状態が続く.例えば、1つのクラスタには50 Gサイズの永続ボリュームが多く用意されており、(総量は十分であるが)100 GのPVをクラスタに追加しない限り、100 Gの申請に応答することはできない.
使用
PodはPVCをロールとして使用しています.クラスタはPVCでバインドされたPVを検索し、PodにMountを与えます.複数のアクセス方式をサポートするボリュームの場合、ユーザは、PVCをボリュームとして使用する場合に、必要なアクセス方式を指定することができる.
ユーザがバインドされたPVCを持つと、バインドされたPVはそのユーザの所有となる.ユーザのPodsは、Podのボリュームに含まれるPVCを介して、彼らが占有するPVにアクセスすることができる.
レリーズ
ユーザがボリュームの使用を完了すると、APIを利用してPVCオブジェクトを削除することができ、再申請することもできる.PVCを削除すると、対応するボリュームは「解放された」と見なされますが、この場合は他のPVCには使用できません.以前のPVCデータはボリュームに保存されており、ポリシーに従って後続の処理が行われます.
リサイクル
PVの回収戦略は,PVCがボリュームを解放する際に,後続の作業をどのように行うべきかをクラスタに述べた.現在、保存、回収、または削除の3つのポリシーが採用されています.保存ポリシーを使用すると、このリソースを再申請できます.PVCがサポートされている場合、削除ポリシーは、AWS EBS/GCE PDまたはCinderボリュームのストレージコンテンツを同時に削除します.プラグインがサポートされている場合、回収ポリシーはベースの消去操作(rm-rf/thevolume/*)を実行し、このボリュームは再申請されます.
サンプルの作成
PV
各PVは、ボリュームの仕様および状態を記述するためのspecを含む.
cat << EOF > pv-lykops-sfs-0.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv-lykops-sfs-0
labels:
type: nfs
app: pv
version: v1
spec:
capacity:
storage: 1Gi
accessModes:
-ReadWriteMany
persistentVolumeReclaimPolicy: Recycle
nfs:
path: /data
server: 192.168.20.128
readOnly: false
EOF
kubectl create -f pv-lykops-sfs-0.yamlCapacity(容量)
一般的に、PVは記憶容量を指定します.ここではPVのcapcityプロパティを使用する必要があります.
現在、ストレージ・サイズは、申請可能な唯一の指標です.
アクセスモード
永続ボリュームは、リソースプロバイダがサポートしている限り、任意の方法でホストにロードできます.それぞれのストレージには異なる能力があり、各PVのアクセスモードもこのボリュームでサポートされている特定のモードに設定されます.例えば、NFSは複数の読み書きクライアントをサポートすることができるが、あるNFS PVはサーバ上で読み取り専用で使用される可能性がある.各PVには独自の一連のアクセスモードがあり、これらのアクセスモードはPVの能力に依存する.
アクセス・モードのオプションは次のとおりです.
ReadWriteOnce:このボリュームは、ノードに読み書きモードでロードできます.
ReadOnlyMany:このボリュームは、読み取り専用モードで複数のノードにロードできます.
ReadWriteMany:このボリュームは、読み書きモードで複数のノードに同時にロードできます.
CLIでは、アクセス・モードは以下のように略されます.
RWO:ReadWriteOnce
ROX:ReadOnlyMany
RWX:ReadWriteMany
重要!1つのボリュームは、複数のアクセス・モードがサポートされているにもかかわらず、1つのアクセス・モードでのみロードできます.例えば、GCEpersistentDiskはReadWriteOnceもReadOnlyManyもサポートできます.
Recycling Policy(リサイクルポリシー)
現在の回収ポリシーのオプション値は次のとおりです.
Retain-手動再申請
Recycle-ベース消去(「rm-rf/thevolume/*」)
Delete-関連ストレージ資産、例えばAWSEBSまたはGCE PDボリュームを一括削除します.
現在、RecycleポリシーはNFSとHostPathのみがサポートされており、AWSEBS、GCE PDはDeleteポリシーをサポートしています.
フェーズ(Phase)
1つのボリュームは次のいずれかの段階になります.
Available:使用可能なリソース、PVCにバインドされていません
Bound:ボリュームはバインドされています
Released:PVCは削除されましたが、このリソースはクラスタによって回収されていません.
Failed:ボリュームの自動回収プロセスに失敗しました.
CLIには、PVにバインドされたPVCが表示されます.
PVC
cat << EOF > pvc-lykops-sfs-0.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-lykops-sfs-0
labels:
type: nfs
app: pvc
version: v1
spec:
accessModes:
-ReadWriteMany
resources:
requests:
storage: 1Gi
EOF
kubectl create -f pvc-lykops-sfs-0.yamlアクセスモード
PVCはPVと一致するアクセスモードを使用する.
しげん
PVCはPodと同様に特定の数のリソースを要求することができる.ここでのリクエスト内容はストレージです.ResourceModelで説明した内容はPVとPVCにも適用されます.
StatefulSet汎用
PodはPVCを利用してストレージにアクセスできる.PVCはPodと同じネーミングスペースにある必要があります.クラスタはPodネーミングスペースのPVCを見つけ,PVCを用いてPVCを取得する.このボリュームはホストにロードされ、Podが使用できるようになります.
cat << EOF > lykops-sfs.yaml
apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
name: lykops-sfs
labels:
software: apache
project: lykops
app: lykops-sfs
version: v1
spec:
serviceName: lykops-sfs
template:
metadata:
labels:
software: apache
project: lykops
app: lykops-sfs
version: v1
name: test-sfs
spec:
containers:
- name: lykops-sfs
image: web:apache
ports:
- containerPort: 80
name: apache
volumeMounts:
- name: pvc
mountPath: /data/
volumeClaimTemplates:
-metadata:
name: pvc
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 1Gi
EOF
kubectl create -f lykops-sfs.yamlPV、PVC、呼び出しリソースの作成上の注意事項
使用制限
PVC、PVはdeployment、rc、rsなどのシーンでは使用できません
命名規則
上記の例のように、
汎用PVCのStatefulSet:StatefulSet名はtest-sfs、ボリューム名はpvc
PV:pv-test-sfs-{0,1}
PVC:pvc-test-sfs-{0,1}
ルールは次のとおりです.
PVCとPVの命名規則は、リソースタイプ-statefulSet名-コピー数シーケンス番号(0から)
PVとPVCのyaml企画
ネーミングルールに加えて、accessModes、resourcesの両方にアクセスすることを保証する必要があります.
以上のルールに従って作成すると、PVとPVCが関連付けられていることがわかります