1 00:00:00,001 --> 00:00:02,134 [No Audio] 2 00:00:02,134 --> 00:00:05,201 To avoid any confusion, let's start with a list of 3 00:00:05,201 --> 00:00:09,434 the pods, by running kubectl get pods. We have 4 00:00:09,434 --> 00:00:12,601 three Pods from our previous replica set. Let them 5 00:00:12,601 --> 00:00:16,667 be where they are, and let's open our deployment.yaml file. 6 00:00:17,101 --> 00:00:19,534 Let's start from the top. Just like 7 00:00:19,534 --> 00:00:23,634 replica sets, deployments also use API version, 8 00:00:23,634 --> 00:00:27,834 apps/v1. Their kind, or object type is 9 00:00:27,834 --> 00:00:31,101 obviously Deployment, we have given it the name of 10 00:00:31,134 --> 00:00:35,334 deploy -nginx. Let's go to the specs field. 11 00:00:35,567 --> 00:00:38,801 We are using matchLabels strategy as selectors, 12 00:00:38,934 --> 00:00:44,067 and we will be looking for Pods with label app: nginx. 13 00:00:44,067 --> 00:00:45,734 Deployments are higher level 14 00:00:45,734 --> 00:00:48,501 orchestration objects compared to replica sets. 15 00:00:48,501 --> 00:00:51,901 So, if we are creating a deployment, a deployment 16 00:00:51,901 --> 00:00:55,101 itself is capable of creating the replica set it 17 00:00:55,101 --> 00:00:59,201 needs. By providing replicas field, we can instruct 18 00:00:59,201 --> 00:01:01,834 the resultant replica to create a certain number 19 00:01:01,834 --> 00:01:05,934 of Pods. Now let's go to the Pod template and fill 20 00:01:05,934 --> 00:01:10,634 out the data. We will provide the labels app: nginx 21 00:01:10,634 --> 00:01:13,167 to avoid any conflicts, and we will 22 00:01:13,167 --> 00:01:15,901 provide the container information which include 23 00:01:15,901 --> 00:01:19,167 name, which is deploy-container and container 24 00:01:19,167 --> 00:01:23,667 image, which is nginx 1.7.9. We are back 25 00:01:23,667 --> 00:01:26,567 to using images from Docker's registry, because well 26 00:01:26,567 --> 00:01:29,267 they are just simple to write. After mentioning 27 00:01:29,267 --> 00:01:32,801 the port, let's save and exit this file. As usual, 28 00:01:32,934 --> 00:01:35,734 let's write kubetl create -f followed by 29 00:01:35,734 --> 00:01:39,034 the name of the file which is deployment.yaml. 30 00:01:39,034 --> 00:01:42,334 And our deployment is created. Let's have a list 31 00:01:42,334 --> 00:01:45,901 of Pods again. And we have two new Pods here, 32 00:01:45,901 --> 00:01:50,134 the top two Pods are nginx Pods created by deployment 33 00:01:50,167 --> 00:01:52,567 deploy-nginx.. 34 00:01:54,034 --> 00:01:56,101 First of all, apart from 35 00:01:56,101 --> 00:01:59,801 the label which we have provided, which is app: nginx, 36 00:01:59,801 --> 00:02:02,034 the pod contains another label 37 00:02:02,034 --> 00:02:04,534 which is for the Pod template it is using. 38 00:02:04,534 --> 00:02:07,467 This label has been provided by Kubernetes itself. 39 00:02:07,767 --> 00:02:11,901 Next up we have Controlled By. As you can see, this Pod 40 00:02:11,901 --> 00:02:14,901 is not directly controlled by a deployment, it is 41 00:02:14,901 --> 00:02:17,867 controlled by a replica set, which is controlled 42 00:02:17,867 --> 00:02:21,067 by deployment. Next, we have container details 43 00:02:21,101 --> 00:02:26,134 including Image name, Image, ID, and Status which is READY. 44 00:02:26,134 --> 00:02:29,067 We also have the normal events of images 45 00:02:29,067 --> 00:02:32,267 being pulled and the container being created, etc. 46 00:02:32,267 --> 00:02:34,267 Let's clear out our terminal 47 00:02:34,267 --> 00:02:36,301 [No Audio] 48 00:02:36,301 --> 00:02:38,001 and describe our deployment. 49 00:02:38,001 --> 00:02:39,901 The deployment description provides a 50 00:02:39,901 --> 00:02:43,134 lot of details, starting with the obvious ones, like 51 00:02:43,134 --> 00:02:47,034 Name, Namespaces, and Labels. We have description 52 00:02:47,034 --> 00:02:50,067 about ReplicaSet, which indicates that this 53 00:02:50,067 --> 00:02:53,134 ReplicaSet is supposed to keep two Pods up and 54 00:02:53,134 --> 00:02:56,267 running. Below that, we have StrategyType. 55 00:02:56,267 --> 00:02:59,034 You might be wondering what kind of strategy? 56 00:02:59,034 --> 00:03:02,101 Well, we are talking about update strategy of the 57 00:03:02,101 --> 00:03:04,734 deployment. One of the most well known use cases 58 00:03:04,734 --> 00:03:08,667 of deployments is without taking it down. Here the 59 00:03:08,667 --> 00:03:11,501 StrategyType is RollingUpdate. If you are 60 00:03:11,501 --> 00:03:14,467 wondering what RollingUpdate strategy means, just 61 00:03:14,467 --> 00:03:18,767 go a couple of steps below. And we have RollingUpdateStrategy details. 62 00:03:18,767 --> 00:03:22,167 It says 25% max unavailable 63 00:03:22,167 --> 00:03:27,334 and 25% max surge. It means that when this 64 00:03:27,334 --> 00:03:32,367 deployment is being updated, only 25% of its total 65 00:03:32,367 --> 00:03:37,067 Pods can be unavailable, and the cluster is only 66 00:03:37,067 --> 00:03:41,534 allowed to deploy 25% of extra Pods while updating 67 00:03:41,534 --> 00:03:45,267 the deployment. Take this example if a deployment 68 00:03:45,267 --> 00:03:48,467 has 4 Pods, and we are trying to update it, 69 00:03:48,467 --> 00:03:53,401 then 25% max unavailability means, the deployment 70 00:03:53,401 --> 00:03:56,501 needs to keep at least 3 Pods up and running 71 00:03:56,501 --> 00:04:01,167 all the time. And 25% max surge means that the 72 00:04:01,167 --> 00:04:05,767 deployment can only create up to 5 Pods at max. 73 00:04:06,067 --> 00:04:09,067 Going below we have details about Pod Template, 74 00:04:09,301 --> 00:04:12,034 which is quite common. But if you go even below 75 00:04:12,034 --> 00:04:15,134 that, we have the name of the replica set which 76 00:04:15,134 --> 00:04:18,401 has been created under this deployment. And if you 77 00:04:18,401 --> 00:04:21,666 look at the events, only one event is directly 78 00:04:21,666 --> 00:04:24,701 linked to the deployment, which is scaling up the 79 00:04:24,701 --> 00:04:27,934 replica set to 2, rest all of the events regarding 80 00:04:27,966 --> 00:04:31,701 Pod and containers are handled by either ReplicaSets 81 00:04:31,701 --> 00:04:33,567 which work under the deployment 82 00:04:33,567 --> 00:04:36,367 or Pods which are governed by ReplicaSets.