1 00:00:02,310 --> 00:00:04,640 So we had a look at the Pod object. 2 00:00:04,640 --> 00:00:07,400 Now let's have a look at the Deployment object. 3 00:00:07,400 --> 00:00:10,760 Because it turns out that the Deployment object 4 00:00:10,760 --> 00:00:14,230 will be one of the key objects you work with 5 00:00:14,230 --> 00:00:16,740 when working with Kubernetes. 6 00:00:16,740 --> 00:00:18,630 Because you typically don't create 7 00:00:18,630 --> 00:00:20,560 the Pod objects on your own 8 00:00:20,560 --> 00:00:23,310 and manually move them to some worker node. 9 00:00:23,310 --> 00:00:26,100 But instead you create a Deployment object, 10 00:00:26,100 --> 00:00:30,070 which you then give instructions about the number of Pods 11 00:00:30,070 --> 00:00:34,380 and the containers it should create and manage for you. 12 00:00:34,380 --> 00:00:37,010 The Deployment object is able to control 13 00:00:37,010 --> 00:00:39,970 one or multiple Pods. 14 00:00:39,970 --> 00:00:44,080 So, you can also use it to create multiple Pods at once 15 00:00:44,080 --> 00:00:48,190 and the core philosophy behind this Deployment object, 16 00:00:48,190 --> 00:00:50,980 which under the hood is a controller object. 17 00:00:50,980 --> 00:00:51,813 But for us, 18 00:00:51,813 --> 00:00:54,460 it's enough to know that it's a Deployment object. 19 00:00:54,460 --> 00:00:55,990 The idea behind that, 20 00:00:55,990 --> 00:00:59,500 is that we set a desired target state. 21 00:00:59,500 --> 00:01:00,510 For example, 22 00:01:00,510 --> 00:01:04,599 that we have two Pods with this container up and running, 23 00:01:04,599 --> 00:01:07,820 and then Kubernetes will do everything it needs to do 24 00:01:07,820 --> 00:01:09,763 to reach this target state. 25 00:01:10,650 --> 00:01:13,160 So, we can define what we want 26 00:01:13,160 --> 00:01:16,510 and Kubernetes will get us there. 27 00:01:16,510 --> 00:01:18,830 And the advantage of this is, 28 00:01:18,830 --> 00:01:22,250 that the Pod objects are then created by Kubernetes 29 00:01:22,250 --> 00:01:25,410 and the pods are therefore created by Kubernetes. 30 00:01:25,410 --> 00:01:27,850 The containers are started by Kubernetes 31 00:01:27,850 --> 00:01:30,180 and Kubernetes will then, for example, 32 00:01:30,180 --> 00:01:34,360 also place these Pods on worker nodes, 33 00:01:34,360 --> 00:01:38,410 which have sufficient memory and CPU capacity 34 00:01:38,410 --> 00:01:40,480 for these new Pods. 35 00:01:40,480 --> 00:01:44,120 So, we don't manually have to pick a remote machine 36 00:01:44,120 --> 00:01:46,040 and place our Pod on there. 37 00:01:46,040 --> 00:01:48,313 Kubernetes will do this for us instead. 38 00:01:49,360 --> 00:01:52,570 Another advantage of using this Deployment object, 39 00:01:52,570 --> 00:01:55,550 is that we can also pause or delete Deployments 40 00:01:55,550 --> 00:01:57,720 and also roll them back. 41 00:01:57,720 --> 00:02:02,310 So, if we mess something up and our application fails, 42 00:02:02,310 --> 00:02:07,310 we don't have to rush to change our code and fix the error 43 00:02:07,600 --> 00:02:11,020 and replace the failing Pod with a new one. 44 00:02:11,020 --> 00:02:15,490 Instead, we can just roll back the failing Deployment 45 00:02:15,490 --> 00:02:18,910 and go back to the previous Deployment which worked. 46 00:02:18,910 --> 00:02:22,380 Then we can fix the bug without any need to hurry, 47 00:02:22,380 --> 00:02:25,210 and we can then simply start a new Deployment 48 00:02:25,210 --> 00:02:28,350 with the updated code in the updated container image 49 00:02:28,350 --> 00:02:29,430 once we're done. 50 00:02:29,430 --> 00:02:32,720 So, that's another very handy feature. 51 00:02:32,720 --> 00:02:34,430 Another handy feature, 52 00:02:34,430 --> 00:02:36,080 which is worth mentioning here, 53 00:02:36,080 --> 00:02:39,290 is that the Deployments can also be scaled. 54 00:02:39,290 --> 00:02:41,530 We can tell Kubernetes 55 00:02:41,530 --> 00:02:45,570 that we now want to have more Pods or less Pods, 56 00:02:45,570 --> 00:02:49,050 and we can also use a feature called autoscaling, 57 00:02:49,050 --> 00:02:51,660 where we can set certain metrics. 58 00:02:51,660 --> 00:02:55,930 For example, incoming traffic and CPU utilization. 59 00:02:55,930 --> 00:02:58,800 And when these metrics are exceeded, 60 00:02:58,800 --> 00:03:02,220 Kubernetes automatically creates more Pods 61 00:03:02,220 --> 00:03:05,370 and therefore more running container instances, 62 00:03:05,370 --> 00:03:08,050 which are there to handle the incoming requests. 63 00:03:08,050 --> 00:03:11,640 And once the traffic goes down and is less, 64 00:03:11,640 --> 00:03:15,280 these unnecessary Pods will be removed again. 65 00:03:15,280 --> 00:03:18,110 And these are all features we can get 66 00:03:18,110 --> 00:03:20,563 when using this Deployment object. 67 00:03:21,440 --> 00:03:23,770 Now, when we create Deployments, 68 00:03:23,770 --> 00:03:26,400 we manage one Pod with the Deployment, 69 00:03:26,400 --> 00:03:29,280 but we can of course create multiple Deployments 70 00:03:29,280 --> 00:03:33,150 to have multiple Pods being managed by Kubernetes. 71 00:03:33,150 --> 00:03:36,370 And therefore, we typically don't directly create Pods, 72 00:03:36,370 --> 00:03:38,350 we don't directly manage them. 73 00:03:38,350 --> 00:03:41,220 Instead, we let Kubernetes do that for us 74 00:03:41,220 --> 00:03:45,270 by using Deployments and by creating Deployment objects 75 00:03:45,270 --> 00:03:48,133 and sending that to the Kubernetes cluster. 76 00:03:49,030 --> 00:03:51,800 So, now that we know all of that, 77 00:03:51,800 --> 00:03:54,170 let's finally get our hands dirty 78 00:03:54,170 --> 00:03:55,270 and let's run some commands 79 00:03:55,270 --> 00:03:58,360 to finally create such a Deployment 80 00:03:58,360 --> 00:04:01,363 in our Minikube demo cluster.