Thus far, we've seen examples of directly provisioning the storage within our pod definitions. This works quite well if you have full control over your cluster and infrastructure, but at larger scales, application owners will want to use storage that is managed separately. Typically, a central IT team or the cloud provider will take care of the details behind provisioning storage and leave the application owners to worry about their primary concern, the application itself. This separation of concerns and duties in Kubernetes allows you to structure your engineering focus around a storage subsystem that can be managed by a distinct group of engineers.

In order to accommodate this, we need some way for the application to specify and request storage without being concerned with how that storage is provided. This is where PersistentVolumes and PersistentVolumeClaim come into play.

PersistentVolumes are similar to the volumes we created earlier, but they are provided by the cluster administrator and are not dependent on a particular pod. PersistentVolumes are a resource that's provided to the cluster just like any other object. The Kubernetes API provides an interface for this object in the form of NFS, EBS Persistent Disks, or any other volume type described before. Once the volume has been created, you can use PersistentVolumeClaims to request storage for your applications.

PersistentVolumeClaims is an abstraction that allows users to specify the details of the storage needed. We can defined the amount of storage, as well as the access type, such as ReadWriteOnce (read and write by one node), ReadOnlyMany (read-only by multiple nodes), and ReadWriteMany (read and write by many nodes). The cluster operators are in charge of providing a wide variety of storage options for application operators in order to meet requirements across a number of different access modes, sizes, speeds, and durability without requiring the end users to know the details of that implementation. The modes supported by cluster operators is dependent on the backing storage provider. For example, we saw in the AWS aws-ebs example that mounting to multiple nodes was not an option, while with GCP Persistent Disks could be shared among several nodes in read-only mode. 

Additionally, Kubernetes provides two other methods for specifying certain groupings or types of storage volumes. The first is the use of selectors, as we have seen previously for pod selection. Here, labels can be applied to storage volumes and then claims can reference these labels to further filter the volume they are provided. Second, Kubernetes has the concept of StorageClass, which allows us specify a storage provisioner and parameters for the types of volumes it provisions.

PersistentVolumes and PersistentVolumeClaims have a life cycle that involves the following phases:

• Provisioning
• Static or dynamic
• Binding
• Using
• Reclaiming
• Delete, retain, or recycle

We will dive into Storage Classes in the next section, but here is a quick example of a PersistentVolumeClaim for illustration purposes. You can see in the annotations that we request 1Gi of storage in ReadWriteOnce mode with a StorageClass of solidstate and a label of aws-storage. Save the following code as the pvc-example.yaml file:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: demo-claim
spec:
  accessModes:
  - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 1Gi
  storageClassName: ssd
  selector:
    matchLabels:
      release: "aws-storage"
  matchExpressions:
      - {key: environment, operator: In, values: [dev, stag, uat]}

As of Kubernetes version 1.8, there's also alpha support for expanding PersistentVolumeClaim for gcePersistentDisk, awsElasticBlockStore, Cinder, glusterfs, and rbd volume claim types. These are similar to the thin provisioning that you may have seen with systems such as VMware, and they allow for resizing of a storage class via the allowVolumeExpansion field as long as you're running either XFS or Ext3/Ext4 filesystems. Here's a quick example of what that looks like:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
 name: Cinder-volume-01
provisioner: kubernetes.io/cinder
parameters:
 resturl: "http://192.168.10.10:8080"
 restuser: ""
 secretNamespace: ""
 secretName: ""
allowVolumeExpansion: true