1
00:00:02,180 --> 00:00:04,530
So we got our application up and running

2
00:00:04,530 --> 00:00:06,490
on our cluster here.

3
00:00:06,490 --> 00:00:11,160
Now, let's move on, and let's dig into volumes.

4
00:00:11,160 --> 00:00:14,560
We covered volumes in an earlier module,

5
00:00:14,560 --> 00:00:19,400
and there I also talked about these types of volumes.

6
00:00:19,400 --> 00:00:23,770
And we use the emptyDir type and the hostPath type.

7
00:00:23,770 --> 00:00:26,850
And I mentioned that this CSI type

8
00:00:26,850 --> 00:00:29,540
would also become important later.

9
00:00:29,540 --> 00:00:31,893
Well now is later.

10
00:00:33,450 --> 00:00:36,810
Now the application we are working on at the moment,

11
00:00:36,810 --> 00:00:40,640
actually has no code that would really write a file

12
00:00:40,640 --> 00:00:42,120
to the hard drive.

13
00:00:42,120 --> 00:00:45,380
We're interacting with a real database instead.

14
00:00:45,380 --> 00:00:48,680
Nonetheless, we could assume that we have some code

15
00:00:48,680 --> 00:00:50,610
which does write to a file,

16
00:00:50,610 --> 00:00:53,300
even though it's not the case here.

17
00:00:53,300 --> 00:00:56,230
We could assume that we have some code,

18
00:00:56,230 --> 00:00:58,800
which actually writes to let's say,

19
00:00:58,800 --> 00:01:02,730
a user's folder in our main project folder.

20
00:01:02,730 --> 00:01:07,300
Maybe storing extra data about users and text files there.

21
00:01:07,300 --> 00:01:09,130
Again, it's just an assumption,

22
00:01:09,130 --> 00:01:11,800
it's not something our application does,

23
00:01:11,800 --> 00:01:14,520
but if we would have this behavior,

24
00:01:14,520 --> 00:01:16,670
if we would have a feature like this,

25
00:01:16,670 --> 00:01:21,260
then we might wanna use a volume to persist the data

26
00:01:21,260 --> 00:01:26,260
in that fictional users folder in our project folder.

27
00:01:26,460 --> 00:01:28,870
So what would we do normally?

28
00:01:28,870 --> 00:01:33,260
Well, in docker-compose world, there, we would add a volume.

29
00:01:33,260 --> 00:01:34,920
I'm not going to do this here,

30
00:01:34,920 --> 00:01:36,620
but you'll learn how to add volume

31
00:01:36,620 --> 00:01:40,650
stare over the course sections in this course.

32
00:01:40,650 --> 00:01:43,290
Here, I wanna focus on Kubernetes.

33
00:01:43,290 --> 00:01:47,100
And there we have two main ways of adding volume,

34
00:01:47,100 --> 00:01:51,170
we can directly add it here in our container setup

35
00:01:51,170 --> 00:01:53,450
in our pod template in the end,

36
00:01:53,450 --> 00:01:57,470
or we set up such a persistent volume resource

37
00:01:57,470 --> 00:02:00,950
and create a persistent volume claim.

38
00:02:00,950 --> 00:02:04,330
And here, I will go for this persistent volume approach,

39
00:02:04,330 --> 00:02:07,870
because it is probably the one you'll use more often

40
00:02:07,870 --> 00:02:12,800
in reality, and in addition, the specific type of volume

41
00:02:12,800 --> 00:02:15,480
I wanna set up here, at least at the moment

42
00:02:15,480 --> 00:02:18,720
only works with persistent volumes.

43
00:02:18,720 --> 00:02:22,320
But let's first of all come back to volumes in general.

44
00:02:22,320 --> 00:02:25,560
Now, in local development, emptyDir was useful

45
00:02:25,560 --> 00:02:27,700
because it's a new empty directory,

46
00:02:27,700 --> 00:02:29,590
but it's created for each pot,

47
00:02:29,590 --> 00:02:31,020
and therefore it's not great

