Hello and welcome to this lecture.
My name is Mumshad Mannambeth and we are learning Kubernetes for beginners. In this lecture,
We'll talk about creating a part using a YAML based configuration file.
In the previous lecture we learned about YAML files in general.
Now we will learn how to develop YAML files specifically for Kubernetes. Kubernetes uses YAML files
as inputs for the creation of objects such as POD's, replicas, deployment services, etc. All of these
follow similar structure Kubernetes definition file always contains 4 top level fields.
The API version, kind,
metadata and spec.
These are the top level or root level properties.
These are also required fields so you must have them in your configuration file.
Let's just look at each one of them.
The first one is the API version.
This is the version of the Kubernetes API you're using to create the objects.
Depending on what we are trying to create we must use the right API version. For now since we are working
on part.
We will set the API version as we want.
Few other possible values for this field are apps/v1.
extensions/v1Beta
etc..
We will see what these are for later in this course.
Next is the kind. The kind refers to the type of object we are trying to create which in this case happens
to be a POD.
So we will set it as POD.
Some other possible values here could be replica set or deployment or service which is what you see
in the kind field in the table on the right the next is metadata.
The metadata is data about the object like its name labels etc. As you can see unlike the first two where
you have specified a string value,
this is in the form of a dictionary.
So, everything under metadata is intended to the right a little bit and so names and labels are children
of metadata.
The number of spaces before the two properties name and labels doesn't matter.
But they should be the same as they are siblings.
In this case labels has more spaces on the left than name and so it is now a child of the name property
instead of a sibling.
Which is incorrect.
Also the two properties must have more spaces than its parent which is metadata so that it's intended
to the right a little bit.
In this case all three of them have the same number of spaces before them and so they are all siblings.
Which is not correct. Under metadata the name is a string value so you can name your part my app part and
the labels is a dictionary.
So labels is a dictionary within the metadata dictionary and it can have any key value pairs as you
wish.
For now I have added a label app with the value my app.
Similarly you could add other labels as you see fit.
Which will help you identify these objects at a later point in time.
Say for example there are hundreds of pods running a front end application and hundreds of pods running
a backend application or a database.
It will be difficult for you to group these parts once they are deployed.
If you label them now as frontend backend or database you will be able to filter the parts.
Based on this label at a later point in time it's important to note that under metadata you can only
specify name or labels or anything else that Kubernetes expects to be under metadata.
You cannot add any other property as you wish under this.
However, under labels you can have any kind of key or value pairs as you see fit.
So it's important to understand what each of these parameters expect.
So far we have only mentioned that type and name of the object we need to create which happens to be
a part with a name.
My app part, but we haven't really specified the container or image we need in the part.
The last section in the configuration file is the specification section which is written as spec. Depending
on the object we are going to create.
This is where we would provide additional information to Kubernetes pertaining to that object.
This is going to be different for different objects so it's important to understand or refer to the
documentation section to get the right format for each since we are only creating a pod with a single
container in it.
It is easy. Spec is a dictionary.
So add a property under it called containers. Containers is a list or an array.
The reason this property is a list is because the parts can have multiple containers within them.
As we learned in the lecture earlier in this case though we will only add a single item in the list
since we plan to have only a single container in the part that - right before the name indicates
that this is the first item in the list the item in the list is a dictionary.
So add a name and image property the value for image is ngina, which is the name of the docker image
in the docker repository.
Once the file is created from the command qctl create -f followed by the file name which is
pod-definition.yml
and Kubernetes creates the pod.
So to summarize.
Remember the four top level properties API version, kind metadata and spec.
Then start by adding values to those depending on the object you're going to create.
Once we create the pod How do you see it?
Use the kubectl get pods command to see a list of pods available.YAML
In this case it's just want to see detailed information about the pod.
Run the kubectl
Describe part command.
This will tell you information about the part when it was created.
What labels are assigned to it.
What containers are part of it and the events associated with that part.
That's it for this lecture.
We will now head over to a demo and I will see you in the next lecture.