1 00:00:02,130 --> 00:00:05,570 If you visit kubernedes.io, 2 00:00:05,570 --> 00:00:08,270 you can get started learning more about Kubernetes, 3 00:00:08,270 --> 00:00:10,340 though of course you don't need to go 4 00:00:10,340 --> 00:00:11,748 through their documentation. 5 00:00:11,748 --> 00:00:14,930 Since I'm going to teach you all the fundamentals of 6 00:00:14,930 --> 00:00:18,150 Kubernetes in this and the next sections. 7 00:00:18,150 --> 00:00:21,210 But on this official page, you learn that Kubernetes, 8 00:00:21,210 --> 00:00:25,540 is an open source system, for automating deployment, 9 00:00:25,540 --> 00:00:30,540 scaling, and management of containerized applications. 10 00:00:30,820 --> 00:00:34,030 So it's not a single software, it's a system. 11 00:00:34,030 --> 00:00:37,050 And it's a collection of things, of tools, 12 00:00:37,050 --> 00:00:39,320 and of ways of doing something, 13 00:00:39,320 --> 00:00:42,570 which will help you with container deployment. 14 00:00:42,570 --> 00:00:45,520 But whilst this is a nice sentence to read, 15 00:00:45,520 --> 00:00:47,400 it still doesn't fully tell us, 16 00:00:47,400 --> 00:00:50,490 what exactly Kubernetes is, how we use it, 17 00:00:50,490 --> 00:00:52,820 and why we might wanna use it. 18 00:00:52,820 --> 00:00:54,850 So let's take a step back. 19 00:00:54,850 --> 00:00:57,780 When we think about deploying containers. 20 00:00:57,780 --> 00:00:59,530 And it's really just about that. 21 00:00:59,530 --> 00:01:02,550 It's not about using containers and Docker, 22 00:01:02,550 --> 00:01:05,520 locally on our machine for development, 23 00:01:05,520 --> 00:01:06,800 which we can also do, 24 00:01:06,800 --> 00:01:08,680 but it's just about deployment. 25 00:01:08,680 --> 00:01:12,880 When we think about that, we might have a problem. 26 00:01:12,880 --> 00:01:14,530 And for that specifically, 27 00:01:14,530 --> 00:01:18,090 let's think about manually, deploying containers, 28 00:01:18,090 --> 00:01:21,640 by manually managing servers for them. 29 00:01:21,640 --> 00:01:23,710 So with that, I'm talking about, 30 00:01:23,710 --> 00:01:27,644 for example, creating our own EC2 instances, 31 00:01:27,644 --> 00:01:31,387 which are these virtual machines we could create with AWS, 32 00:01:32,280 --> 00:01:35,240 on which we then were able to install Docker, 33 00:01:35,240 --> 00:01:37,430 to then run our containers on them. 34 00:01:37,430 --> 00:01:40,240 That is something we did initially, 35 00:01:40,240 --> 00:01:43,660 in the deployment section of this course. 36 00:01:43,660 --> 00:01:48,020 Now, when we do that, we will face a couple of challenges. 37 00:01:48,020 --> 00:01:50,860 And I'm not just talking about the security and 38 00:01:50,860 --> 00:01:52,570 configuration concerns, 39 00:01:52,570 --> 00:01:55,750 I already mentioned in the deployment section. 40 00:01:55,750 --> 00:01:58,630 These are all the serious concerns, 41 00:01:58,630 --> 00:02:02,510 that we have to manage and configure our EC2 instances 42 00:02:02,510 --> 00:02:05,010 on our own that we have to ensure, 43 00:02:05,010 --> 00:02:07,730 that the software and the operating system on 44 00:02:07,730 --> 00:02:09,230 there stays updated. 45 00:02:09,230 --> 00:02:11,330 These are definitely challenges, 46 00:02:11,330 --> 00:02:14,640 but I'm not even talking about these challenges here. 47 00:02:14,640 --> 00:02:17,090 Instead, if we install Docker there, 48 00:02:17,090 --> 00:02:21,360 and we manually run our containers, on these EC2 instances, 49 00:02:21,360 --> 00:02:24,380 even if we wouldn't have any security problems, 50 00:02:24,380 --> 00:02:26,920 we still might face other problems, 51 00:02:26,920 --> 00:02:31,070 which I didn't focus on too much, up to this point. 52 00:02:31,070 --> 00:02:35,920 For example, containers, might crash or go down, 53 00:02:35,920 --> 00:02:39,560 and might need to be replaced with a new container. 54 00:02:39,560 --> 00:02:41,600 This is something which can happen. 55 00:02:41,600 --> 00:02:43,610 Something might go wrong, 56 00:02:43,610 --> 00:02:46,300 inside of your containerized application. 57 00:02:46,300 --> 00:02:48,050 Something might fail there, 58 00:02:48,050 --> 00:02:49,950 and therefore the entire container, 59 00:02:49,950 --> 00:02:53,300 in the end crashes and becomes unusable. 60 00:02:53,300 --> 00:02:55,580 If something like this happens, 61 00:02:55,580 --> 00:02:58,940 you want to replace it with a new container, 62 00:02:58,940 --> 00:03:01,020 running your application again, 63 00:03:01,020 --> 00:03:02,080 because otherwise, 64 00:03:02,080 --> 00:03:04,810 your application might not be reachable anymore, 65 00:03:04,810 --> 00:03:06,953 if it crashed and isn't replaced. 66 00:03:07,800 --> 00:03:10,020 Now, when manually deploying, 67 00:03:10,020 --> 00:03:13,810 when manually running containers on an EC2 instance, 68 00:03:13,810 --> 00:03:16,660 we also have to manually monitor, 69 00:03:16,660 --> 00:03:18,210 whenever something crashed, 70 00:03:18,210 --> 00:03:22,270 and we have to manually restart containers thereafter. 71 00:03:22,270 --> 00:03:25,070 And, it should be needless to say that, 72 00:03:25,070 --> 00:03:27,420 that is of course not really something 73 00:03:27,420 --> 00:03:31,350 we wanna do for a serious or bigger applications, 74 00:03:31,350 --> 00:03:34,320 because when we're asleep, we can't monitor. 75 00:03:34,320 --> 00:03:35,740 And even if we're not asleep, 76 00:03:35,740 --> 00:03:39,080 we can't sit the entire day watching our logs, 77 00:03:39,080 --> 00:03:41,090 and seeing if something goes wrong, 78 00:03:41,090 --> 00:03:44,290 just to then restart a container. 79 00:03:44,290 --> 00:03:47,350 So that is clearly a problem we might be facing, 80 00:03:47,350 --> 00:03:51,670 in more realistic and bigger applications. 81 00:03:51,670 --> 00:03:55,080 Now, in addition, even if we wouldn't have that problem, 82 00:03:55,080 --> 00:03:58,210 we might need more container instances, 83 00:03:58,210 --> 00:04:02,310 upon traffic spikes, because if traffic increases, 84 00:04:02,310 --> 00:04:04,909 if we got more workload coming in, 85 00:04:04,909 --> 00:04:07,440 our containers might be still stuck, 86 00:04:07,440 --> 00:04:09,660 finishing the first task, 87 00:04:09,660 --> 00:04:11,930 before they can handle the next task. 88 00:04:11,930 --> 00:04:14,693 The next incoming request, for example. 89 00:04:15,550 --> 00:04:18,430 That's why we might want to scale up the number 90 00:04:18,430 --> 00:04:22,690 of containers, to then decrease and evenly distribute 91 00:04:22,690 --> 00:04:26,620 the incoming traffic across the different containers. 92 00:04:26,620 --> 00:04:29,710 And of course, if we then got less traffic incoming, 93 00:04:29,710 --> 00:04:33,110 we might want to remove a container again. 94 00:04:33,110 --> 00:04:36,550 And that is something we totally haven't talked about at all 95 00:04:36,550 --> 00:04:38,010 up to this point. 96 00:04:38,010 --> 00:04:41,780 Up to this point, we only executed every container once, 97 00:04:41,780 --> 00:04:45,341 no matter, if we consider the EC2 example, 98 00:04:45,341 --> 00:04:48,290 or if we think about ECS, 99 00:04:48,290 --> 00:04:51,680 which we also used in the deployment section, 100 00:04:51,680 --> 00:04:54,980 we always just had one running instance of a container. 101 00:04:54,980 --> 00:04:58,630 And in reality, that might not be enough. 102 00:04:58,630 --> 00:05:00,000 Also keep in mind, 103 00:05:00,000 --> 00:05:03,440 that you cannot just use containers for web development. 104 00:05:03,440 --> 00:05:07,540 If you got a container which runs an application, or a task, 105 00:05:07,540 --> 00:05:11,260 where you maybe transform image files, 106 00:05:11,260 --> 00:05:15,780 then this might not be depending on incoming HTTP requests, 107 00:05:15,780 --> 00:05:19,010 but you might simply be going through image files, 108 00:05:19,010 --> 00:05:21,930 which are uploaded to some folder. 109 00:05:21,930 --> 00:05:24,560 And if more and more files are coming in, 110 00:05:24,560 --> 00:05:27,710 your container might take longer and longer to finish 111 00:05:27,710 --> 00:05:29,760 transforming all these files. 112 00:05:29,760 --> 00:05:31,650 Spinning up multiple containers, 113 00:05:31,650 --> 00:05:34,480 which run the same task on different files, 114 00:05:34,480 --> 00:05:36,860 might then be a solution. 115 00:05:36,860 --> 00:05:40,080 So you might need to scale the number of running container 116 00:05:40,080 --> 00:05:42,420 instances up and down, 117 00:05:42,420 --> 00:05:46,923 as your workload or your traffic increases and decreases. 118 00:05:48,360 --> 00:05:51,490 Besides that, when we talk about traffic, 119 00:05:51,490 --> 00:05:54,450 HTTP traffic coming in for example, 120 00:05:54,450 --> 00:05:57,323 then we also might wanna ensure that it's evenly 121 00:05:57,323 --> 00:06:01,710 distributed across the running container instances. 122 00:06:01,710 --> 00:06:03,960 If we got only one container instance, 123 00:06:03,960 --> 00:06:06,160 of course there is nothing to distribute, 124 00:06:06,160 --> 00:06:08,060 but if we've got multiple instances, 125 00:06:08,060 --> 00:06:10,710 so multiple versions of the same app running. 126 00:06:10,710 --> 00:06:13,320 So the same container running multiple times, 127 00:06:13,320 --> 00:06:16,520 then we might wanna split the incoming traffic evenly, 128 00:06:16,520 --> 00:06:19,820 to ensure that not one container is doing all the work, 129 00:06:19,820 --> 00:06:22,683 while the other container instances are doing nothing. 130 00:06:23,570 --> 00:06:27,260 And I am aware that this concept of having multiple running 131 00:06:27,260 --> 00:06:29,030 container instances. 132 00:06:29,030 --> 00:06:31,568 So the same container running multiple times, 133 00:06:31,568 --> 00:06:33,880 is relatively new. 134 00:06:33,880 --> 00:06:37,180 Of course I did mention earlier in the course already, 135 00:06:37,180 --> 00:06:40,330 that you can run Docker run, on the same image, 136 00:06:40,330 --> 00:06:41,990 as often as you want. 137 00:06:41,990 --> 00:06:44,940 You can run as many containers as you want, 138 00:06:44,940 --> 00:06:47,170 based on one at the same image. 139 00:06:47,170 --> 00:06:49,120 But for our local development, 140 00:06:49,120 --> 00:06:52,060 and also in the deployment section up to this point, 141 00:06:52,060 --> 00:06:54,130 we, of course, didn't really use that. 142 00:06:54,130 --> 00:06:57,070 We always just executed every image, once. 143 00:06:57,070 --> 00:07:00,330 So we created one container per image. 144 00:07:00,330 --> 00:07:03,560 But in reality, for real web apps, 145 00:07:03,560 --> 00:07:06,820 or for whatever costs you are containerizing, 146 00:07:06,820 --> 00:07:09,300 you might need multiple container instances, 147 00:07:09,300 --> 00:07:11,110 which are based on the same image, 148 00:07:11,110 --> 00:07:13,130 so that the work can be split, 149 00:07:13,130 --> 00:07:16,850 and you ensure that for higher amounts of incoming traffic, 150 00:07:16,850 --> 00:07:20,440 for example, you got enough containers available, 151 00:07:20,440 --> 00:07:23,290 to handle all these incoming workloads. 152 00:07:23,290 --> 00:07:26,820 And we'll see this scaling concepts in greater detail, 153 00:07:26,820 --> 00:07:29,600 throughout this and the next modules. 154 00:07:29,600 --> 00:07:33,160 But these are the problems we might be facing, 155 00:07:33,160 --> 00:07:34,820 when deploying containers. 156 00:07:34,820 --> 00:07:36,900 And these are definitely big problems, 157 00:07:36,900 --> 00:07:39,363 if we manually deploy containers.