WEBVTT 00:05.030 --> 00:06.740 Hello and welcome to this lecture. 00:08.200 --> 00:08.900 In this lecture, 00:09.320 --> 00:13.970 We'll talk about creating a part using a YAML based configuration file. 00:15.500 --> 00:19.850 In the previous lecture we learned about YAML files in general. 00:20.250 --> 00:27.700 Now we will learn how to develop YAML files specifically for Kubernetes. Kubernetes uses YAML files 00:27.800 --> 00:35.520 as inputs for the creation of objects such as POD's, replicas, deployment services, etc. All of these 00:35.530 --> 00:42.570 follow similar structure Kubernetes definition file always contains 4 top level fields. 00:43.670 --> 00:44.560 The API version, kind, 00:45.220 --> 00:47.200 metadata and spec. 00:47.380 --> 00:51.650 These are the top level or root level properties. 00:51.670 --> 00:57.280 These are also required fields so you must have them in your configuration file. 00:57.610 --> 00:59.620 Let's just look at each one of them. 00:59.710 --> 01:02.340 The first one is the API version. 01:02.350 --> 01:07.670 This is the version of the Kubernetes API you're using to create the objects. 01:07.780 --> 01:15.100 Depending on what we are trying to create we must use the right API version. For now since we are working 01:15.100 --> 01:16.360 on part. 01:16.360 --> 01:19.480 We will set the API version as we want. 01:19.480 --> 01:24.430 Few other possible values for this field are apps/v1. 01:24.430 --> 01:27.180 extensions/v1Beta 01:27.340 --> 01:29.040 etc.. 01:29.290 --> 01:32.310 We will see what these are for later in this course. 01:33.310 --> 01:39.850 Next is the kind. The kind refers to the type of object we are trying to create which in this case happens 01:39.850 --> 01:41.370 to be a POD. 01:41.530 --> 01:44.490 So we will set it as POD. 01:44.540 --> 01:50.260 Some other possible values here could be replica set or deployment or service which is what you see 01:50.260 --> 01:56.340 in the kind field in the table on the right the next is metadata. 01:56.590 --> 02:06.430 The metadata is data about the object like its name labels etc. As you can see unlike the first two where 02:06.430 --> 02:09.820 you have specified a string value, 02:09.820 --> 02:12.350 this is in the form of a dictionary. 02:13.410 --> 02:21.060 So, everything under metadata is intended to the right a little bit and so names and labels are children 02:21.150 --> 02:23.020 of metadata. 02:23.130 --> 02:28.330 The number of spaces before the two properties name and labels doesn't matter. 02:28.500 --> 02:31.970 But they should be the same as they are siblings. 02:32.040 --> 02:40.140 In this case labels has more spaces on the left than name and so it is now a child of the name property 02:40.230 --> 02:41.690 instead of a sibling. 02:41.760 --> 02:42.880 Which is incorrect. 02:43.910 --> 02:51.230 Also the two properties must have more spaces than its parent which is metadata so that it's intended 02:51.230 --> 02:53.120 to the right a little bit. 02:53.120 --> 02:59.620 In this case all three of them have the same number of spaces before them and so they are all siblings. 02:59.630 --> 03:09.750 Which is not correct. Under metadata the name is a string value so you can name your pod my app pod and 03:09.750 --> 03:12.130 the labels is a dictionary. 03:12.150 --> 03:20.180 So labels is a dictionary within the metadata dictionary and it can have any key value pairs as you 03:20.180 --> 03:20.910 wish. 03:20.990 --> 03:26.490 For now I have added a label app with the value my app. 03:26.570 --> 03:30.260 Similarly you could add other labels as you see fit. 03:30.260 --> 03:34.220 Which will help you identify these objects at a later point in time. 03:34.490 --> 03:40.460 Say for example there are hundreds of pods running a front end application and hundreds of pods running 03:40.490 --> 03:43.650 a backend application or a database. 03:43.670 --> 03:48.800 It will be difficult for you to group these parts once they are deployed. 03:48.800 --> 03:54.830 If you label them now as frontend backend or database you will be able to filter the parts. 03:54.830 --> 04:02.480 Based on this label at a later point in time it's important to note that under metadata you can only 04:02.480 --> 04:08.970 specify name or labels or anything else that Kubernetes expects to be under metadata. 04:09.020 --> 04:13.100 You cannot add any other property as you wish under this. 04:13.280 --> 04:19.270 However, under labels you can have any kind of key or value pairs as you see fit. 04:19.610 --> 04:24.970 So it's important to understand what each of these parameters expect. 04:24.980 --> 04:30.590 So far we have only mentioned that type and name of the object we need to create which happens to be 04:30.590 --> 04:32.240 a part with a name. 04:32.240 --> 04:39.250 My app part, but we haven't really specified the container or image we need in the part. 04:39.290 --> 04:46.970 The last section in the configuration file is the specification section which is written as spec. Depending 04:46.970 --> 04:49.310 on the object we are going to create. 04:49.310 --> 04:55.110 This is where we would provide additional information to Kubernetes pertaining to that object. 04:55.520 --> 05:00.650 This is going to be different for different objects so it's important to understand or refer to the 05:00.650 --> 05:08.550 documentation section to get the right format for each since we are only creating a pod with a single 05:08.550 --> 05:09.830 container in it. 05:09.840 --> 05:13.770 It is easy. Spec is a dictionary. 05:13.770 --> 05:21.420 So add a property under it called containers. Containers is a list or an array. 05:21.420 --> 05:27.420 The reason this property is a list is because the parts can have multiple containers within them. 05:27.420 --> 05:34.080 As we learned in the lecture earlier in this case though we will only add a single item in the list 05:34.350 --> 05:41.280 since we plan to have only a single container in the part that - right before the name indicates 05:41.280 --> 05:46.950 that this is the first item in the list the item in the list is a dictionary. 05:46.950 --> 05:54.300 So add a name and image property the value for image is ngina, which is the name of the docker image 05:54.390 --> 05:57.030 in the docker repository. 05:57.120 --> 06:04.140 Once the file is created from the command qctl create -f followed by the file name which is 06:04.140 --> 06:05.350 pod-definition.yml 06:05.460 --> 06:09.190 and Kubernetes creates the pod. 06:09.230 --> 06:10.330 So to summarize. 06:10.340 --> 06:17.870 Remember the four top level properties API version, kind metadata and spec. 06:17.870 --> 06:24.330 Then start by adding values to those depending on the object you're going to create. 06:24.350 --> 06:26.970 Once we create the pod How do you see it? 06:27.260 --> 06:31.840 Use the kubectl get pods command to see a list of pods available.YAML 06:31.850 --> 06:36.710 In this case it's just want to see detailed information about the pod. 06:36.740 --> 06:38.170 Run the kubectl 06:38.210 --> 06:40.080 Describe part command. 06:40.400 --> 06:44.240 This will tell you information about the part when it was created. 06:44.240 --> 06:46.100 What labels are assigned to it. 06:46.100 --> 06:50.690 What containers are part of it and the events associated with that part. 06:52.340 --> 06:53.610 That's it for this lecture. 06:53.620 --> 06:57.410 We will now head over to a demo and I will see you in the next lecture.