Persistent Volumes and Persistent Volume Claims

  • PVs are created by cluster administrators and they are consumed by PVCs which are created by developers.
  • A PV is like a mounting configuration of storage. Therefore, you can create different mount configurations for the same storage by creating multiple PVs.
  • A PV is a public resource in a cluster, which means it is accessible to all the namespaces. This also means the name of the PV needs to be unique in the whole cluster.
  • A PVC is a k8s object within a namespace, which means its name must be unique in the namespace.
  • A PV can only be exclusively bound to a PVC. This one-to-one mapping lasts until the PVC is deleted.
  • A PV and its bound PVC builds a bridge between the “clients” (Pods) and the real storage.

Provisioning Persistent Volumes

“Static” Persistent Volumes

apiVersion: v1
kind: PersistentVolume
metadata:
name: nfs-pv
spec:
nfs:
# TODO: use right IP
server: 12.34.56.78
path: "/data"
readOnly: false
mountOptions:
- vers=4.0
- rsize=32768
- wsize=32768
capacity:
storage: 10Gi
accessModes:
- ReadWriteMany
persistentVolumeReclaimPolicy: Retain
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: nfs-pvc
spec:
resources:
requests:
storage: 10Gi
accessModes:
- ReadWriteMany
selector:
matchLabels:
pv-name: nfs-pv
apiVersion: v1
kind: Pod
metadata:
name: nfs-pod
labels:
app: nfs-pods
spec:
volumes:
- name: data-dir
persistentVolumeClaim:
claimName: nfs-pvc

containers:
- name: nginx
image: nginx
volumeMounts:
- name: data-dir
mountPath: "/usr/share/nginx/html"
readOnly: false
  • ReadWriteOnce: a PV can be mounted as read-write by a single node if it has ReadWriteOnce in its accessModes spec. This means 1. the PV can perform read and write operation to storage. 2. The PV can only be mounted on a single node, which means any Pod that wants to use this PV must be scheduled to the same node as well.
  • ReadOnlyMany: a PV can be mounted as read-only by many nodes if it has ReadOnlyMany in its accessModes spec. Unlike ReadWriteOnce, ReadOnlyMany allows the PV to be mounted on many nodes but it can only perform read operation to the real storage. Any write request will be denied in this case.
  • ReadWriteMany: a PV can be mounted as read-write by many nodes if it has ReadWriteMany in its accessModes spec. This means the PV can perform read and write operations in many nodes.
  • The attribute readOnly of a PV type is a storage side setting. It is used to control whether real storage is read-only or not.
  • AccessModes of a PV is a PV side setting and it is used to control the access mode of the PV.
  • AccessModes of a PVC has to match up the PV that it wants to bind. A PV and a PVC build a bridge between the "client" and the real storage: the PV connects to the real storage while the PVC connects to the "client".
  • The attribute readOnly of VolumeMount is a "client" side setting. It is used to control whether the mounted directory is read-only or not.

“Dynamic” Persistent Volumes

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: standard
parameters:
type: pd-standard
provisioner: kubernetes.io/gce-pd
reclaimPolicy: Delete
volumeBindingMode: Immediate
  • The field metadata.name is the name of the StorageClass. It has to be unique in the whole cluster.
  • The field parameters specifies the parameters for the real storage. For example, parameters.type == pd-standard means this storage class uses GCEPersistentDisk as storage media. You can check this doc for more details about the parameters of Storage Classes.
  • The fieldprovisioner specifies which volume plugin is used by the Storage Class to provision dynamic PVs. You can check this list for each provisioner's specification.
  • Like persistentVolumeReclaimPolicy, the field reclaimPolicy specifies the reclaim policy for the storage created by the Storage Class. It can be either Delete (default value) or Retain.
  • The volumeBindingMode field controls when to perform dynamic provisioning and volume binding. volumeBindingMode == Immediate means doing dynamic provisioning and volume binding once the PVC is created, while volumeBindingMode == WaitForFirstConsumer means delaying dynamic provisioning and volume binding until the PVC is actually being consumed.
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: zoo-keepr
# StatefulSet spec
spec:
serviceName: zk-hs
selector:
matchLabels:
app: zk
replicas: 3

volumeClaimTemplates:
- metadata:
name: datadir
spec:
storageClassName: standard
accessModes: [ "ReadWriteOnce" ]
resources:
requests:
storage: 10Gi

# Pod spec
template:
metadata:
labels:
app: zk
spec:
containers:
- name: k8szk
image: gcr.io/google_samples/k8szk:v3
...
volumeMounts:
- name: datadir
mountPath: /var/lib/zookeeper

“Updating” PVs & PVCs

Updating Static PVs

Updating Dynamic PVs

What Is Next

Reference

--

--

--

A software engineer

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

SolDate 👄 is built to reward platform users.

Intermediate: Improve Application Quality using Huawei Crash Service in Xamarin(Android)

Partnership with Matry Announcement

Data Infrastructure at Uniplaces

Export organizational structure to CSV and build reports using Excel and Power BI

How to Setup HAproxy(Load Balancer) using Ansible.

Docker Vs Podman

Learn: SwiftUI with Simple Login Design

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Aaron Zhuo

Aaron Zhuo

A software engineer

More from Medium

Creating your own Template in Monokle

Kubernetes and its Use-Cases

Decrease your Organization’s Carbon footprints using Kubernetes