1 00:00:01,020 --> 00:00:07,830 Hello and welcome to this lecture on Persistent Volumes in Kubernetes. In the previous lecture. 2 00:00:07,830 --> 00:00:10,210 We created a persistent volume. 3 00:00:10,290 --> 00:00:18,000 Now we will create a Persistent Volume Claim to make the storage available to a node. Persistent 4 00:00:18,000 --> 00:00:24,450 Volumes and Persistent Volume Claims are two separate objects in the Kubernetes namespace. 5 00:00:24,450 --> 00:00:31,050 An Administrator creates a set of Persistent Volumes and a user creates Persistent Volume Claims to 6 00:00:31,050 --> 00:00:32,230 use to storage. 7 00:00:32,910 --> 00:00:40,110 Once the Persistent Volume Claims are created, Kubernetes binds the Persistent Volumes to Claims based 8 00:00:40,110 --> 00:00:49,360 on the request and properties set on the volume. Every Persistent Volume Claims is bound to single Persistent 9 00:00:49,360 --> 00:00:56,500 volume during the binding process Kubernetes tries to find a persistent volume that has sufficient 10 00:00:56,500 --> 00:01:03,940 capacity as requested by the claim and any other request properties such as access modes volume modes 11 00:01:04,000 --> 00:01:11,950 storage class etc. However if there are multiple possible matches for a single claim and you would like 12 00:01:11,950 --> 00:01:18,700 to specifically use a particular volume you could still use labels and selectors to bind to the right 13 00:01:18,700 --> 00:01:20,140 volumes. 14 00:01:20,140 --> 00:01:27,610 Finally note that a smaller claim may get bound to a larger volume if all the other criteria matches 15 00:01:28,030 --> 00:01:30,230 and there are no better options. 16 00:01:30,310 --> 00:01:37,450 There is a one to one relationship between claims and volumes so no other claims can utilize the remaining 17 00:01:37,450 --> 00:01:39,720 capacity in the volume. 18 00:01:39,970 --> 00:01:46,970 If there are no volumes available the persistent volume claim will remain in a pending state until newer 19 00:01:46,980 --> 00:01:51,880 volumes are made available to the cluster once newer volumes are available. 20 00:01:51,880 --> 00:01:59,000 The claim would automatically be bound to the newly available volume let us now create a persistent 21 00:01:59,000 --> 00:02:00,270 volume claim. 22 00:02:00,290 --> 00:02:07,050 We start with a blank template said the API version to V1 and kind to persistent volume claim. 23 00:02:07,400 --> 00:02:15,170 We will name it myclaim. Under specification set the accessModes to ReadWriteOnce. And set resources 24 00:02:15,260 --> 00:02:23,180 to request a storage of 500 mega bytes. Create the claim using kubectl create command. To view the 25 00:02:23,180 --> 00:02:30,860 created claim run the kubectl get persistentvolumeclaim command. We see the claim in a pending state. 26 00:02:31,700 --> 00:02:38,210 When the claim is created, kubernetes looks at the volume created previously. The access Modes match. 27 00:02:38,720 --> 00:02:45,950 The capacity requested is 500 Megabytes but the volume is configured with 1 GB of storage. Since there 28 00:02:45,950 --> 00:02:48,440 are no other volumes available. 29 00:02:48,440 --> 00:02:55,910 The persistent volume claim is bound to persistent volume when we run to get volumes command again. 30 00:02:55,940 --> 00:03:04,360 We see the claim is bound to the persistent volume we created perfect. To delete a PVC run the kubectl 31 00:03:04,430 --> 00:03:11,060 delete persistent volume claim command but what happens to the underlying persistent volume when the 32 00:03:11,060 --> 00:03:12,560 claim is deleted. 33 00:03:12,740 --> 00:03:16,910 You can choose what is to happen to the volume by default. 34 00:03:17,000 --> 00:03:25,760 It is set to retain meaning the persistent volume will remain until it is manually deleted by the administrator. 35 00:03:25,760 --> 00:03:32,560 It is not available for reuse by any other claims or it can be deleted automatically. 36 00:03:32,600 --> 00:03:38,900 This way as soon as the claim is deleted the volume will be deleted as well thus freeing up storage 37 00:03:39,380 --> 00:03:44,810 on the end storage device or a third option is to recycle. 38 00:03:44,890 --> 00:03:51,950 In this case the data in the data volume will be scrubbed before making it available to other claims 39 00:03:53,000 --> 00:03:55,250 well that's it for this lecture. 40 00:03:55,250 --> 00:04:01,730 Head over to the coding exercises section and practice configuring and troubleshooting persistent volumes 41 00:04:01,850 --> 00:04:04,350 and volume claims in Kubernetes.