1 00:00:02,220 --> 00:00:03,780 Over the last lectures, 2 00:00:03,780 --> 00:00:07,600 we talked a lot about volumes and persistent volumes. 3 00:00:07,600 --> 00:00:09,340 And from my own experience, 4 00:00:09,340 --> 00:00:12,460 I know that it can be confusing that you have 5 00:00:12,460 --> 00:00:14,980 these different kinds of volumes. 6 00:00:14,980 --> 00:00:18,230 So in this lecture, I wanna compare the two approaches 7 00:00:18,230 --> 00:00:22,020 and make it really clear why we have these two approaches 8 00:00:22,020 --> 00:00:25,810 and which one should be used in which situation. 9 00:00:25,810 --> 00:00:28,140 The first very important thing, 10 00:00:28,140 --> 00:00:31,830 I wanna make absolutely clear though, is that volumes, 11 00:00:31,830 --> 00:00:35,160 no matter if you use the regular volumes 12 00:00:35,160 --> 00:00:40,160 or persistent volumes allow you to persist data. 13 00:00:40,540 --> 00:00:43,960 So even though these normal volumes, 14 00:00:43,960 --> 00:00:47,390 which were defined together with a pod definition 15 00:00:47,390 --> 00:00:52,210 are not labeled such, they do help you persist data. 16 00:00:52,210 --> 00:00:56,040 It's not just persistent volumes that help you with that. 17 00:00:56,040 --> 00:00:59,620 This name can be deceiving and misleading. 18 00:00:59,620 --> 00:01:02,980 The idea behind all volumes here is 19 00:01:02,980 --> 00:01:05,150 that you have data in a container 20 00:01:05,150 --> 00:01:08,870 which should not be lost when the container restarts 21 00:01:08,870 --> 00:01:11,110 or is removed and recreated, 22 00:01:11,110 --> 00:01:14,540 and both types of volumes help you with that. 23 00:01:14,540 --> 00:01:17,800 Now, when it comes to the normal volumes here, 24 00:01:17,800 --> 00:01:19,570 which is not an official term, 25 00:01:19,570 --> 00:01:21,830 just a term I came up with here, 26 00:01:21,830 --> 00:01:24,080 it is important to realize that 27 00:01:24,080 --> 00:01:26,870 they are independent from containers, 28 00:01:26,870 --> 00:01:29,350 but not independent from pods. 29 00:01:29,350 --> 00:01:34,350 They are attached to individual pods and they are lifecycle. 30 00:01:34,530 --> 00:01:38,650 Which means if a part is deleted and removed, 31 00:01:38,650 --> 00:01:41,960 a volume attached to this pod might 32 00:01:41,960 --> 00:01:44,100 also have its data cleared. 33 00:01:44,100 --> 00:01:46,760 It's then depends on the volume type. 34 00:01:46,760 --> 00:01:49,050 For example, the empty dirt type, 35 00:01:49,050 --> 00:01:53,050 would then start again empty if the pod is recreated. 36 00:01:53,050 --> 00:01:55,490 Our volume types like host path 37 00:01:55,490 --> 00:01:57,650 and certain cloud provider types, 38 00:01:57,650 --> 00:02:00,600 of course would not lose their data. 39 00:02:00,600 --> 00:02:02,900 But either way, the volume definition 40 00:02:02,900 --> 00:02:07,180 and the volume configuration is closely tied to a pod. 41 00:02:07,180 --> 00:02:09,500 And indeed we do define 42 00:02:09,500 --> 00:02:13,900 and writes down the volume configuration in the same file 43 00:02:13,900 --> 00:02:15,810 as we define the pod. 44 00:02:15,810 --> 00:02:20,180 It's in the pod template where we don't just define 45 00:02:20,180 --> 00:02:23,180 how the volume is mounted into the container, 46 00:02:23,180 --> 00:02:26,970 but where we also define which volume type to use. 47 00:02:26,970 --> 00:02:29,590 That's what you saw a couple of lectures ago 48 00:02:29,590 --> 00:02:31,770 for these regular volumes. 49 00:02:31,770 --> 00:02:35,420 You saw it for both empty dirt and host path. 50 00:02:35,420 --> 00:02:38,480 Now I outlined that one problem could be 51 00:02:38,480 --> 00:02:41,610 that your data is lost when the pod is removed. 52 00:02:41,610 --> 00:02:43,380 But as I just said already, 53 00:02:43,380 --> 00:02:47,570 that's depends on the type of volume driver you're using. 54 00:02:47,570 --> 00:02:50,100 The bigger problem, which you might face, 55 00:02:50,100 --> 00:02:53,950 even if you use a volume type where data is not lost, 56 00:02:53,950 --> 00:02:56,220 is that it can be repetitive 57 00:02:56,220 --> 00:02:59,720 and hard to administer on a global level 58 00:02:59,720 --> 00:03:04,230 if you work with these pods specific volumes only. 59 00:03:04,230 --> 00:03:05,430 For a small apps, 60 00:03:05,430 --> 00:03:08,220 or if you're the only one working on this project, 61 00:03:08,220 --> 00:03:10,220 it might not be a problem at all. 62 00:03:10,220 --> 00:03:12,110 Though even in that case, 63 00:03:12,110 --> 00:03:14,240 you might have a lot of repetition. 64 00:03:14,240 --> 00:03:15,860 If you have different pods, 65 00:03:15,860 --> 00:03:19,050 different deployments with different pod templates, 66 00:03:19,050 --> 00:03:21,840 and you need the same volume configuration 67 00:03:21,840 --> 00:03:23,460 on different parts, 68 00:03:23,460 --> 00:03:26,780 you need to repeat that same volume set up code 69 00:03:26,780 --> 00:03:29,580 in all your different pod templates. 70 00:03:29,580 --> 00:03:30,963 So that might be annoying. 71 00:03:31,970 --> 00:03:34,310 And if you're working in a bigger project 72 00:03:34,310 --> 00:03:37,330 and you're the administrator responsible 73 00:03:37,330 --> 00:03:40,060 for setting up all the storage and the volumes, 74 00:03:40,060 --> 00:03:41,930 then you always need to 75 00:03:41,930 --> 00:03:45,510 go into the pod templates your colleagues created 76 00:03:45,510 --> 00:03:48,270 just to set up the volume configuration there. 77 00:03:48,270 --> 00:03:50,740 So this could also be annoying. 78 00:03:50,740 --> 00:03:53,680 And that is the very specific problem 79 00:03:53,680 --> 00:03:56,420 to gather with the data persistence, 80 00:03:56,420 --> 00:03:59,580 which to persistent volumes solve. 81 00:03:59,580 --> 00:04:03,520 Because their volumes are not defined together 82 00:04:03,520 --> 00:04:06,740 with pods and therefore attached to pods. 83 00:04:06,740 --> 00:04:09,560 Instead they are standalone resources 84 00:04:09,560 --> 00:04:12,040 in your Kubernetes cluster. 85 00:04:12,040 --> 00:04:15,450 They are not attached to a specific pod. 86 00:04:15,450 --> 00:04:17,570 They can be created standalone. 87 00:04:17,570 --> 00:04:19,370 And then they are claimed with 88 00:04:19,370 --> 00:04:22,790 these persistent volume claims which you saw. 89 00:04:22,790 --> 00:04:24,470 But of course, that means 90 00:04:24,470 --> 00:04:27,750 that if you need the same volume configuration, 91 00:04:27,750 --> 00:04:30,810 the same volume type with the same path 92 00:04:30,810 --> 00:04:33,640 or whatever it is in different parts, 93 00:04:33,640 --> 00:04:37,600 then you just need to create this persistent volume once 94 00:04:37,600 --> 00:04:41,020 and it can be claimed by these different pods. 95 00:04:41,020 --> 00:04:44,290 So the configuration lives in one file 96 00:04:44,290 --> 00:04:47,080 and therefore it's easy to reuse. 97 00:04:47,080 --> 00:04:48,770 You have less repetition. 98 00:04:48,770 --> 00:04:51,820 And of course, it's also easier to administer 99 00:04:51,820 --> 00:04:54,010 if you are the administrator 100 00:04:54,010 --> 00:04:56,730 responsible for managing all the storage 101 00:04:56,730 --> 00:04:59,390 and the volumes in the cluster. 102 00:04:59,390 --> 00:05:01,830 So especially for bigger projects, 103 00:05:01,830 --> 00:05:05,460 these persistent volumes can make it way easier 104 00:05:05,460 --> 00:05:07,970 to manage all the storage options 105 00:05:07,970 --> 00:05:12,280 and all the volumes your clusters should be able to use. 106 00:05:12,280 --> 00:05:15,440 And then some colleagues could focus on 107 00:05:15,440 --> 00:05:17,620 setting up the pods templates 108 00:05:17,620 --> 00:05:20,400 and they would only need to specify the claim 109 00:05:20,400 --> 00:05:21,480 which they wanna use, 110 00:05:21,480 --> 00:05:22,840 and they would not need to 111 00:05:22,840 --> 00:05:26,120 write any volume specific configuration logic 112 00:05:26,120 --> 00:05:28,160 in their templates. 113 00:05:28,160 --> 00:05:30,890 And on the apprehended would be super easy 114 00:05:30,890 --> 00:05:34,030 to manage all the volumes on a global level, 115 00:05:34,030 --> 00:05:36,820 without touching pod templates at all. 116 00:05:36,820 --> 00:05:38,540 And in addition then, 117 00:05:38,540 --> 00:05:40,960 you have to spot and note independence 118 00:05:40,960 --> 00:05:43,540 which I emphasized over the last lectures. 119 00:05:43,540 --> 00:05:47,570 Where you are ensured that your data will not be lost 120 00:05:47,570 --> 00:05:50,200 just because a pod was destroyed 121 00:05:50,200 --> 00:05:53,270 or launched on a different note. 122 00:05:53,270 --> 00:05:55,490 Because with a persistent volume, 123 00:05:55,490 --> 00:05:59,210 you are only allowed to use volume types 124 00:05:59,210 --> 00:06:02,250 which do actually work independent 125 00:06:02,250 --> 00:06:05,130 from the node on which your pods live. 126 00:06:05,130 --> 00:06:06,820 So that's the difference. 127 00:06:06,820 --> 00:06:10,700 And therefore there is no better or worse volume type here. 128 00:06:10,700 --> 00:06:13,110 It really depends on your project. 129 00:06:13,110 --> 00:06:14,440 If you're on your own, 130 00:06:14,440 --> 00:06:17,210 working on your own small demo project, 131 00:06:17,210 --> 00:06:20,130 using persistent volumes, might be overkill. 132 00:06:20,130 --> 00:06:22,030 You can, of course still do it though, 133 00:06:22,030 --> 00:06:25,840 in bigger projects with a lot of pods and a lot of volumes, 134 00:06:25,840 --> 00:06:28,690 and maybe a lot of people working on the project 135 00:06:28,690 --> 00:06:30,420 using persistent volumes 136 00:06:30,420 --> 00:06:33,293 might make it easier to manage that project.