Kubernetes-volumes
提供:Dev Guides
Kubernetes-ボリューム
Kubernetesでは、ボリュームはポッド内のコンテナーからアクセス可能なディレクトリと考えることができます。 Kubernetesにはさまざまなタイプのボリュームがあり、タイプはボリュームの作成方法とそのコンテンツを定義します。
Dockerにはボリュームの概念がありましたが、唯一の問題はボリュームが特定のポッドに非常に限定されていたことでした。 ポッドの寿命が終了するとすぐに、ボリュームも失われました。
一方、Kubernetesを介して作成されるボリュームは、コンテナーに限定されません。 Kubernetesのポッド内に展開されたコンテナの一部またはすべてをサポートします。 Kubernetesボリュームの主な利点は、ポッドが複数のストレージを同時に使用できる異なる種類のストレージをサポートしていることです。
Kubernetesボリュームの種類
以下は、人気のあるKubernetesボリュームのリストです-
- emptyDir -ポッドがノードに最初に割り当てられたときに作成されるタイプのボリュームです。 Podがそのノードで実行されている限り、アクティブのままです。 ボリュームは最初は空であり、ポッド内のコンテナーはemptyDirボリューム内のファイルを読み書きできます。 ノードからポッドが削除されると、emptyDirのデータは消去されます。
- hostPath -このタイプのボリュームは、ホストノードのファイルシステムからポッドにファイルまたはディレクトリをマウントします。
- gcePersistentDisk -このタイプのボリュームは、Google Compute Engine(GCE)永続ディスクをポッドにマウントします。 ポッドがノードから削除されても、 gcePersistentDisk のデータはそのまま残ります。
- awsElasticBlockStore -このタイプのボリュームは、Amazon Web Services(AWS)Elastic Block Storeをポッドにマウントします。 gcePersistentDisk と同様に、 awsElasticBlockStore のデータは、ポッドがノードから削除されてもそのまま残ります。
- nfs - nfs ボリュームを使用すると、既存のNFS(ネットワークファイルシステム)をポッドにマウントできます。 ノードからポッドが削除されても、 nfs ボリュームのデータは消去されません。 ボリュームはアンマウントされているだけです。
- iscsi - iscsi ボリュームにより、既存のiSCSI(SCSI over IP)ボリュームをポッドにマウントできます。
- flocker -これは、オープンソースのクラスター化コンテナーデータボリュームマネージャーです。 データボリュームの管理に使用されます。 flocker ボリュームを使用すると、Flockerデータセットをポッドにマウントできます。 データセットがFlockerに存在しない場合、まずFlocker APIを使用して作成する必要があります。
- glusterfs -Glusterfsは、オープンソースのネットワークファイルシステムです。 glusterfsボリュームを使用すると、glusterfsボリュームをポッドにマウントできます。
- rbd -RBDはRados Block Deviceの略です。 rbd ボリュームを使用すると、Rados Block Deviceボリュームをポッドにマウントできます。 ノードからポッドが削除された後も、データは保持されたままです。
- cephfs - cephfs ボリュームを使用すると、既存のCephFSボリュームをポッドにマウントできます。 ポッドがノードから削除された後、データはそのまま残ります。
- gitRepo - gitRepo ボリュームは空のディレクトリをマウントし、ポッドが使用する git リポジトリをそこにクローンします。
- secret - secret ボリュームは、パスワードなどの機密情報をポッドに渡すために使用されます。
- persistentVolumeClaim - persistentVolumeClaim ボリュームは、PersistentVolumeをポッドにマウントするために使用されます。 PersistentVolumesは、特定のクラウド環境の詳細を知らなくても、ユーザーが永続ストレージ(GCE PersistentDiskやiSCSIボリュームなど)を「要求」する方法です。
- downwardAPI - downwardAPI ボリュームを使用して、アプリケーションで下位APIデータを利用できるようにします。 ディレクトリをマウントし、要求されたデータをプレーンテキストファイルに書き込みます。
- azureDiskVolume - AzureDiskVolume は、Microsoft Azureデータディスクをポッドにマウントするために使用されます。
永続ボリュームと永続ボリューム要求
永続ボリューム(PV)-管理者によってプロビジョニングされたネットワークストレージです。 これは、PVを使用する個々のポッドから独立したクラスター内のリソースです。
- Persistent Volume Claim(PVC)*-Kubernetesがポッド用に要求するストレージは、PVCと呼ばれます。 ユーザーは、基礎となるプロビジョニングを知る必要はありません。 クレームは、ポッドが作成されるのと同じネームスペースで作成する必要があります。
永続ボリュームの作成
kind: PersistentVolume ---------> 1
apiVersion: v1
metadata:
name: pv0001 ------------------> 2
labels:
type: local
spec:
capacity: -----------------------> 3
storage: 10Gi ----------------------> 4
accessModes:
- ReadWriteOnce -------------------> 5
hostPath:
path: "/tmp/data01" --------------------------> 6
上記のコードでは、定義しています-
- kind:PersistentVolume →使用されているyamlファイルが永続ボリュームを作成することであることをkubernetesに伝えるPersistentVolumeとして種類を定義しました。
- name:pv0001 →作成しているPersistentVolumeの名前。
- 容量:→この仕様は、作成しようとしているPVの容量を定義します。
- storage:10Gi →これは、定義されたパス上の10Giスペースを要求しようとしていることを、基盤となるインフラストラクチャに伝えます。
- ReadWriteOnce →これは、作成しているボリュームのアクセス権を示します。
- path: "/tmp/data01" →この定義は、基礎となるインフラストラクチャ上のこのパスの下にボリュームを作成しようとしていることをマシンに伝えます。
PVの作成
$ kubectl create –f local-01.yaml
persistentvolume "pv0001" created
PVの確認
$ kubectl get pv
NAME CAPACITY ACCESSMODES STATUS CLAIM REASON AGE
pv0001 10Gi RWO Available 14s
PVの説明
$ kubectl describe pv pv0001
永続的なボリューム要求の作成
kind: PersistentVolumeClaim --------------> 1
apiVersion: v1
metadata:
name: myclaim-1 --------------------> 2
spec:
accessModes:
- ReadWriteOnce ------------------------> 3
resources:
requests:
storage: 3Gi ---------------------> 4
上記のコードでは、定義しています-
- kind:PersistentVolumeClaim →指定された容量を要求しようとしている基盤インフラストラクチャに指示します。
- name:myclaim-1 →作成しようとしているクレームの名前。
- ReadWriteOnce →これは、作成しようとしているクレームのモードを指定します。
- *ストレージ:3Gi *→これにより、kubernetesに要求しようとしているスペースの量が通知されます。
PVCの作成
$ kubectl create –f myclaim-1
persistentvolumeclaim "myclaim-1" created
PVCに関する詳細の取得
$ kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESSMODES AGE
myclaim-1 Bound pv0001 10Gi RWO 7s
PVCの説明
$ kubectl describe pv pv0001
PODでPVおよびPVCを使用する
kind: Pod
apiVersion: v1
metadata:
name: mypod
labels:
name: frontendhttp
spec:
containers:
- name: myfrontend
image: nginx
ports:
- containerPort: 80
name: "http-server"
volumeMounts: ----------------------------> 1
- mountPath: "/usr/share/tomcat/html"
name: mypd
volumes: -----------------------> 2
- name: mypd
persistentVolumeClaim: ------------------------->3
claimName: myclaim-1
上記のコードでは、定義しています-
- * volumeMounts:*→これは、マウントが行われるコンテナ内のパスです。
- ボリューム:→この定義は、クレームするボリューム定義を定義します。
- * persistentVolumeClaim:*→この下で、定義されたポッドで使用するボリューム名を定義します。