WEBVTT 0 00:05.030 --> 00:06.740 Hello and welcome to this lecture. 1 00:06.740 --> 00:12.310 My name is Mumshad Mannambeth and we are learning Kubernetes for beginners. In this lecture, 2 00:12.320 --> 00:17.970 We'll talk about creating a part using a YAML based configuration file. 3 00:19.500 --> 00:23.850 In the previous lecture we learned about YAML files in general. 4 00:23.850 --> 00:30.990 Now we will learn how to develop YAML files specifically for Kubernetes. Kubernetes uses YAML files 5 00:31.080 --> 00:39.520 as inputs for the creation of objects such as POD's, replicas, deployment services, etc. All of these 6 00:39.530 --> 00:46.570 follow similar structure Kubernetes definition file always contains 4 top level fields. 7 00:46.670 --> 00:49.060 The API version, kind, 8 00:49.220 --> 00:51.200 metadata and spec. 9 00:51.380 --> 00:55.650 These are the top level or root level properties. 10 00:55.670 --> 01:01.280 These are also required fields so you must have them in your configuration file. 11 01:01.610 --> 01:03.620 Let's just look at each one of them. 12 01:03.710 --> 01:06.340 The first one is the API version. 13 01:06.350 --> 01:11.670 This is the version of the Kubernetes API you're using to create the objects. 14 01:11.780 --> 01:19.100 Depending on what we are trying to create we must use the right API version. For now since we are working 15 01:19.100 --> 01:20.360 on part. 16 01:20.360 --> 01:23.480 We will set the API version as we want. 17 01:23.480 --> 01:28.430 Few other possible values for this field are apps/v1. 18 01:28.430 --> 01:31.180 extensions/v1Beta 19 01:31.340 --> 01:33.040 etc.. 20 01:33.290 --> 01:36.310 We will see what these are for later in this course. 21 01:37.310 --> 01:43.850 Next is the kind. The kind refers to the type of object we are trying to create which in this case happens 22 01:43.850 --> 01:45.370 to be a POD. 23 01:45.530 --> 01:47.490 So we will set it as POD. 24 01:47.540 --> 01:54.260 Some other possible values here could be replica set or deployment or service which is what you see 25 01:54.260 --> 02:00.340 in the kind field in the table on the right the next is metadata. 26 02:00.590 --> 02:10.430 The metadata is data about the object like its name labels etc. As you can see unlike the first two where 27 02:10.430 --> 02:13.820 you have specified a string value, 28 02:13.820 --> 02:16.350 this is in the form of a dictionary. 29 02:17.410 --> 02:25.060 So, everything under metadata is intended to the right a little bit and so names and labels are children 30 02:25.150 --> 02:27.020 of metadata. 31 02:27.130 --> 02:32.330 The number of spaces before the two properties name and labels doesn't matter. 32 02:32.500 --> 02:35.970 But they should be the same as they are siblings. 33 02:36.040 --> 02:44.140 In this case labels has more spaces on the left than name and so it is now a child of the name property 34 02:44.230 --> 02:45.690 instead of a sibling. 35 02:45.760 --> 02:46.880 Which is incorrect. 36 02:47.910 --> 02:55.230 Also the two properties must have more spaces than its parent which is metadata so that it's intended 37 02:55.230 --> 02:57.120 to the right a little bit. 38 02:57.120 --> 03:03.620 In this case all three of them have the same number of spaces before them and so they are all siblings. 39 03:03.630 --> 03:13.750 Which is not correct. Under metadata the name is a string value so you can name your part my app part and 40 03:13.750 --> 03:16.130 the labels is a dictionary. 41 03:16.150 --> 03:24.180 So labels is a dictionary within the metadata dictionary and it can have any key value pairs as you 42 03:24.180 --> 03:24.910 wish. 43 03:24.990 --> 03:30.490 For now I have added a label app with the value my app. 44 03:30.570 --> 03:34.260 Similarly you could add other labels as you see fit. 45 03:34.260 --> 03:38.220 Which will help you identify these objects at a later point in time. 46 03:38.490 --> 03:44.460 Say for example there are hundreds of pods running a front end application and hundreds of pods running 47 03:44.490 --> 03:47.650 a backend application or a database. 48 03:47.670 --> 03:52.800 It will be difficult for you to group these parts once they are deployed. 49 03:52.800 --> 03:58.830 If you label them now as frontend backend or database you will be able to filter the parts. 50 03:58.830 --> 04:06.480 Based on this label at a later point in time it's important to note that under metadata you can only 51 04:06.480 --> 04:12.970 specify name or labels or anything else that Kubernetes expects to be under metadata. 52 04:13.020 --> 04:17.100 You cannot add any other property as you wish under this. 53 04:17.280 --> 04:23.270 However, under labels you can have any kind of key or value pairs as you see fit. 54 04:23.610 --> 04:28.970 So it's important to understand what each of these parameters expect. 55 04:28.980 --> 04:34.590 So far we have only mentioned that type and name of the object we need to create which happens to be 56 04:34.590 --> 04:36.240 a part with a name. 57 04:36.240 --> 04:43.250 My app part, but we haven't really specified the container or image we need in the part. 58 04:43.290 --> 04:50.970 The last section in the configuration file is the specification section which is written as spec. Depending 59 04:50.970 --> 04:53.310 on the object we are going to create. 60 04:53.310 --> 04:59.110 This is where we would provide additional information to Kubernetes pertaining to that object. 61 04:59.520 --> 05:04.650 This is going to be different for different objects so it's important to understand or refer to the 62 05:04.650 --> 05:12.550 documentation section to get the right format for each since we are only creating a pod with a single 63 05:12.550 --> 05:13.830 container in it. 64 05:13.840 --> 05:17.770 It is easy. Spec is a dictionary. 65 05:17.770 --> 05:25.420 So add a property under it called containers. Containers is a list or an array. 66 05:25.420 --> 05:31.420 The reason this property is a list is because the parts can have multiple containers within them. 67 05:31.420 --> 05:38.080 As we learned in the lecture earlier in this case though we will only add a single item in the list 68 05:38.350 --> 05:45.280 since we plan to have only a single container in the part that - right before the name indicates 69 05:45.280 --> 05:50.950 that this is the first item in the list the item in the list is a dictionary. 70 05:50.950 --> 05:58.300 So add a name and image property the value for image is ngina, which is the name of the docker image 71 05:58.390 --> 06:01.030 in the docker repository. 72 06:01.120 --> 06:08.140 Once the file is created from the command qctl create -f followed by the file name which is 73 06:08.140 --> 06:09.350 pod-definition.yml 74 06:09.460 --> 06:13.190 and Kubernetes creates the pod. 75 06:13.230 --> 06:14.330 So to summarize. 76 06:14.340 --> 06:21.870 Remember the four top level properties API version, kind metadata and spec. 77 06:21.870 --> 06:28.330 Then start by adding values to those depending on the object you're going to create. 78 06:28.350 --> 06:30.970 Once we create the pod How do you see it? 79 06:31.260 --> 06:35.840 Use the kubectl get pods command to see a list of pods available.YAML 80 06:35.850 --> 06:40.710 In this case it's just want to see detailed information about the pod. 81 06:40.740 --> 06:42.170 Run the kubectl 82 06:42.210 --> 06:44.080 Describe part command. 83 06:44.400 --> 06:48.240 This will tell you information about the part when it was created. 84 06:48.240 --> 06:50.100 What labels are assigned to it. 85 06:50.100 --> 06:54.690 What containers are part of it and the events associated with that part. 86 06:56.340 --> 06:57.610 That's it for this lecture. 87 06:57.620 --> 07:01.410 We will now head over to a demo and I will see you in the next lecture.