48
00:02:31,020 --> 00:02:33,400
if we have multiple pods up and running.

49
00:02:33,400 --> 00:02:36,950
Or if our pod would restart, the data would also be lost,

50
00:02:36,950 --> 00:02:40,593
because it always is recreated as an empty directory.

51
00:02:42,200 --> 00:02:46,000
hostPath was very useful locally with mini-cube

52
00:02:46,000 --> 00:02:48,940
because that created a path on our node

53
00:02:48,940 --> 00:02:50,990
and use that as a volume.

54
00:02:50,990 --> 00:02:53,370
And since the node is not shut down

55
00:02:53,370 --> 00:02:55,410
just because a pod is removed,

56
00:02:55,410 --> 00:02:58,240
that also survived pod restarts

57
00:02:58,240 --> 00:03:02,373
and multiple pods were able to share one of the same volume.

58
00:03:03,290 --> 00:03:05,300
But this is not an option here,

59
00:03:05,300 --> 00:03:08,220
because actually here we got more than one node.

60
00:03:08,220 --> 00:03:10,000
In this case, I got two nodes.

61
00:03:10,000 --> 00:03:13,330
And in most clusters, most Kubernetes clusters,

62
00:03:13,330 --> 00:03:15,113
you will have more than one node.

63
00:03:15,990 --> 00:03:19,110
That means that a hostPath would only be created

64
00:03:19,110 --> 00:03:21,670
on one node but not the other.

65
00:03:21,670 --> 00:03:25,470
But you don't know where your pods will be created.

66
00:03:25,470 --> 00:03:29,180
Kubernetes automatically manages this pod creation

67
00:03:29,180 --> 00:03:31,490
and tries to create them on the node,

68
00:03:31,490 --> 00:03:34,870
which doesn't have too much work at the moment.

69
00:03:34,870 --> 00:03:38,150
So therefore, the node on which a pod is created

70
00:03:38,150 --> 00:03:39,870
might not have the hostPath

71
00:03:39,870 --> 00:03:41,570
to which you wanna bind your volume.

72
00:03:41,570 --> 00:03:42,960
And even if it would,

73
00:03:42,960 --> 00:03:45,700
multiple nodes would have different data

74
00:03:45,700 --> 00:03:47,340
on their hard drives.

75
00:03:47,340 --> 00:03:50,030
So hostPath is really only useful

76
00:03:50,030 --> 00:03:53,853
if you have a single node setup mostly during development.

77
00:03:55,090 --> 00:03:58,080
The CSI type is useful here though,

78
00:03:58,080 --> 00:04:01,540
because this stands for a Container Storage Interface.

79
00:04:01,540 --> 00:04:03,880
And as I explained earlier in the course,

80
00:04:03,880 --> 00:04:06,500
that's a very flexible volume type

81
00:04:06,500 --> 00:04:11,500
where third party developers can add their own integrations

82
00:04:11,550 --> 00:04:14,503
and their own volume types with ease.

83
00:04:15,460 --> 00:04:19,839
And here I wanna use AWSEFS de elastic file

84
00:04:19,839 --> 00:04:24,170
system service to manage my data.

85
00:04:24,170 --> 00:04:27,210
That's the same service we used earlier in the course

86
00:04:27,210 --> 00:04:30,923
already when we deployed our containers with ECS.

87
00:04:31,790 --> 00:04:36,757
And there exists such a CSI package for AWSEFS,

88
00:04:38,150 --> 00:04:40,930
and there also is an official documentation here,

89
00:04:40,930 --> 00:04:43,300
I'm just going to go to this GitHub page

90
00:04:43,300 --> 00:04:46,440
to learn more about this integration.

91
00:04:46,440 --> 00:04:50,200
And this is a very useful integration which is easy to add

92
00:04:50,200 --> 00:04:54,060
to our cluster and which then allows us to use EFS

93
00:04:54,060 --> 00:04:57,203
as a volume driver, as a volume type.