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:*→この下で、定義されたポッドで使用するボリューム名を定義します。