1
00:00:02,160 --> 00:00:04,110
So persistent volumes

2
00:00:04,110 --> 00:00:07,900
can give us greater independence of the individual pods

3
00:00:07,900 --> 00:00:10,660
and nodes on which these pods are run.

4
00:00:10,660 --> 00:00:13,400
So let's now create a persistent volume

5
00:00:13,400 --> 00:00:15,700
and let's see how we can use that

6
00:00:15,700 --> 00:00:19,370
compared to volumes created as we did it before.

7
00:00:19,370 --> 00:00:21,550
And therefore, I'll create a new file

8
00:00:21,550 --> 00:00:25,000
and I'll name this host-pv.yaml

9
00:00:25,000 --> 00:00:28,740
because there I'll set up a persistent volume,

10
00:00:28,740 --> 00:00:32,810
that is what PV stands for, using the host path driver,

11
00:00:32,810 --> 00:00:34,670
the host path type.

12
00:00:34,670 --> 00:00:36,800
Which, just to make this clear again,

13
00:00:36,800 --> 00:00:40,240
will only work on a single node testing environment.

14
00:00:40,240 --> 00:00:42,430
But this is the environment we have right now

15
00:00:42,430 --> 00:00:45,800
and what I explain about this will always hold true.

16
00:00:45,800 --> 00:00:48,400
So what I teach you here with host path

17
00:00:48,400 --> 00:00:50,570
will then later all to be important

18
00:00:50,570 --> 00:00:52,960
if you would use a number type.

19
00:00:52,960 --> 00:00:55,450
Now, to define our persistent volume

20
00:00:55,450 --> 00:00:58,990
we, first of all, again, need to set the API version

21
00:00:58,990 --> 00:01:02,693
and I'll set it to v1, just as for a service.

22
00:01:03,720 --> 00:01:07,050
Then, just as for the deployment and the service,

23
00:01:07,050 --> 00:01:09,610
we of course need to make Kubernetes aware

24
00:01:09,610 --> 00:01:13,780
of the kind of resource we want to create with this file

25
00:01:13,780 --> 00:01:16,210
because it, of course, can't guess that

26
00:01:16,210 --> 00:01:18,180
and can't know that either

27
00:01:18,180 --> 00:01:21,180
without us adding more information.

28
00:01:21,180 --> 00:01:23,010
So I'll add a kind here.

29
00:01:23,010 --> 00:01:28,010
And here, the kind is PersistentVolume, written like this.

30
00:01:28,230 --> 00:01:31,100
And of course, just as with the other kinds,

31
00:01:31,100 --> 00:01:34,740
like deployment, make sure you type this correctly

32
00:01:34,740 --> 00:01:36,773
and you have no typo in here.

33
00:01:38,010 --> 00:01:39,780
Next we can add metadata

34
00:01:39,780 --> 00:01:42,140
and give this persistent volume a name,

35
00:01:42,140 --> 00:01:44,420
for example, host-pv.

36
00:01:44,420 --> 00:01:47,380
The name as always is up to you.

37
00:01:47,380 --> 00:01:51,430
And then also just as with the deployment and the service,

38
00:01:51,430 --> 00:01:52,970
we have our spec,

39
00:01:52,970 --> 00:01:56,480
our specification for this persistent volume.

40
00:01:56,480 --> 00:02:00,090
This is now where we're going to configure it.

41
00:02:00,090 --> 00:02:03,270
And here we need to configure a couple of things.

42
00:02:03,270 --> 00:02:06,840
For example, of course, which type of volume

43
00:02:06,840 --> 00:02:10,669
we want to define as a standalone entity here.

44
00:02:10,669 --> 00:02:13,090
And I will use host path,

45
00:02:13,090 --> 00:02:18,090
so we add host path here just as we did it here on volumes

46
00:02:18,310 --> 00:02:20,900
in the deployment yaml file.

47
00:02:20,900 --> 00:02:24,810
And indeed we can use the same sub-configuration

48
00:02:24,810 --> 00:02:26,320
as we did there.

49
00:02:26,320 --> 00:02:28,730
So we can add the same configuration,

50
00:02:28,730 --> 00:02:33,730
like the path and the type here, nested below host path.

51
00:02:34,660 --> 00:02:37,200
And this will now set up a host path,

52
00:02:37,200 --> 00:02:40,730
persistent volume as a standalone volume

53
00:02:40,730 --> 00:02:45,010
detached from any pod in this environment.

54
00:02:45,010 --> 00:02:47,090
Again, because it's host path,

55
00:02:47,090 --> 00:02:49,750
it will not be independent from the nodes

56
00:02:49,750 --> 00:02:52,580
and it only works if we have only one node.

57
00:02:52,580 --> 00:02:54,810
But the rest of the explanation

58
00:02:54,810 --> 00:02:58,090
will apply to other types as well.

59
00:02:58,090 --> 00:03:00,510
Because the type is not everything.

