WEBVTT 0 00:05.000 --> 00:06.790 Hello and welcome to this lecture. 1 00:06.800 --> 00:09.550 My name is Mumshad Mannambeth and we are learning. 2 00:09.580 --> 00:12.440 Kubernetes for beginners. In this lecture, 3 00:12.470 --> 00:17.760 we will discuss about Kubernetes deployments. For a minute, 4 00:17.800 --> 00:24.700 let us forget about pods and replica sets and other Kubernetes concepts and talk about how 5 00:24.700 --> 00:28.760 you might want to deploy your application in a production environment. 6 00:29.080 --> 00:35.140 Say for example you have a web server that needs to be deployed in a production environment. 7 00:35.230 --> 00:39.700 You need not one but many such instances of the web server running. 8 00:39.700 --> 00:41.820 For obvious reasons. 9 00:41.830 --> 00:48.730 Secondly, whenever newer versions of application builds become available on the docker registry, you 10 00:48.730 --> 00:52.540 would like to upgrade your docker instances seamlessly. 11 00:52.690 --> 01:00.030 However, when you upgrade your instances you do not want to upgrade all of them at once as we just did. 12 01:00.070 --> 01:06.250 This may impact users accessing your applications so you might want to upgrade them one after the other 13 01:06.800 --> 01:10.870 and that kind of upgrade is known as rolling updates. 14 01:10.870 --> 01:17.140 Suppose one of the upgrades you performed resulted in an unexpected error and you're asked to undo the 15 01:17.140 --> 01:23.290 recent change, you would like to be able to roll back the changes that were recently carried out. 16 01:24.020 --> 01:30.380 Finally say for example you would like to make multiple changes to your environment such as upgrading 17 01:30.380 --> 01:36.110 the underlying Web Server versions as well as scaling your environment and also modifying the resource 18 01:36.110 --> 01:38.040 allocations etc. 19 01:38.060 --> 01:44.600 You do not want to apply each change immediately after the command is run, instead you like to apply 20 01:44.600 --> 01:46.260 a pause to your environment. 21 01:46.310 --> 01:52.040 make the changes and then resumes so that all the changes are rolled out together. 22 01:52.040 --> 01:58.010 All of these capabilities are available with the Kubernetes deployments. So far in this course. 23 01:58.010 --> 02:05.010 We discussed about pods which deploy single instances of our application such as the web application. 24 02:05.030 --> 02:09.380 in this case. Each container is encapsulated in pods. 25 02:09.800 --> 02:17.390 Multiple such pods are deployed using replication controllers or replica sets and then comes deployment 26 02:17.450 --> 02:24.320 which is a Kubernetes object that comes higher in the hierarchy, the deployment provides us with the 27 02:24.320 --> 02:30.480 capability to upgrade the underlying instances seamlessly using rolling updates. 28 02:30.470 --> 02:34.530 Undo changes and pause and resume changes as required. 29 02:35.550 --> 02:37.910 So how do we create a deployment. 30 02:38.160 --> 02:44.490 As with the previous components we first create the deployment definition file, the contents of the deployment 31 02:44.490 --> 02:50.930 definition file are exactly similar to the replica set definition file, except for the kind which 32 02:50.940 --> 02:53.370 is now going to be deployment. 33 02:53.610 --> 03:00.710 If we walk through the contents of the file it has an API version which is apps/v1, metadata 34 03:00.750 --> 03:06.570 which has a name and labels and a spec that has a template, replicas and selector. 35 03:06.570 --> 03:14.120 The template has a pod definition inside it once the file is ready run the kubectl create command 36 03:14.150 --> 03:21.620 and specify the deployment definition file. Then run the kubectl get deployments command to see the newly 37 03:21.620 --> 03:26.560 created deployment. The deployment automatically creates a replica set. 38 03:26.630 --> 03:32.630 So if you run the kubectl get replica set command you will be able to see a new replica set in 39 03:32.630 --> 03:34.700 the name of the deployment. 40 03:34.920 --> 03:37.650 The replica sets ultimately create pods. 41 03:37.670 --> 03:40.740 So if you run the kubectl get pods command. 42 03:40.880 --> 03:47.690 You will be able to see the pod with the name of the deployment and the replica set so far there hasn't 43 03:47.690 --> 03:54.560 been much of a difference between replica set and deployments, except for the fact that deployment created 44 03:54.590 --> 03:58.490 a new Kubernetes object called deployments. 45 03:58.490 --> 04:03.830 We will see how to take advantage of the deployment using the use cases we discussed in the previous 46 04:03.830 --> 04:06.040 slide in the upcoming lectures. 47 04:07.290 --> 04:14.580 And one more note before we end this lecture to see all the created objects at once run the kubectl 48 04:14.670 --> 04:22.170 get all command and in this case we can see that the deployment was created and then we have the replica 49 04:22.170 --> 04:28.940 set followed by three parts that were created as part of the deployment. 50 04:28.940 --> 04:30.110 That's it for this lecture. 51 04:30.110 --> 04:33.880 We will now head over to a demo and I will see you in the next lecture.