1
00:00:02,050 --> 00:00:04,510
Kind of related to that restarting,

2
00:00:04,510 --> 00:00:06,740
there's another useful command.

3
00:00:06,740 --> 00:00:09,810
Let's say we don't have auto scaling in place.

4
00:00:09,810 --> 00:00:11,930
So Kubectl will not automatically

5
00:00:11,930 --> 00:00:14,360
create more or less pods

6
00:00:14,360 --> 00:00:17,380
but we know that we'll have more traffic incoming.

7
00:00:17,380 --> 00:00:20,230
So we don't just want to have this pod and this container

8
00:00:20,230 --> 00:00:21,680
up and running once

9
00:00:21,680 --> 00:00:24,090
but let's say three times.

10
00:00:24,090 --> 00:00:27,860
We can achieve this by running kubectl scale.

11
00:00:27,860 --> 00:00:31,120
Then we need to specify what we wanna scale.

12
00:00:31,120 --> 00:00:34,400
And here we could say deployment/first-app.

13
00:00:34,400 --> 00:00:37,190
This is how we identified this deployment.

14
00:00:37,190 --> 00:00:41,033
And then we add the dash dash replica's option.

15
00:00:41,950 --> 00:00:44,170
To specify how many instances,

16
00:00:44,170 --> 00:00:46,040
how many pods we wanna have.

17
00:00:46,040 --> 00:00:48,153
For example, you could set this two free.

18
00:00:49,700 --> 00:00:51,660
And if we do that,

19
00:00:51,660 --> 00:00:54,340
we run cube control get pods,

20
00:00:54,340 --> 00:00:58,710
we see free pots for our first app deployment here,

21
00:00:58,710 --> 00:01:02,740
The pods which we had before and two new pods.

22
00:01:02,740 --> 00:01:04,680
Of course, we also see that here

23
00:01:04,680 --> 00:01:07,480
in our dashboard here in the browser,

24
00:01:07,480 --> 00:01:09,820
we see our new pods here as well,

25
00:01:09,820 --> 00:01:13,360
and they are running the same container as the other pod.

26
00:01:13,360 --> 00:01:15,710
Now because we have a load balancer,

27
00:01:15,710 --> 00:01:18,470
traffic will also be distributed evenly

28
00:01:18,470 --> 00:01:20,310
across these different pods

29
00:01:20,310 --> 00:01:22,470
and the containers running in there.

30
00:01:22,470 --> 00:01:23,820
To see this in action.

31
00:01:23,820 --> 00:01:27,570
Let me go back to our application and visit this page.

32
00:01:27,570 --> 00:01:31,190
And now let's visit slash error and have crashes.

33
00:01:31,190 --> 00:01:34,510
Let me go back to the other page and it works.

34
00:01:34,510 --> 00:01:36,550
Now it works even though this pod here

35
00:01:36,550 --> 00:01:38,960
is still terminated at the moment,

36
00:01:38,960 --> 00:01:40,750
it will eventually restart.

37
00:01:40,750 --> 00:01:43,900
But of course now to traffic was simply redirected

38
00:01:43,900 --> 00:01:45,710
to another pod.

39
00:01:45,710 --> 00:01:48,110
Now, if I crashed as again,

40
00:01:48,110 --> 00:01:50,193
we see another pod crashed,

41
00:01:52,580 --> 00:01:56,350
but again, we got one other pot up and running here.

42
00:01:56,350 --> 00:01:59,750
So you can tell that the traffic is definitely not just

43
00:01:59,750 --> 00:02:02,360
going to one and the same pot all the time,

44
00:02:02,360 --> 00:02:06,800
but that it is being distributed across our different pods.

45
00:02:06,800 --> 00:02:10,240
So scaling, even if it doesn't happen automatically,

46
00:02:10,240 --> 00:02:13,863
is another very useful feature we get with Kubernetes.

47
00:02:14,730 --> 00:02:18,390
Of course, we can also scale it down to one replica again,

48
00:02:18,390 --> 00:02:21,230
by repeating the kubectl controlled scale command

49
00:02:21,230 --> 00:02:23,480
and setting replica's to one.

50
00:02:23,480 --> 00:02:27,080
If we do that and we run Q control get pods thereafter,

51
00:02:27,080 --> 00:02:29,460
we see two pods are terminating

52
00:02:29,460 --> 00:02:32,550
and only one pod will stay up and running.

53
00:02:32,550 --> 00:02:35,330
And therefore eventually the other two pods here

54
00:02:35,330 --> 00:02:38,120
will be gone after some time.

55
00:02:38,120 --> 00:02:40,683
So scaling is a never useful feature.