60
00:03:00,510 --> 00:03:05,210
With a persistent volume, unlike with a regular volume,

61
00:03:05,210 --> 00:03:10,210
we need to add more information here in this spec object.

62
00:03:10,840 --> 00:03:14,870
For example, we need to define a capacity.

63
00:03:14,870 --> 00:03:19,080
The capacity matters because as an administrator

64
00:03:19,080 --> 00:03:23,530
we might want to control how much capacity can be used

65
00:03:23,530 --> 00:03:25,070
by the different pods

66
00:03:25,070 --> 00:03:29,370
which are later executed in our cluster.

67
00:03:29,370 --> 00:03:32,370
And therefore we can set a capacity here.

68
00:03:32,370 --> 00:03:36,230
A capacity for this persistent volume and the pods,

69
00:03:36,230 --> 00:03:38,570
when they claim this volume later,

70
00:03:38,570 --> 00:03:42,750
can then define how much capacity they need.

71
00:03:42,750 --> 00:03:47,480
So here we specify the overall available capacity.

72
00:03:47,480 --> 00:03:52,010
And we can specify to storage capacity here, to be precise.

73
00:03:52,010 --> 00:03:55,560
And set this, for example, to four gigabytes

74
00:03:55,560 --> 00:03:56,673
by adding 4Gi here .

75
00:03:58,530 --> 00:04:02,310
Now, to know which values are suppoded here

76
00:04:02,310 --> 00:04:05,670
you can dive into the official persistent volume docs.

77
00:04:05,670 --> 00:04:07,840
And there, if you scroll down a bit,

78
00:04:07,840 --> 00:04:12,840
under Persistent Volumes, there is a capacity key or point.

79
00:04:13,010 --> 00:04:16,350
And then there, you can click on the Resource Model.

80
00:04:16,350 --> 00:04:17,990
And here in this document,

81
00:04:17,990 --> 00:04:22,730
you can learn more about how Kubernetes defines resources

82
00:04:22,730 --> 00:04:24,573
and which units it knows.

83
00:04:25,620 --> 00:04:28,910
So here, for example, you see this gigabyte notation.

84
00:04:28,910 --> 00:04:31,990
So this is a document you can look into to learn more

85
00:04:31,990 --> 00:04:36,900
about the available units and how to define resources.

86
00:04:36,900 --> 00:04:39,560
At the moment, we only have to storage resource

87
00:04:39,560 --> 00:04:40,670
and there of course,

88
00:04:40,670 --> 00:04:43,330
you will quite often work with gigabytes.

89
00:04:43,330 --> 00:04:47,850
So here I'm defining that up to four gigabytes of space

90
00:04:47,850 --> 00:04:52,850
can be claimed and used here for this host path volume.

91
00:04:53,110 --> 00:04:56,180
And of course you could define more if you need more.

92
00:04:56,180 --> 00:04:58,480
If you're using some third party service

93
00:04:58,480 --> 00:05:00,040
you of course need to ensure

94
00:05:00,040 --> 00:05:02,430
that you have enough away level space there

95
00:05:02,430 --> 00:05:04,580
so that you don't offer more here

96
00:05:04,580 --> 00:05:07,160
than is realistically available.

97
00:05:07,160 --> 00:05:09,740
So actually here I will shrink this to one gigabyte

98
00:05:09,740 --> 00:05:12,490
to be really sure that this is really available

99
00:05:12,490 --> 00:05:15,093
inside of this virtual minikube machine.

100
00:05:16,140 --> 00:05:19,080
Now, a next option you need to specify here

101
00:05:19,080 --> 00:05:24,080
is the volume mode, and there are two available modes here.

102
00:05:24,400 --> 00:05:28,560
There is file system and block.

103
00:05:28,560 --> 00:05:31,890
And these are different storage types.

104
00:05:31,890 --> 00:05:35,220
Not only defined by Kubernetes, but generally.

105
00:05:35,220 --> 00:05:37,540
When we talk about storage and development,

106
00:05:37,540 --> 00:05:39,180
we have block storage

107
00:05:39,180 --> 00:05:42,410
and we have file system storage, typically.

108
00:05:42,410 --> 00:05:45,000
I attached a resource where you can learn more

109
00:05:45,000 --> 00:05:48,250
about the differences between file system and block storage.

110
00:05:48,250 --> 00:05:50,960
Here, we have file system storage

111
00:05:50,960 --> 00:05:54,060
because we have a folder on the file system

112
00:05:54,060 --> 00:05:55,863
inside of our virtual machine.

113
00:05:57,430 --> 00:06:01,200
The next key we can define here for this persistent volume

114
00:06:01,200 --> 00:06:03,130
is how it may be accessed.

115
00:06:03,130 --> 00:06:06,930
And we set this by adding the access modes key here

116
00:06:06,930 --> 00:06:10,090
which then accepts multiple access modes.

117
00:06:10,090 --> 00:06:11,840
Hence we have a dash here

