1 00:00:02,080 --> 00:00:02,980 So now 2 00:00:02,980 --> 00:00:06,320 to apply everything we configured here 3 00:00:06,320 --> 00:00:10,720 we of course can run the kube control, apply command. 4 00:00:10,720 --> 00:00:12,740 But before we do that, there's one thing I forgot 5 00:00:12,740 --> 00:00:14,390 which is all to pretty important. 6 00:00:14,390 --> 00:00:19,110 Kubernetes has a concept called storage classes 7 00:00:19,110 --> 00:00:21,490 and you got a storage class by default. 8 00:00:21,490 --> 00:00:26,110 If you run kube control get sc for storage classes, 9 00:00:26,110 --> 00:00:26,943 you'll see, 10 00:00:26,943 --> 00:00:30,430 there is a storage class by default here on minikube. 11 00:00:30,430 --> 00:00:33,320 The storage class is a number of concept, 12 00:00:33,320 --> 00:00:35,260 which you have in Kubernetes 13 00:00:35,260 --> 00:00:39,630 to give administrators fine grain control over 14 00:00:39,630 --> 00:00:43,860 how storage is managed and how volumes can be configured. 15 00:00:43,860 --> 00:00:45,260 It's an advanced concept 16 00:00:45,260 --> 00:00:47,060 and for our purposes here, 17 00:00:47,060 --> 00:00:50,790 the default storage class is absolutely fine. 18 00:00:50,790 --> 00:00:55,070 The storage class in the end defines two Kubernetes 19 00:00:55,070 --> 00:00:57,790 how exactly that storage, 20 00:00:57,790 --> 00:00:59,560 which we want to use in this case, 21 00:00:59,560 --> 00:01:04,290 the host path storage should be provisioned, you could say. 22 00:01:04,290 --> 00:01:06,550 So behind the scenes to storage class 23 00:01:06,550 --> 00:01:08,610 will provide important information 24 00:01:08,610 --> 00:01:12,050 to the PersistentVolume configuration we set up. 25 00:01:12,050 --> 00:01:14,700 It works together with the PersistentVolume 26 00:01:14,700 --> 00:01:17,010 and our standard storage class, 27 00:01:17,010 --> 00:01:19,780 which we got on minikube is already configured 28 00:01:19,780 --> 00:01:21,420 for this host path type, 29 00:01:21,420 --> 00:01:24,210 which is why it will work just fine here. 30 00:01:24,210 --> 00:01:26,220 We just need to make sure though, 31 00:01:26,220 --> 00:01:28,550 and that's the part which is missing 32 00:01:28,550 --> 00:01:31,860 that we're using this storage class. 33 00:01:31,860 --> 00:01:36,250 So therefore, in our PersistentVolume configuration file 34 00:01:36,250 --> 00:01:38,100 in the specification data 35 00:01:38,100 --> 00:01:42,020 somewhere next to capacity and volume mode, 36 00:01:42,020 --> 00:01:44,810 you should add a storageClassName 37 00:01:44,810 --> 00:01:47,183 and use standard here, 38 00:01:48,770 --> 00:01:53,033 because that is the name we have here, standard. 39 00:01:55,800 --> 00:01:59,763 Use that same storageClassName when you make your claim. 40 00:02:01,240 --> 00:02:05,070 So they're next to resources and access modes 41 00:02:05,070 --> 00:02:09,033 you wanna again have storageClassName, standard. 42 00:02:09,970 --> 00:02:11,510 Now with that done, 43 00:02:11,510 --> 00:02:16,090 we finalized this and now we can apply all of that. 44 00:02:16,090 --> 00:02:21,090 I'll first of all, apply the host-pv.yaml file 45 00:02:21,340 --> 00:02:23,560 so I will apply the PersistentVolume 46 00:02:24,853 --> 00:02:27,680 because applying to claim makes more sense 47 00:02:27,680 --> 00:02:29,253 if we already got the volume. 48 00:02:30,130 --> 00:02:32,100 So now this was created. 49 00:02:32,100 --> 00:02:35,800 Next, I will apply the host-pvc.yaml file 50 00:02:35,800 --> 00:02:39,060 to create the claim. 51 00:02:39,060 --> 00:02:39,893 And thereafter, 52 00:02:41,560 --> 00:02:44,670 we can of course also apply the deployment 53 00:02:44,670 --> 00:02:49,510 because we updated that deployment.yaml file to use that. 54 00:02:49,510 --> 00:02:50,800 Now here for me it's saying 55 00:02:50,800 --> 00:02:53,720 unchanged because I did test this in advance 56 00:02:53,720 --> 00:02:55,600 of course, I did run this in advance, 57 00:02:55,600 --> 00:02:57,740 but for you, it should say configured 58 00:02:57,740 --> 00:02:59,713 because it updated to deployment. 59 00:03:00,810 --> 00:03:03,530 Thereafter, you can run kube control get pv 60 00:03:03,530 --> 00:03:05,730 to get a list of all your PersistentVolumes. 61 00:03:06,890 --> 00:03:10,380 And there you should find your host PersistentVolume using 62 00:03:10,380 --> 00:03:13,683 the storageclass standard, which has a status of bound. 63 00:03:14,960 --> 00:03:17,360 And if you run kube control get pvc 64 00:03:17,360 --> 00:03:20,360 you find all your claims and there you should find 65 00:03:20,360 --> 00:03:22,283 that one claim that was made. 66 00:03:23,120 --> 00:03:25,900 And of course, if you get deployments 67 00:03:25,900 --> 00:03:27,330 you should get your deployment 68 00:03:27,330 --> 00:03:29,630 with the two up and running pods. 69 00:03:29,630 --> 00:03:31,700 Which should now be using 70 00:03:31,700 --> 00:03:34,693 this PersistentVolume as a volume. 71 00:03:35,950 --> 00:03:38,670 So therefore, with all of that up and running 72 00:03:38,670 --> 00:03:40,670 our service remained unchanged. 73 00:03:40,670 --> 00:03:42,260 So that should still work. 74 00:03:42,260 --> 00:03:44,500 Hence if you try to get a story, 75 00:03:44,500 --> 00:03:46,900 we still get our text here 76 00:03:46,900 --> 00:03:49,930 because I'm actually using the same host path here 77 00:03:49,930 --> 00:03:52,070 for my PersistentVolume, 78 00:03:52,070 --> 00:03:55,500 as I did before for the pod specific volume. 79 00:03:55,500 --> 00:03:58,020 That's why the data is still there 80 00:03:58,020 --> 00:04:01,000 because there's always was a path on the node 81 00:04:01,000 --> 00:04:04,150 and therefore, no matter if it's a PersistentVolume 82 00:04:04,150 --> 00:04:07,370 or the double kind of volume, the pod specific volume 83 00:04:07,370 --> 00:04:09,800 it was the same path on the node. 84 00:04:09,800 --> 00:04:13,810 And I also won't be able to show you much new behavior. 85 00:04:13,810 --> 00:04:15,350 If we crashed this, 86 00:04:15,350 --> 00:04:17,600 you will still see that the data is there 87 00:04:17,600 --> 00:04:21,160 because we already had that before with host path. 88 00:04:21,160 --> 00:04:24,310 The important difference now still is though 89 00:04:24,310 --> 00:04:27,420 that this PersistentVolume is independent from 90 00:04:27,420 --> 00:04:32,020 the path and from the node and the node independence is new. 91 00:04:32,020 --> 00:04:33,740 And that we have this independence 92 00:04:33,740 --> 00:04:35,490 not just with the host path, 93 00:04:35,490 --> 00:04:38,953 but with any supported type for PersistentVolumes. 94 00:04:40,276 --> 00:04:43,293 And you'll find these types in the official documentation. 95 00:04:44,300 --> 00:04:47,800 So now we really have that standalone volume 96 00:04:47,800 --> 00:04:52,800 and any part can now use our claim or we create a new claim 97 00:04:52,870 --> 00:04:55,130 if we need a different claim configuration. 98 00:04:55,130 --> 00:05:00,130 And we detached the volume and the volume configuration 99 00:05:00,210 --> 00:05:01,283 from our path. 100 00:05:02,600 --> 00:05:06,610 The only thing we do in the pod is reach out to our claim. 101 00:05:06,610 --> 00:05:09,440 All the configuration, then is in the claim 102 00:05:09,440 --> 00:05:14,000 and specifically in the PersistentVolume configuration. 103 00:05:14,000 --> 00:05:17,943 And now we achieve pod and node independence. 104 00:05:19,070 --> 00:05:21,570 So we learned about PersistentVolumes 105 00:05:21,570 --> 00:05:24,530 and it's a powerful feature because it allows us 106 00:05:24,530 --> 00:05:28,200 to store data in a way that will never be lost. 107 00:05:28,200 --> 00:05:30,600 Because it's node and pod independent 108 00:05:30,600 --> 00:05:33,350 and for some data that's crucial. 109 00:05:33,350 --> 00:05:34,970 I wanna come back to that state 110 00:05:34,970 --> 00:05:38,020 I talked about earlier in this module. 111 00:05:38,020 --> 00:05:40,820 There, we learned about two types of data, 112 00:05:40,820 --> 00:05:42,140 two types of state 113 00:05:42,140 --> 00:05:44,870 and that was some application data like 114 00:05:44,870 --> 00:05:49,230 user-generated data, user accounts, products in a shop, 115 00:05:49,230 --> 00:05:50,580 anything like that. 116 00:05:50,580 --> 00:05:53,993 And it would be intermediate results and temporary data. 117 00:05:54,850 --> 00:05:58,960 Now in both cases, volumes are great solutions. 118 00:05:58,960 --> 00:06:00,580 I wanna highlight though, 119 00:06:00,580 --> 00:06:04,080 that for intermediate temporary results 120 00:06:04,080 --> 00:06:07,770 pod specific volumes might be enough. 121 00:06:07,770 --> 00:06:11,020 You might not need a PersistentVolume for that 122 00:06:11,020 --> 00:06:13,540 though you of course could use it if you needed it 123 00:06:14,440 --> 00:06:17,370 especially for the left kind of data. 124 00:06:17,370 --> 00:06:21,140 So for the user generated data, user accounts and so on 125 00:06:21,140 --> 00:06:23,930 for that PersistentVolumes are awesome 126 00:06:23,930 --> 00:06:27,480 because your data is fully independent from the container 127 00:06:27,480 --> 00:06:30,600 but also, from the pod and from the node 128 00:06:30,600 --> 00:06:33,750 on which the pod runs if you use PersistentVolumes 129 00:06:33,750 --> 00:06:36,873 and PersistentVolume claims.