Kubernetes-ボリューム
Kubernetesでは、ボリュームはポッド内のコンテナにアクセスできるディレクトリと考えることができます。Kubernetesにはさまざまなタイプのボリュームがあり、そのタイプによってボリュームの作成方法とそのコンテンツが定義されます。
ボリュームの概念はDockerに存在していましたが、唯一の問題は、ボリュームが特定のポッドに非常に限定されていることでした。ポッドの寿命が尽きるとすぐに、音量も失われました。
一方、Kubernetesを介して作成されるボリュームは、どのコンテナにも限定されません。Kubernetesのポッド内にデプロイされたコンテナの一部またはすべてをサポートします。Kubernetesボリュームの主な利点は、ポッドが複数のストレージを同時に使用できるさまざまな種類のストレージをサポートすることです。
Kubernetesボリュームの種類
これがいくつかの人気のあるKubernetesボリュームのリストです-
emptyDir−ポッドが最初にノードに割り当てられたときに作成されるボリュームのタイプです。ポッドがそのノードで実行されている限り、アクティブなままです。ボリュームは最初は空であり、ポッド内のコンテナーはemptyDirボリューム内のファイルを読み書きできます。ポッドがノードから削除されると、emptyDirのデータは消去されます。
hostPath −このタイプのボリュームは、ファイルまたはディレクトリをホストノードのファイルシステムからポッドにマウントします。
gcePersistentDisk−このタイプのボリュームは、Google Compute Engine(GCE)永続ディスクをポッドにマウントします。のデータgcePersistentDisk ポッドがノードから削除されても、そのまま残ります。
awsElasticBlockStore−このタイプのボリュームは、Amazon Web Services(AWS)Elastic BlockStoreをポッドにマウントします。と同じようにgcePersistentDisk、のデータ awsElasticBlockStore ポッドがノードから削除されても、そのまま残ります。
nfs − nfsボリュームを使用すると、既存のNFS(ネットワークファイルシステム)をポッドにマウントできます。のデータnfsポッドがノードから削除されても、ボリュームは消去されません。ボリュームはマウント解除されているだけです。
iscsi − iscsi ボリュームを使用すると、既存のiSCSI(SCSI over IP)ボリュームをポッドにマウントできます。
flocker−オープンソースのクラスター化コンテナーデータボリュームマネージャーです。データ量の管理に使用されます。Aflockerボリュームを使用すると、Flockerデータセットをポッドにマウントできます。データセットがFlockerに存在しない場合は、最初にFlockerAPIを使用してデータセットを作成する必要があります。
glusterfs− Glusterfsは、オープンソースのネットワーク化されたファイルシステムです。glusterfsボリュームを使用すると、glusterfsボリュームをポッドにマウントできます。
rbd−RBDはRadosBlockDeviceの略です。アンrbdボリュームを使用すると、Rados BlockDeviceボリュームをポッドにマウントできます。ポッドがノードから削除された後も、データは保持されたままです。
cephfs − a cephfsボリュームを使用すると、既存のCephFSボリュームをポッドにマウントできます。ポッドがノードから削除された後も、データはそのまま残ります。
gitRepo − a gitRepo ボリュームは空のディレクトリをマウントし、クローンを作成します git ポッドが使用するためのリポジトリ。
secret − a secret ボリュームは、パスワードなどの機密情報をポッドに渡すために使用されます。
persistentVolumeClaim − a persistentVolumeClaimボリュームは、PersistentVolumeをポッドにマウントするために使用されます。PersistentVolumesは、ユーザーが特定のクラウド環境の詳細を知らなくても、耐久性のあるストレージ(GCE PersistentDiskやiSCSIボリュームなど)を「要求」する方法です。
downwardAPI − a downwardAPIボリュームは、アプリケーションが下位APIデータを利用できるようにするために使用されます。ディレクトリをマウントし、要求されたデータをプレーンテキストファイルに書き込みます。
azureDiskVolume − AzureDiskVolume MicrosoftAzureデータディスクをポッドにマウントするために使用されます。
永続ボリュームと永続ボリュームの要求
Persistent Volume (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 →種類をPersistentVolumeとして定義しました。これは、使用されているyamlファイルが永続ボリュームを作成することであることをkubernetesに通知します。
name: pv0001 →作成するPersistentVolumeの名前。
capacity: →この仕様は、私たちが作成しようとしている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 →これは、作成しようとしているクレームのモードを指定します。
storage: 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: →これは、取り付けが行われるコンテナ内のパスです。
Volume: →この定義は、主張するボリューム定義を定義します。
persistentVolumeClaim: →この下で、定義されたポッドで使用するボリューム名を定義します。