118
00:06:11,840 --> 00:06:15,830
and we can now list all the access modes we want to support.

119
00:06:15,830 --> 00:06:19,940
And there are three possible access modes we could add here.

120
00:06:19,940 --> 00:06:23,667
That's ReadWriteOnce.

121
00:06:23,667 --> 00:06:26,550
ReadOnlyMany.

122
00:06:26,550 --> 00:06:28,133
And ReadWriteMany.

123
00:06:30,520 --> 00:06:32,370
So what is the difference now?

124
00:06:32,370 --> 00:06:34,060
You can specify all,

125
00:06:34,060 --> 00:06:36,530
because it's only when you claim a volume

126
00:06:36,530 --> 00:06:37,830
that you then have to define

127
00:06:37,830 --> 00:06:41,510
how you want to claim this volume for a given pod.

128
00:06:41,510 --> 00:06:45,140
Here you justifying what should generally be allowed,

129
00:06:45,140 --> 00:06:46,963
so how this may be claimed.

130
00:06:47,810 --> 00:06:51,640
ReadWriteOnce means that this volume can be mounted

131
00:06:51,640 --> 00:06:55,210
as a read-write volume by a single node.

132
00:06:55,210 --> 00:06:56,770
So by multiple pods,

133
00:06:56,770 --> 00:06:59,620
but they all have to be on the same node.

134
00:06:59,620 --> 00:07:02,070
ReadOnlyMany means that it's read-only

135
00:07:02,070 --> 00:07:04,810
but it can be claimed by multiple nodes.

136
00:07:04,810 --> 00:07:07,230
So multiple pods on different nodes

137
00:07:07,230 --> 00:07:10,370
can claim this same persistent volume.

138
00:07:10,370 --> 00:07:12,920
And for example, for the host path type

139
00:07:12,920 --> 00:07:15,590
this is simply not in available option

140
00:07:15,590 --> 00:07:20,000
because host path by definition is defined on one node

141
00:07:20,000 --> 00:07:21,870
and they offer another node

142
00:07:21,870 --> 00:07:24,610
and another pod running on another node

143
00:07:24,610 --> 00:07:26,133
won't be able to claim it.

144
00:07:27,036 --> 00:07:29,830
ReadWriteMany is therefore also not available

145
00:07:29,830 --> 00:07:32,480
because that's the same like ReadOnlyMany,

146
00:07:32,480 --> 00:07:34,620
just with the difference that we're talking about

147
00:07:34,620 --> 00:07:36,790
read-write access.

148
00:07:36,790 --> 00:07:40,100
So here for this specific type of volume,

149
00:07:40,100 --> 00:07:44,040
the host path type, only ReadWriteOnce is available.

150
00:07:44,040 --> 00:07:46,490
Which means, when this value is claimed,

151
00:07:46,490 --> 00:07:48,930
it can be claimed by multiple pods

152
00:07:48,930 --> 00:07:51,260
and they will have read-write access,

153
00:07:51,260 --> 00:07:53,860
so the containers will have read-write access.

154
00:07:53,860 --> 00:07:57,750
But all the pods have to always run on the same node.

155
00:07:57,750 --> 00:08:01,293
Which, for this local dummy environment, will be guaranteed.

156
00:08:02,270 --> 00:08:04,640
So these are the available access modes

157
00:08:04,640 --> 00:08:07,120
which can be used for claiming this later.

158
00:08:07,120 --> 00:08:10,630
And here, I will only to find one available access mode

159
00:08:10,630 --> 00:08:13,883
because it's the only mode which makes sense for this type.

160
00:08:14,720 --> 00:08:17,970
In the official docs under Access Modes,

161
00:08:17,970 --> 00:08:20,780
you also find a matrix, a table,

162
00:08:20,780 --> 00:08:24,320
where you see which access modes are available

163
00:08:24,320 --> 00:08:26,030
for which type.

164
00:08:26,030 --> 00:08:29,030
Of course for the CSI type, which is highly flexible,

165
00:08:29,030 --> 00:08:32,082
it depends on the exact driver you are using.

166
00:08:33,179 --> 00:08:36,080
Now, that's it for the core keys I want to add

167
00:08:36,080 --> 00:08:37,260
at the moment.

168
00:08:37,260 --> 00:08:41,500
This defines that we have this standalone host path volume

169
00:08:41,500 --> 00:08:45,770
which now could be used by any pod in our application.

170
00:08:45,770 --> 00:08:49,200
So if we had multiple deployments and not just one,

171
00:08:49,200 --> 00:08:51,580
and therefore different types of pods,

172
00:08:51,580 --> 00:08:53,780
all these different types of pods

173
00:08:53,780 --> 00:08:56,703
could use that same persistent volume.

174
00:08:57,650 --> 00:08:59,450
But in order to use them

175
00:08:59,450 --> 00:09:02,533
they need to use a persistent volume claim.

