1
00:00:02,150 --> 00:00:04,290
So updating isn't too hard.

2
00:00:04,290 --> 00:00:07,420
Now let's try something which will fail.

3
00:00:07,420 --> 00:00:09,950
If I try this set image command again,

4
00:00:09,950 --> 00:00:13,660
but I use a tag, which doesn't exist, actually,

5
00:00:13,660 --> 00:00:17,890
it will still try to update this, but it will fail.

6
00:00:17,890 --> 00:00:19,800
And you can tell that it will fail

7
00:00:19,800 --> 00:00:21,460
by running another command,

8
00:00:21,460 --> 00:00:26,460
which allows you to inspect the progress of your rollouts.

9
00:00:26,720 --> 00:00:31,720
That's the kubectl rollout status deployment/

10
00:00:32,810 --> 00:00:35,113
your deployment name command.

11
00:00:36,540 --> 00:00:38,240
This actually tells you,

12
00:00:38,240 --> 00:00:40,650
what's currently going on for this deployment.

13
00:00:40,650 --> 00:00:42,140
And for example, here you see

14
00:00:42,140 --> 00:00:45,160
that we're waiting for a deployment to finish.

15
00:00:45,160 --> 00:00:47,970
And at the moment, the old replica,

16
00:00:47,970 --> 00:00:51,590
so the currently running port is shutting down,

17
00:00:51,590 --> 00:00:54,530
you could say, and please note that I can't execute more

18
00:00:54,530 --> 00:00:55,940
commands here at the moment.

19
00:00:55,940 --> 00:00:58,350
Because this rollout status command

20
00:00:58,350 --> 00:01:00,480
enters an interactive session,

21
00:01:00,480 --> 00:01:03,670
where we keep on listening to what's going on,

22
00:01:03,670 --> 00:01:06,343
you can always get out of that with Control + C.

23
00:01:07,380 --> 00:01:11,370
Now if we have a look at our dashboard here, under pods,

24
00:01:11,370 --> 00:01:14,460
we see that we're facing some problems.

25
00:01:14,460 --> 00:01:17,500
This old replica is not terminating,

26
00:01:17,500 --> 00:01:21,630
because the new pod is not starting up successfully.

27
00:01:21,630 --> 00:01:24,550
And it has issues with pulling the image,

28
00:01:24,550 --> 00:01:26,950
you see it fails to pull the image.

29
00:01:26,950 --> 00:01:28,570
So it's pretty good that

30
00:01:28,570 --> 00:01:32,240
because of that rolling update strategy Kubernetes uses,

31
00:01:32,240 --> 00:01:34,460
it doesn't shut down the old pod

32
00:01:34,460 --> 00:01:36,550
before the new pod is up and running.

33
00:01:36,550 --> 00:01:38,200
So that's good to have.

34
00:01:38,200 --> 00:01:39,410
But of course, here,

35
00:01:39,410 --> 00:01:41,560
our update will never finish therefore,

36
00:01:41,560 --> 00:01:44,060
because the new pod never starts.

37
00:01:44,060 --> 00:01:47,423
Because in this case, I had a typo in my image tag.

38
00:01:48,360 --> 00:01:49,890
So what does this mean?

39
00:01:49,890 --> 00:01:54,160
It means that we want to roll back this update,

40
00:01:54,160 --> 00:01:57,840
so that we don't want Kubernetes to continue with it.

41
00:01:57,840 --> 00:02:00,840
Now, first of all, let's quickly get our pods here

42
00:02:00,840 --> 00:02:04,290
to see the pod which is stuck,

43
00:02:04,290 --> 00:02:07,630
where it tried to pull an image which it doesn't find,

44
00:02:07,630 --> 00:02:10,800
so that it eventually stopped trying this.

45
00:02:10,800 --> 00:02:14,330
And let's now roll back this problematic deployment,

46
00:02:14,330 --> 00:02:16,660
which clearly won't complete here.

47
00:02:16,660 --> 00:02:18,260
To roll back, we can run

48
00:02:18,260 --> 00:02:23,260
kubectl rollout undo deployment/first-app.

49
00:02:26,630 --> 00:02:29,910
And this will undo the latest deployment.

50
00:02:29,910 --> 00:02:32,450
So if we now check our pods again,

51
00:02:32,450 --> 00:02:35,250
this problematic pod is gone.

52
00:02:35,250 --> 00:02:38,230
And if we have a look at our status,

53
00:02:38,230 --> 00:02:41,750
we see here we're back to successful.

54
00:02:41,750 --> 00:02:43,210
And our application, of course,

55
00:02:43,210 --> 00:02:44,803
still is up and running here.

56
00:02:45,900 --> 00:02:48,453
So this is how we can roll back a deployment.

57
00:02:49,380 --> 00:02:52,650
Now if you wanna go back to an even older deployment,

