{"id":6321,"date":"2019-04-04T16:00:03","date_gmt":"2019-04-04T16:00:03","guid":{"rendered":"http:\/\/howk.de\/w1\/blog-kubernetes-1-14-local-persistent-volumes-ga\/"},"modified":"2019-04-04T16:00:03","modified_gmt":"2019-04-04T16:00:03","slug":"blog-kubernetes-1-14-local-persistent-volumes-ga","status":"publish","type":"post","link":"https:\/\/howk.de\/?p=6321","title":{"rendered":"Blog: Kubernetes 1.14: Local Persistent Volumes GA"},"content":{"rendered":"

Authors<\/strong>: Michelle Au (Google), Matt Schallert (Uber), Celina Ward (Uber)<\/p>\n

The Local Persistent Volumes<\/a>
\nfeature has been promoted to GA in Kubernetes 1.14.
\nIt was first introduced as alpha in Kubernetes 1.7, and then
\nbeta<\/a> in Kubernetes
\n1.10. The GA milestone indicates that Kubernetes users may depend on the feature
\nand its API for production use. GA features are protected by the Kubernetes
\ndeprecation
\npolicy<\/a>.<\/p>\n

What is a Local Persistent Volume?<\/h2>\n

A local persistent volume represents a local disk directly-attached to a single
\nKubernetes Node.<\/p>\n

Kubernetes provides a powerful volume plugin system that enables Kubernetes
\nworkloads to use a wide
\nvariety<\/a>
\nof block and file storage to persist data. Most
\nof these plugins enable remote storage – these remote storage systems persist
\ndata independent of the Kubernetes node where the data originated. Remote
\nstorage usually can not offer the consistent high performance guarantees of
\nlocal directly-attached storage. With the Local Persistent Volume plugin,
\nKubernetes workloads can now consume high performance local storage using the
\nsame volume APIs that app developers have become accustomed to.<\/p>\n

How is it different from a HostPath Volume?<\/h2>\n

To better understand the benefits of a Local Persistent Volume, it is useful to
\ncompare it to a HostPath volume<\/a>.
\nHostPath volumes mount a file or directory from
\nthe host node\u2019s filesystem into a Pod. Similarly a Local Persistent Volume
\nmounts a local disk or partition into a Pod.<\/p>\n

The biggest difference is that the Kubernetes scheduler understands which node a
\nLocal Persistent Volume belongs to. With HostPath volumes, a pod referencing a
\nHostPath volume may be moved by the scheduler to a different node resulting in
\ndata loss. But with Local Persistent Volumes, the Kubernetes scheduler ensures
\nthat a pod using a Local Persistent Volume is always scheduled to the same node.<\/p>\n

While HostPath volumes may be referenced via a Persistent Volume Claim (PVC) or
\ndirectly inline in a pod definition, Local Persistent Volumes can only be
\nreferenced via a PVC. This provides additional security benefits since
\nPersistent Volume objects are managed by the administrator, preventing Pods from
\nbeing able to access any path on the host.<\/p>\n

Additional benefits include support for formatting of block devices during
\nmount, and volume ownership using fsGroup.<\/p>\n

What’s New With GA?<\/h2>\n

Since 1.10, we have mainly focused on improving stability and scalability of the
\nfeature so that it is production ready.<\/p>\n

The only major feature addition is the ability to specify a raw block device and
\nhave Kubernetes automatically format and mount the filesystem. This reduces the
\nprevious burden of having to format and mount devices before giving it to
\nKubernetes.<\/p>\n

Limitations of GA<\/h2>\n

At GA, Local Persistent Volumes do not support dynamic volume
\nprovisioning<\/a>.
\nHowever there is an external
\ncontroller<\/a>
\navailable to help manage the local
\nPersistentVolume lifecycle for individual disks on your nodes. This includes
\ncreating the PersistentVolume objects, cleaning up and reusing disks once they
\nhave been released by the application.<\/p>\n

How to Use a Local Persistent Volume?<\/h2>\n

Workloads can request a local persistent volume using the same
\nPersistentVolumeClaim interface as remote storage backends. This makes it easy
\nto swap out the storage backend across clusters, clouds, and on-prem
\nenvironments.<\/p>\n

First, a StorageClass should be created that sets volumeBindingMode:
\nWaitForFirstConsumer<\/code> to enable volume topology-aware
\nscheduling<\/a>.
\nThis mode instructs Kubernetes to wait to bind a PVC until a Pod using it is scheduled.<\/p>\n

kind: StorageClass\napiVersion: storage.k8s.io\/v1\nmetadata:\nname: local-storage\nprovisioner: kubernetes.io\/no-provisioner\nvolumeBindingMode: WaitForFirstConsumer\n<\/code><\/pre>\n
Then, the external static provisioner can be configured and
\nrun<\/a> to create PVs
\nfor all the local disks on your nodes.<\/p>\n
$ kubectl get pv\nNAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE\nlocal-pv-27c0f084 368Gi RWO Delete Available local-storage 8s\nlocal-pv-3796b049 368Gi RWO Delete Available local-storage 7s\nlocal-pv-3ddecaea 368Gi RWO Delete Available local-storage 7s\n<\/code><\/pre>\n
Afterwards, workloads can start using the PVs by creating a PVC and Pod or a
\nStatefulSet with volumeClaimTemplates.<\/p>\n
apiVersion: apps\/v1\nkind: StatefulSet\nmetadata:\nname: local-test\nspec:\nserviceName: "local-service"\nreplicas: 3\nselector:\nmatchLabels:\napp: local-test\ntemplate:\nmetadata:\nlabels:\napp: local-test\nspec:\ncontainers:\n- name: test-container\nimage: k8s.gcr.io\/busybox\ncommand:\n- "\/bin\/sh"\nargs:\n- "-c"\n- "sleep 100000"\nvolumeMounts:\n- name: local-vol\nmountPath: \/usr\/test-pod\nvolumeClaimTemplates:\n- metadata:\nname: local-vol\nspec:\naccessModes: [ "ReadWriteOnce" ]\nstorageClassName: "local-storage"\nresources:\nrequests:\nstorage: 368Gi\n<\/code><\/pre>\n
Once the StatefulSet is up and running, the PVCs are all bound:<\/p>\n
$ kubectl get pvc\nNAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE\nlocal-vol-local-test-0 Bound local-pv-27c0f084 368Gi RWO local-storage 3m45s\nlocal-vol-local-test-1 Bound local-pv-3ddecaea 368Gi RWO local-storage 3m40s\nlocal-vol-local-test-2 Bound local-pv-3796b049 368Gi RWO local-storage 3m36s\n<\/code><\/pre>\n
When the disk is no longer needed, the PVC can be deleted. The external static provisioner
\nwill clean up the disk and make the PV available for use again.<\/p>\n
$ kubectl patch sts local-test -p '{"spec":{"replicas":2}}'\nstatefulset.apps\/local-test patched\n$ kubectl delete pvc local-vol-local-test-2\npersistentvolumeclaim "local-vol-local-test-2" deleted\n$ kubectl get pv\nNAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE\nlocal-pv-27c0f084 368Gi RWO Delete Bound default\/local-vol-local-test-0 local-storage 11m\nlocal-pv-3796b049 368Gi RWO Delete Available local-storage 7s\nlocal-pv-3ddecaea 368Gi RWO Delete Bound default\/local-vol-local-test-1 local-storage 19m\n<\/code><\/pre>\n
You can find full documentation<\/a>
\nfor the feature on the Kubernetes website.<\/p>\n
What Are Suitable Use Cases?<\/h2>\n
The primary benefit of Local Persistent Volumes over remote persistent storage
\nis performance: local disks usually offer higher IOPS and throughput and lower
\nlatency compared to remote storage systems.<\/p>\n
However, there are important limitations and caveats to consider when using
\nLocal Persistent Volumes:<\/p>\n