1 00:00:02,050 --> 00:00:05,750 Now that we created our mini-cube setup, 2 00:00:05,750 --> 00:00:08,070 and we there for have this virtual machine 3 00:00:08,070 --> 00:00:11,230 with our Kubernetes cluster up and running, 4 00:00:11,230 --> 00:00:13,640 we can start interacting with that cluster, 5 00:00:13,640 --> 00:00:17,510 and we can start sending commands to that cluster 6 00:00:17,510 --> 00:00:20,440 to get Kubernetes to do something. 7 00:00:20,440 --> 00:00:22,850 And in order to start doing that, 8 00:00:22,850 --> 00:00:26,640 we need to understand how Kubernetes works internally. 9 00:00:26,640 --> 00:00:29,280 And with that, I don't directly mean 10 00:00:29,280 --> 00:00:31,790 how the architecture looks like 11 00:00:31,790 --> 00:00:34,750 and how such a Kubernetes cluster looks like, 12 00:00:34,750 --> 00:00:38,650 but which kind of commands, which kind of language 13 00:00:38,650 --> 00:00:42,230 Kubernetes understands, to then for example, 14 00:00:42,230 --> 00:00:45,483 create a new pod and start a new container. 15 00:00:46,350 --> 00:00:50,290 And here, it's important to understand and to keep in mind 16 00:00:50,290 --> 00:00:55,290 that Kubernetes works with so called objects. 17 00:00:55,740 --> 00:00:57,680 That's just how it's named. 18 00:00:57,680 --> 00:01:01,190 Kubernetes knows a couple of objects, for example, 19 00:01:01,190 --> 00:01:05,900 it knows pods, it knows deployments, services, volumes, 20 00:01:05,900 --> 00:01:07,580 and way more than that, 21 00:01:07,580 --> 00:01:11,230 and we're going to see the most important objects 22 00:01:11,230 --> 00:01:14,063 in action in this and the next modules. 23 00:01:14,950 --> 00:01:17,290 Now, the idea behind these objects, 24 00:01:17,290 --> 00:01:20,900 is simply that you can create such an object 25 00:01:20,900 --> 00:01:23,270 by executing a certain command. 26 00:01:23,270 --> 00:01:28,050 And then Kubernetes will take that object created by you, 27 00:01:28,050 --> 00:01:31,660 which of course is just a thing in code in the end, 28 00:01:31,660 --> 00:01:34,020 and it will then do something based 29 00:01:34,020 --> 00:01:38,740 on the instructions encoded in that object, you could say. 30 00:01:38,740 --> 00:01:42,220 And these objects can actually be created 31 00:01:42,220 --> 00:01:47,110 in two different ways, imperatively or declaratively. 32 00:01:47,110 --> 00:01:49,910 And we're going to see both ways in action, 33 00:01:49,910 --> 00:01:52,640 we're going to start with the imperative approach. 34 00:01:52,640 --> 00:01:54,970 But we'll also see what the difference is 35 00:01:54,970 --> 00:01:57,490 and which approach is preferable. 36 00:01:57,490 --> 00:02:00,860 So that's how Kubernetes basically works. 37 00:02:00,860 --> 00:02:03,250 It wants such objects, 38 00:02:03,250 --> 00:02:07,260 which then leads to Kubernetes doing something. 39 00:02:07,260 --> 00:02:09,889 And now when it comes to these objects, 40 00:02:09,889 --> 00:02:12,700 there are a couple of key objects, 41 00:02:12,700 --> 00:02:14,810 which we work with all the time, 42 00:02:14,810 --> 00:02:18,530 for example, the pod object. 43 00:02:18,530 --> 00:02:23,530 A pod in Kubernetes, is that smallest unit Kubernetes, 44 00:02:24,370 --> 00:02:26,520 knows and interacts with. 45 00:02:26,520 --> 00:02:31,520 And you do know that pod from the architecture slide 46 00:02:31,540 --> 00:02:33,490 I showed you earlier. 47 00:02:33,490 --> 00:02:37,960 Kubernetes creates pods and pods then hold containers, 48 00:02:37,960 --> 00:02:40,390 and Kubernetes manages these pods 49 00:02:40,390 --> 00:02:42,890 and therefore the containers for you. 50 00:02:42,890 --> 00:02:46,350 So indeed, the idea behind a pod is that it contains 51 00:02:46,350 --> 00:02:49,660 and runs one or multiple containers. 52 00:02:49,660 --> 00:02:54,110 Both is possible, you can have one container in a pod, 53 00:02:54,110 --> 00:02:55,960 or multiple containers. 54 00:02:55,960 --> 00:02:59,870 Though, typically you have one container per pod. 55 00:02:59,870 --> 00:03:03,330 That's the most common use case and scenario, 56 00:03:03,330 --> 00:03:05,810 but both would be possible. 57 00:03:05,810 --> 00:03:08,800 And if you wanna tell Kubernetes, 58 00:03:08,800 --> 00:03:10,820 that it should create a pod, 59 00:03:10,820 --> 00:03:14,460 run a container and do that on some worker node 60 00:03:14,460 --> 00:03:15,640 in the cluster. 61 00:03:15,640 --> 00:03:18,900 You would tell Kubernetes to do that, 62 00:03:18,900 --> 00:03:23,900 by creating a pod object in code or with help of a command, 63 00:03:23,910 --> 00:03:27,030 and sending that object to Kubernetes. 64 00:03:27,030 --> 00:03:29,620 That's how you can think about that. 65 00:03:29,620 --> 00:03:32,920 Now, pods are not just there to run one 66 00:03:32,920 --> 00:03:34,960 or multiple containers though, 67 00:03:34,960 --> 00:03:37,890 they can also hold shared resources 68 00:03:37,890 --> 00:03:40,130 which these containers might utilize, 69 00:03:40,130 --> 00:03:42,330 most importantly volumes. 70 00:03:42,330 --> 00:03:46,180 Though I will come back to volumes and Kubernetes later, 71 00:03:46,180 --> 00:03:48,070 because that is definitely something 72 00:03:48,070 --> 00:03:50,290 we can also dive in deeper. 73 00:03:50,290 --> 00:03:53,490 And also very important, pods of course, 74 00:03:53,490 --> 00:03:55,730 also are part of the cluster 75 00:03:55,730 --> 00:03:59,750 and therefore it can communicate with our pods 76 00:03:59,750 --> 00:04:01,660 or the outside world. 77 00:04:01,660 --> 00:04:06,660 But by default, a pod has a cluster internal IP address. 78 00:04:07,770 --> 00:04:11,720 Now that is something which we'll be able to change 79 00:04:11,720 --> 00:04:15,230 or we'll be able to communicate with pods nonetheless, 80 00:04:15,230 --> 00:04:17,029 even from outside the cluster. 81 00:04:17,029 --> 00:04:21,230 But by default, a pod has a cluster internal IP address, 82 00:04:21,230 --> 00:04:24,910 which can be used to send requests to that pod 83 00:04:24,910 --> 00:04:26,730 and there for to the containers 84 00:04:26,730 --> 00:04:29,330 running in the pod, for example. 85 00:04:29,330 --> 00:04:33,200 Now if you have multiple containers in one of the same pod, 86 00:04:33,200 --> 00:04:36,830 I can also tell you right away that these containers 87 00:04:36,830 --> 00:04:39,510 will be able to communicate with each other 88 00:04:39,510 --> 00:04:42,880 by using the local host address. 89 00:04:42,880 --> 00:04:47,880 And if you followed along with the AWS ECS lectures 90 00:04:47,950 --> 00:04:52,340 in the deployment section, before this section here, 91 00:04:52,340 --> 00:04:54,370 if you followed along there, 92 00:04:54,370 --> 00:04:58,260 you might remember that with AWS ECS, 93 00:04:58,260 --> 00:05:02,690 we also had that concept of tasks which held our containers. 94 00:05:02,690 --> 00:05:04,750 And if you had multiple containers, 95 00:05:04,750 --> 00:05:06,800 in one and the same task, 96 00:05:06,800 --> 00:05:10,400 these containers were also able to communicate 97 00:05:10,400 --> 00:05:12,827 with each other through localhost. 98 00:05:13,760 --> 00:05:17,060 And indeed, a task in AWS ECS 99 00:05:17,060 --> 00:05:21,310 is very similar to a pod in Kubernetes. 100 00:05:21,310 --> 00:05:24,380 This is not something you necessarily need to know, 101 00:05:24,380 --> 00:05:29,380 since Kubernetes is not related to AWS ECS at all. 102 00:05:29,800 --> 00:05:32,320 But it is something I wanna tell you here, 103 00:05:32,320 --> 00:05:35,800 because we covered AWS ECS in the course. 104 00:05:35,800 --> 00:05:39,540 So knowing that analogy is definitely something 105 00:05:39,540 --> 00:05:42,133 which is, well, worth mentioning I would say. 106 00:05:43,040 --> 00:05:46,740 Nonetheless, I will have a closer look at pod networking 107 00:05:46,740 --> 00:05:49,710 and pod volumes later in the course. 108 00:05:49,710 --> 00:05:52,100 For the moment, let's just focus on the fact 109 00:05:52,100 --> 00:05:54,140 that we have this pod object, 110 00:05:54,140 --> 00:05:58,810 and that we can basically tell Kubernetes to create a pod, 111 00:05:58,810 --> 00:06:03,240 run a container, and place that pod on some worker node 112 00:06:03,240 --> 00:06:06,840 in the cluster, by creating such a pod object, 113 00:06:06,840 --> 00:06:11,060 and sending it with a command to the Kubernetes cluster. 114 00:06:11,060 --> 00:06:13,730 But there are two important things to understand 115 00:06:13,730 --> 00:06:16,310 and keep in mind about pods. 116 00:06:16,310 --> 00:06:19,210 The first important thing to understand 117 00:06:19,210 --> 00:06:22,510 is that pods are ephemeral, 118 00:06:22,510 --> 00:06:25,560 which basically means they don't persist. 119 00:06:25,560 --> 00:06:30,090 If a pod is replaced or removed by Kubernetes, 120 00:06:30,090 --> 00:06:31,840 all the resources in the pod, 121 00:06:31,840 --> 00:06:36,173 for example, data stored and created by a container is lost. 122 00:06:37,180 --> 00:06:40,340 Now, just as with containers and volumes, 123 00:06:40,340 --> 00:06:42,790 there are ways of persisting data, 124 00:06:42,790 --> 00:06:44,610 but by default, it's lost. 125 00:06:44,610 --> 00:06:48,650 And that's not a bug, but it's a deliberate design decision. 126 00:06:48,650 --> 00:06:51,980 And this is important to understand and keep in mind. 127 00:06:51,980 --> 00:06:56,270 It's also very similar to the core idea behind containers, 128 00:06:56,270 --> 00:06:58,160 if you would think about it though. 129 00:06:58,160 --> 00:07:01,050 Containers also work like this. 130 00:07:01,050 --> 00:07:03,480 If we launch a container, 131 00:07:03,480 --> 00:07:06,080 we can run our application in there. 132 00:07:06,080 --> 00:07:08,470 And this application could for example, 133 00:07:08,470 --> 00:07:11,550 also create and store files. 134 00:07:11,550 --> 00:07:14,240 But if a container is then removed thereafter, 135 00:07:14,240 --> 00:07:18,050 and we rerun the container based on the same image, 136 00:07:18,050 --> 00:07:20,170 we still get a different container, 137 00:07:20,170 --> 00:07:22,890 and all the data which was in the previous container 138 00:07:22,890 --> 00:07:24,240 will be lost. 139 00:07:24,240 --> 00:07:26,460 And it's the same here for pods. 140 00:07:26,460 --> 00:07:27,590 Because after all, 141 00:07:27,590 --> 00:07:31,520 pods are just a tiny wrapper around containers. 142 00:07:31,520 --> 00:07:35,050 And they share many of the core concepts of containers, 143 00:07:35,050 --> 00:07:38,150 for example, the fact that they are ephemeral, 144 00:07:38,150 --> 00:07:41,120 and that therefore we lose all the state 145 00:07:41,120 --> 00:07:43,773 if they are removed or replaced. 146 00:07:44,840 --> 00:07:48,620 In addition, and that's also very important to understand, 147 00:07:48,620 --> 00:07:50,600 when working with Kubernetes, 148 00:07:50,600 --> 00:07:53,110 we can create pods on our own 149 00:07:53,110 --> 00:07:56,950 and start them on some worker node in our cluster, 150 00:07:56,950 --> 00:07:59,370 but that's typically not what we will do. 151 00:07:59,370 --> 00:08:03,300 Instead, we want Kubernetes to manage these pods for us, 152 00:08:03,300 --> 00:08:05,770 We want Kubernetes to automatically create 153 00:08:05,770 --> 00:08:07,950 and remove and replace them. 154 00:08:07,950 --> 00:08:12,110 For example, if the application running in a pod fails, 155 00:08:12,110 --> 00:08:15,110 we want Kubernetes to do all of that, 156 00:08:15,110 --> 00:08:18,670 because that is the core idea behind using Kubernetes. 157 00:08:18,670 --> 00:08:20,500 If we wouldn't use Kubernetes 158 00:08:20,500 --> 00:08:23,440 to manage the deployed application for us 159 00:08:23,440 --> 00:08:26,220 and to replace failing pods, 160 00:08:26,220 --> 00:08:29,220 then we could just manually run a container 161 00:08:29,220 --> 00:08:32,409 on some instance which we own, with just a Docker. 162 00:08:32,409 --> 00:08:34,669 We wouldn't need Kubernetes then. 163 00:08:34,669 --> 00:08:38,179 The entire idea behind using Kubernetes 164 00:08:38,179 --> 00:08:42,240 is that it also manages the deployment for us. 165 00:08:42,240 --> 00:08:46,350 And that's why we typically don't just create pod objects 166 00:08:46,350 --> 00:08:48,420 and send them to the cluster, 167 00:08:48,420 --> 00:08:51,560 but why we create controller objects, 168 00:08:51,560 --> 00:08:54,210 specifically the deployment object, 169 00:08:54,210 --> 00:08:58,220 which then actually will create pods for us. 170 00:08:58,220 --> 00:09:00,840 So therefore, let's next have a look at this 171 00:09:00,840 --> 00:09:04,463 deployment object, and let's understand how that works.