1
00:00:02,070 --> 00:00:04,370
Now the good news is that Kubernetes

2
00:00:04,370 --> 00:00:07,730
is able to Mount volumes into containers.

3
00:00:07,730 --> 00:00:12,050
We can add instructions to our pod templates,

4
00:00:12,050 --> 00:00:14,520
when we set up a deployment for example,

5
00:00:14,520 --> 00:00:17,930
that a volume should be mounted into the container

6
00:00:17,930 --> 00:00:20,333
which will be launched as part of the pod.

7
00:00:21,440 --> 00:00:26,290
And Kubernetes actually has a quiet powerful volume support,

8
00:00:26,290 --> 00:00:27,330
you could say.

9
00:00:27,330 --> 00:00:32,330
It supports a broad variety of volume types and drivers,

10
00:00:32,619 --> 00:00:35,330
and that's not something we necessarily know

11
00:00:35,330 --> 00:00:37,250
from just Docker.

12
00:00:37,250 --> 00:00:41,400
But since with Kubernetes we run our application

13
00:00:41,400 --> 00:00:43,770
possibly across multiple nodes,

14
00:00:43,770 --> 00:00:47,660
and possibly on different cloud and hosting providers.

15
00:00:47,660 --> 00:00:50,540
It supports different types of volumes

16
00:00:50,540 --> 00:00:53,470
which simply means it is quite flexible

17
00:00:53,470 --> 00:00:57,080
regarding where the data is actually stored.

18
00:00:57,080 --> 00:00:59,310
It supports local volumes.

19
00:00:59,310 --> 00:01:02,610
So simply a folder on the worker node,

20
00:01:02,610 --> 00:01:04,450
where the pod is running.

21
00:01:04,450 --> 00:01:07,900
But it also supports cloud provider specific volumes.

22
00:01:07,900 --> 00:01:09,130
And we're going to have a look

23
00:01:09,130 --> 00:01:12,160
at the different types supported by Kubernetes

24
00:01:12,160 --> 00:01:15,883
in greater detail throughout discourse section, of course.

25
00:01:17,090 --> 00:01:18,640
Now what's important to note

26
00:01:18,640 --> 00:01:21,260
and understand about Kubernetes though,

27
00:01:21,260 --> 00:01:25,050
is that the volume lifetime by default

28
00:01:25,050 --> 00:01:27,453
depends on the pod lifetime.

29
00:01:28,330 --> 00:01:30,990
Because you must not forget that the volumes

30
00:01:30,990 --> 00:01:33,990
are part of the pods, which are started

31
00:01:33,990 --> 00:01:36,440
and managed by Kubernetes.

32
00:01:36,440 --> 00:01:40,110
I mentioned this in the section where I introduced you

33
00:01:40,110 --> 00:01:43,700
to Kubernetes, and gave you a first overview.

34
00:01:43,700 --> 00:01:46,990
So volumes are pod specific

35
00:01:46,990 --> 00:01:49,110
and often that is totally fine,

36
00:01:49,110 --> 00:01:53,320
but of course, sometimes this can also cause problems.

37
00:01:53,320 --> 00:01:57,620
Though I will also present a solution for potential problems

38
00:01:57,620 --> 00:01:59,423
throughout this course section.

39
00:02:00,260 --> 00:02:03,490
However, before we dive into any potential problems

40
00:02:03,490 --> 00:02:07,455
and solutions, let's first understand the basics.

41
00:02:07,455 --> 00:02:10,270
So the volume lifetime, because the volume

42
00:02:10,270 --> 00:02:14,080
is part of the pod, depends on the pod lifetime.

43
00:02:14,080 --> 00:02:17,180
And therefore it survives container restarts

44
00:02:17,180 --> 00:02:21,240
and removals, because the container is inside of the pod

45
00:02:21,240 --> 00:02:23,380
and the volume is outside of the container,

46
00:02:23,380 --> 00:02:25,520
but also inside of the pod.

47
00:02:25,520 --> 00:02:27,790
But since the volume is inside of the pod,

48
00:02:27,790 --> 00:02:31,943
of course volumes are removed when pods are destroyed.

49
00:02:32,810 --> 00:02:35,830
So they survive container restarts and removals,

50
00:02:35,830 --> 00:02:38,190
which is great, which is what we need here.

51
00:02:38,190 --> 00:02:40,520
But if you would remove a pod

52
00:02:40,520 --> 00:02:43,420
then the volume would also be gone.

53
00:02:43,420 --> 00:02:47,410
And if you want a volume to survive the removal of a pod

54
00:02:47,410 --> 00:02:50,010
there also will be away for achieving that.

55
00:02:50,010 --> 00:02:52,700
But it's an advanced concept which we're going to explore

56
00:02:52,700 --> 00:02:53,900
at the next step.

57
00:02:53,900 --> 00:02:57,010
For the moment let's have a look at these pod internal

58
00:02:57,010 --> 00:02:58,983
and pod specific volumes.

59
00:03:00,050 --> 00:03:02,130
And therefore it is important to understand

60
00:03:02,130 --> 00:03:04,670
that Kubernetes has this volume support.

