2回前提知識を挟んで、ようやくPersistentVolumeClaim(PVC)についての説明が開始できるようになりました。
今回はPersistentVolumeClaim(PVC)について、説明していきましょう。
Config&Storageリソースの概要
Config & Storageリソースは、設定や機密データをコンテナに埋め込んだり、永続ボリュームを提供するリソースです。
以下のものがあります。
- Secret：機密情報保存用
- ConfigMap：設定値や共通設定などの保存用
- PersistentVolumeClaim：Podが永続化ディスク(ディスク)を利用するためのリソース
PersistentVolumeClaim(PVC)とは
manifestのリソース指定：
kind: PersistentVolumeClaim
PersistentVolumeClaimは、公式ドキュメントでは以下のように説明されています。
A PersistentVolumeClaim (PVC) is a request for storage by a user. It is similar to a Pod. Pods consume node resources and PVCs consume PV resources. Pods can request specific levels of resources (CPU and Memory). Claims can request specific size and access modes (e.g., they can be mounted once read/write or many times read-only).
簡単に理解すると、PersistentVolumeClaimとは、PresistentVolumeの要求を行うリソースです。
k8sのリソースの中で、多数のPresistentVolume(PV)が存在していると、PodがどのPresistentVolumeを使うかを指定する必要が出てきます。
PersistentVolumeClaimはそのためのリソースです。
PersistentVolumeClaimの設定
PersistentVolumeClaimを作成する時に、以下の項目が設定できます。
- ラベルセレクタ
- 容量
- アクセスモード
- StorageClass
すべてPresistentVolumeが持っている設定項目です。
PersistentVolumeClaimの設定値にマッチするPresistentVolumeの中から、どれかをPodに紐づくようになります。
また、容量について、PersistentVolumeClaimの設定値以上のものはすべてマッチとみなされる。
PersistentVolumeClaimの使用例
前回のPresistentVolumeで使った例をここにも貼っておきます。
説明をPersistentVolumeClaimの部分をメインにします。
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv-demo
spec:
storageClassName: "example-storageclass"
capacity:
storage: 500G
accessModes:
- ReadWriteOnce
claimRef:
namespace: default
name: pv-claim-demo
gcePersistentDisk:
pdName: pd-name
fsType: ext4
---
# PVCの作成
# PVCの条件にマッチするPVが紐付けられます。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pv-claim-demo # PVC名
spec:
storageClassName: "example-storageclass" # StorageClass指定
accessModes: # アクセスモード指定
- ReadWriteOnce
resources: # 容量
requests:
storage: 500G # 同じサイズのPVがない場合、500G以上のものもマッチするDynamic Provisioning
Dynamic ProvisioningはPVCを作成するだけで、PVCで定義した条件に一致するPVが作成してくれる仕組みです。
要するるに、PVを気にする必要なく、PVCだけを作ればいいです。
この機能はGKE(GCP)でデフォルト作成されたStardandのStorageClassでDynamic Provisioningができます。
実は裏では、StorageClassで指定したprovisionerがこの仕事をしてくれます。
GKEの場合では、provisioner: kubernetes.io/gce-pdとなります。
自分でDynamic ProvisioningができるStorageClassを作成する例(GCP)
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: slow # StorageClass名
provisioner: kubernetes.io/gce-pd # 使うprovisionerの指定
parameters:
type: pd-standard # GCPのHDDディスク。pd-ssdはSSD。
replication-type: none # ゾーンレプリケーションしない。regional-pdは複数ゾーン間レプリケーションDynamic Provisioningの作成例
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-demo
spec:
# storageClassName: standard # GCPのデフォルト値
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 30Gi※この作成例はGCPの公式情報を使っています。
PVCとStatefulSetの併用
StatefulSetで永続化ディスクを使う場面が多いため、StatefulSetにはspec.volumeClaimTemplate項目があります。
これで、StatefulSetのmanifestにPVCを定義することが可能になる。
StatefulSetの例を使って、コメントで説明します。
# Headlessの作成
apiVersion: v1
kind: Service
metadata:
name: nginx
labels:
app: nginx
spec:
ports:
- port: 80
name: web
clusterIP: None
selector:
app: nginx
---
# StatefulSetの作成
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
spec:
selector:
matchLabels:
app: nginx # .spec.template.metadata.labelsの値と一致する必要があります
serviceName: "nginx"
replicas: 3 # by default is 1
template:
metadata:
labels:
app: nginx # .spec.selector.matchLabelsの値と一致する必要があります
spec:
terminationGracePeriodSeconds: 10
containers:
- name: nginx
image: k8s.gcr.io/nginx-slim:0.8
ports:
- containerPort: 80
name: web
volumeMounts:
- name: www
mountPath: /usr/share/nginx/html
volumeClaimTemplates: # PVCを作成する
- metadata:
name: www # PVC名
spec:
accessModes: [ "ReadWriteOnce" ] # アクセスモード
storageClassName: "my-storage-class" # StorageClass指定
resources: # 容量
requests:
storage: 1Gi # 1Gib最後に
今回で、Config&Storageのリソースについての紹介がすべて終わりました。
Config&Storageのリソースはk8sのデータを保持するために、大事なリソースとなります。
個人的にその中でも、結構使用頻度の高いものが以下のものかと思います。
- Secret
- ConfigMap
- PresistentVolumeClaim(PVC)
また、StatefulSetは多くの場合、永続化ディスクを持っているので、PVCとの併用もかなり多いかと思います。
ここまで読んでいただいて、お疲れ様でした。
コメント