58
00:02:52,650 --> 00:02:55,730
so not just to the previous one, we can first of all

59
00:02:55,730 --> 00:02:58,150
have a look at the deployment history

60
00:02:58,150 --> 00:03:03,150
with kubectl rollout history for our deployment

61
00:03:03,480 --> 00:03:05,310
with the name first app.

62
00:03:05,310 --> 00:03:08,230
And we see the different deployments we made.

63
00:03:08,230 --> 00:03:11,630
We can also have details about a deployment,

64
00:03:11,630 --> 00:03:14,030
by adding --revision here.

65
00:03:14,030 --> 00:03:16,940
And then using one of these revision identifiers,

66
00:03:16,940 --> 00:03:19,070
let's say three.

67
00:03:19,070 --> 00:03:21,910
And we see which image was he was here,

68
00:03:21,910 --> 00:03:25,140
so that for example is the image which broke.

69
00:03:25,140 --> 00:03:27,050
And a couple of other things here.

70
00:03:27,050 --> 00:03:29,120
Not too useful to us here, though.

71
00:03:29,120 --> 00:03:32,350
But if I, for example, have a look at the revision one,

72
00:03:32,350 --> 00:03:35,480
we see that this is our original deployment,

73
00:03:35,480 --> 00:03:38,913
which use that latest tag on our image.

74
00:03:40,320 --> 00:03:41,900
Now let's say we wanted to go back

75
00:03:41,900 --> 00:03:44,180
to that original deployment.

76
00:03:44,180 --> 00:03:49,180
Instead of just running kubectl rollout undo like this,

77
00:03:49,380 --> 00:03:53,220
we can add the --to-revision option

78
00:03:53,220 --> 00:03:55,280
to specify a specific revision,

79
00:03:55,280 --> 00:03:58,143
we wanna go back to it, in this case, one.

80
00:03:59,270 --> 00:04:03,410
And if we do that, you will see the old code here

81
00:04:03,410 --> 00:04:06,810
because we're going back to that first deployment,

82
00:04:06,810 --> 00:04:09,590
which was based on the original image,

83
00:04:09,590 --> 00:04:11,940
and therefore on the original source code.

84
00:04:11,940 --> 00:04:14,733
So here, if I reload, I'm back to my old output.

85
00:04:15,690 --> 00:04:17,730
So is that we actually already

86
00:04:17,730 --> 00:04:21,019
took a little bit of a deeper dive into Kubernetes, I guess.

87
00:04:21,019 --> 00:04:23,470
But I find it quite interesting to see

88
00:04:23,470 --> 00:04:26,900
what you can do with Kubernetes and with deployments,

89
00:04:26,900 --> 00:04:28,979
and I find it super important

90
00:04:28,979 --> 00:04:32,350
that you see what Kubernetes does for you.

91
00:04:32,350 --> 00:04:34,610
And this pod management,

92
00:04:34,610 --> 00:04:37,240
automatic creation and removal

93
00:04:37,240 --> 00:04:39,400
and restarting pods and containers,

94
00:04:39,400 --> 00:04:42,560
and the rollback of deployments and so on.

95
00:04:42,560 --> 00:04:45,450
These are all super useful features,

96
00:04:45,450 --> 00:04:48,210
which of course can make your life way easier

97
00:04:48,210 --> 00:04:50,990
if you're deploying big applications

98
00:04:50,990 --> 00:04:53,840
to production ready clusters.

99
00:04:53,840 --> 00:04:55,810
With it however, we played around

100
00:04:55,810 --> 00:04:57,920
with these commands enough.

101
00:04:57,920 --> 00:05:01,030
Now I wanna switch from that imperative approach

102
00:05:01,030 --> 00:05:02,350
which we used this far

103
00:05:02,350 --> 00:05:06,870
by executing all these commands to a declarative approach,

104
00:05:06,870 --> 00:05:11,220
which will make working with Kubernetes, even more fun.

105
00:05:11,220 --> 00:05:13,250
Now to switch, let's first of all

106
00:05:13,250 --> 00:05:15,990
delete our service first-app

107
00:05:15,990 --> 00:05:19,460
by running kubectl delete service first-app.

108
00:05:19,460 --> 00:05:21,240
Let's delete the deployment

109
00:05:21,240 --> 00:05:24,350
by running kubectl delete deployment first-app,

110
00:05:24,350 --> 00:05:28,230
so that we ensure that all these resources are removed.

111
00:05:28,230 --> 00:05:29,680
Therefore, of course now,

112
00:05:29,680 --> 00:05:32,070
you can't visit the application anymore.

113
00:05:32,070 --> 00:05:36,330
And the deployment and pods will disappear here in the end.

114
00:05:36,330 --> 00:05:38,433
But with that, let's now move on.