61
00:03:04,670 --> 00:03:08,560
But volumes managed by Kubernetes are not exactly the same

62
00:03:08,560 --> 00:03:10,930
as volumes managed by Docker,

63
00:03:10,930 --> 00:03:14,390
or to be precise, the idea is the same

64
00:03:14,390 --> 00:03:18,550
but Kubernetes volumes are a bit more powerful.

65
00:03:18,550 --> 00:03:20,450
With Kubernetes volumes,

66
00:03:20,450 --> 00:03:23,550
you have different drivers and types.

67
00:03:23,550 --> 00:03:28,170
Which gives you great control over where the data is stored.

68
00:03:28,170 --> 00:03:31,610
Now, when you work with just Docker and Docker compose,

69
00:03:31,610 --> 00:03:33,100
that's not the case,

70
00:03:33,100 --> 00:03:36,010
because that's also not something you really need.

71
00:03:36,010 --> 00:03:39,400
You run it locally on one machine anyways,

72
00:03:39,400 --> 00:03:42,040
and therefore it's clear that the data should be stored

73
00:03:42,040 --> 00:03:43,560
on that machine right?

74
00:03:43,560 --> 00:03:46,620
So when you use just Docker and Docker compose

75
00:03:46,620 --> 00:03:49,730
you don't necessarily need that much support

76
00:03:49,730 --> 00:03:51,883
for different storage systems.

77
00:03:52,770 --> 00:03:56,340
But with Kubernetes of course, running your application

78
00:03:56,340 --> 00:03:58,870
on a cluster with multiple nodes,

79
00:03:58,870 --> 00:04:01,070
on different hosting environments.

80
00:04:01,070 --> 00:04:05,490
On AWS, or your own data center or somewhere else,

81
00:04:05,490 --> 00:04:07,720
of course it needs to be flexible

82
00:04:07,720 --> 00:04:10,350
regarding how data should be stored.

83
00:04:10,350 --> 00:04:12,950
Which service by some cloud provider

84
00:04:12,950 --> 00:04:14,570
should be used for example,

85
00:04:14,570 --> 00:04:16,860
or if it should be stored on the hard drive

86
00:04:16,860 --> 00:04:18,940
on a specific machine.

87
00:04:18,940 --> 00:04:23,330
And that is some flexibility Kubernetes gives you.

88
00:04:23,330 --> 00:04:25,620
In addition, as I mentioned before,

89
00:04:25,620 --> 00:04:28,900
the volumes are not necessarily persistent.

90
00:04:28,900 --> 00:04:33,500
They do survive container restarts but not pod restarts,

91
00:04:33,500 --> 00:04:35,850
at least not by default.

92
00:04:35,850 --> 00:04:38,090
And of course, for just Docker,

93
00:04:38,090 --> 00:04:40,590
since you don't have the concept of pods

94
00:04:40,590 --> 00:04:43,660
and different machines and nodes.

95
00:04:43,660 --> 00:04:47,710
Data is always persistent until manually cleared,

96
00:04:47,710 --> 00:04:50,130
because you run Docker on one machine,

97
00:04:50,130 --> 00:04:53,060
for example, on your local development machine.

98
00:04:53,060 --> 00:04:56,910
And well, the data would be erased there as well,

99
00:04:56,910 --> 00:04:59,880
If you totally destroyed that machine

100
00:04:59,880 --> 00:05:03,520
or if you re-installed the operating system on your machine

101
00:05:03,520 --> 00:05:05,170
and you reset your machine.

102
00:05:05,170 --> 00:05:07,230
Then the data would be lost of course,

103
00:05:07,230 --> 00:05:10,040
but that's not something you typically do.

104
00:05:10,040 --> 00:05:12,050
That is the comparison we should make,

105
00:05:12,050 --> 00:05:15,000
however, when we compare it to Kubernetes.

106
00:05:15,000 --> 00:05:18,740
There we work on a cluster with different nodes and pods,

107
00:05:18,740 --> 00:05:22,410
and of course, if a pod is removed on some node,

108
00:05:22,410 --> 00:05:24,380
that is kind of equivalent

109
00:05:24,380 --> 00:05:27,350
to you resetting your local laptop.

110
00:05:27,350 --> 00:05:30,120
So of course, volumes are then lost.

111
00:05:30,120 --> 00:05:33,090
If just a container stopped and restarted

112
00:05:33,090 --> 00:05:35,000
and was removed in between,

113
00:05:35,000 --> 00:05:38,340
then in both cases, volumes will persist.

114
00:05:38,340 --> 00:05:41,203
Because that is the core idea behind volumes.

115
00:05:42,040 --> 00:05:44,600
So in the end, Kubernetes leverages

116
00:05:44,600 --> 00:05:48,710
the Docker volume system, but adds more power

117
00:05:48,710 --> 00:05:51,080
and more configuration options to it,

118
00:05:51,080 --> 00:05:54,573
because it needs these extra configuration options.

119
00:05:55,450 --> 00:05:57,890
And with all that theory out of the way,

120
00:05:57,890 --> 00:05:59,500
let's simply get started

121
00:05:59,500 --> 00:06:02,893
and let's see how we can utilize Kubernetes volumes.