1
00:00:02,140 --> 00:00:03,810
Now, before we dive into

2
00:00:03,810 --> 00:00:07,460
the declarative approach into volumes and networking,

3
00:00:07,460 --> 00:00:10,870
and dive deeper into Kubernetes in general,

4
00:00:10,870 --> 00:00:14,230
let's play around with the deployment we have here.

5
00:00:14,230 --> 00:00:17,110
And, for example, remember that we have this

6
00:00:17,110 --> 00:00:20,830
get error route here, on this application,

7
00:00:20,830 --> 00:00:23,560
which will actually crash the node app,

8
00:00:23,560 --> 00:00:26,650
and therefore, also the container running the app.

9
00:00:26,650 --> 00:00:30,090
Because this is a Node.js specific command,

10
00:00:30,090 --> 00:00:33,140
which will immediately stop the node server,

11
00:00:33,140 --> 00:00:37,890
and since our container started this node server,

12
00:00:37,890 --> 00:00:41,030
it will crash as well, if that command fails,

13
00:00:41,030 --> 00:00:43,143
which it does when we exit.

14
00:00:44,150 --> 00:00:49,150
So let's now visit slash error here,

15
00:00:50,230 --> 00:00:51,710
and you see it crashes.

16
00:00:51,710 --> 00:00:54,180
And now if you try the original route again,

17
00:00:54,180 --> 00:00:58,250
without slash error, this still works.

18
00:00:58,250 --> 00:01:01,810
Now, if you run Q+Ctrl get pods,

19
00:01:01,810 --> 00:01:04,730
you see the status is running,

20
00:01:04,730 --> 00:01:07,063
but because it was restarted once.

21
00:01:08,210 --> 00:01:11,240
Now if we crashed this again,

22
00:01:11,240 --> 00:01:14,050
by again going to the error route,

23
00:01:14,050 --> 00:01:16,130
you see the status as error,

24
00:01:16,130 --> 00:01:18,020
but if we wait for a while,

25
00:01:18,020 --> 00:01:20,920
it will restart this again.

26
00:01:20,920 --> 00:01:23,240
Now the time after which it restarts,

27
00:01:23,240 --> 00:01:24,920
gets longer and longer,

28
00:01:24,920 --> 00:01:27,100
to prevent infinite loops,

29
00:01:27,100 --> 00:01:28,960
where maybe you have a container,

30
00:01:28,960 --> 00:01:30,970
which simply fails all the time,

31
00:01:30,970 --> 00:01:32,980
to prevent such infinite loops,

32
00:01:32,980 --> 00:01:36,880
Kubernetes waits longer and longer with restarting,

33
00:01:36,880 --> 00:01:39,700
but eventually you'll see it's now back to running,

34
00:01:39,700 --> 00:01:42,340
and it restarted it twice.

35
00:01:42,340 --> 00:01:45,040
And that's a behavior we get

36
00:01:45,040 --> 00:01:47,550
because we created a deployment here.

37
00:01:47,550 --> 00:01:51,410
Because of that, this pod and the container in the pod,

38
00:01:51,410 --> 00:01:55,960
is being monitored, and if it fails, it's restarted.

39
00:01:55,960 --> 00:01:58,870
We can also see this here in the dashboard.

40
00:01:58,870 --> 00:02:00,370
If we have a look at our pods

41
00:02:00,370 --> 00:02:04,370
we see that this pod was indeed restarted twice now.

42
00:02:04,370 --> 00:02:07,380
So it was not recreated and not replaced,

43
00:02:07,380 --> 00:02:09,560
but it was simply restarted,

44
00:02:09,560 --> 00:02:12,870
and the container in there was restarted.

45
00:02:12,870 --> 00:02:16,250
You can also see that here in this events log.

46
00:02:16,250 --> 00:02:19,590
And you can see that it created different containers,

47
00:02:19,590 --> 00:02:22,580
every time this pod was restarted.

48
00:02:22,580 --> 00:02:25,210
So this container was recreated

49
00:02:25,210 --> 00:02:27,040
when the pod failed or when

50
00:02:27,040 --> 00:02:29,030
the application, the container failed,

51
00:02:29,030 --> 00:02:31,230
and the pod therefore decided that

52
00:02:31,230 --> 00:02:33,180
it needed to restart the container.

53
00:02:33,180 --> 00:02:36,093
So that's a very useful behavior we get here.