Kubernetes YAML Tutorial | Kubernetes | YAML | DevOps | Edureka Live

Key Takeaways

Hello everyone. I welcome all of you on behalf of Edureka. So in our today's session guys, we are mainly going to talk on the Kubernetes YAML file. Okay, so what is YAML? Why should we use it? Structure of a YAML file, basics of YAML, YAML map, list, okay, dictionary, uh how to use YAML in Kubernetes. We will see all those things. So in short, our whole agenda is inclined towards the YAML and mainly about the YAML usage in Kubernetes. How do we write a YAML file in Kubernetes? That is what we have to mainly see. Okay? Now let's jump back to our actual topic of the day. Okay, what exactly is the YAML? Okay. So let's talk about that. So let me also open up a notepad quickly. Okay, that will help me in making some notes over here for you guys so that you can easily see that. Okay, so first of all, Kubernetes. So Kubernetes guys is a container orchestrator. Okay, it's going to be a container orchestrator. So we all know like we have some tools to create container. Like for example, I want to create a container. So I can create a container using tools like Docker. I can create it using some tools like Podman, Containerd, okay, Cryo. There are multiple tools that I can use to create containers. But when I'm running my applications in the container, whenever I'm running my application in a container, the problem is that these tools do not provide me the high availability and fault tolerance of my containerized apps. Containerized apps. It do not provide that. For example, let's suppose I have a server. Okay, on this uh particular server, okay, I install a operating system. I install a OS. On top of that, I simply go and deploy my uh Docker. Okay, let's suppose I take example of Docker because Docker is one of the very famous container tool. Okay, so that's why I'm using Docker. However, I can use any of the tool over here. Okay? So, let's suppose I am using Docker and I'm creating some containers over here. Now, in these containers I'm running application like MySQL or I may be running application like a Redis, Kafka. Okay, or maybe some web server. It can be your Nginx web server. So, I'm running many applications inside the server and Docker is helping me to create these applications in the container, run these applications in the container. But, the big problem here is that if this VM, the server that I'm running, okay, it's basically a virtual machine. If this server crash, if this VM is shut down, okay, you shut it down or if this VM goes corrupt, uh corrupt means VM goes corrupt means uh the OS is corrupt, okay, somebody hacked into the OS, some OS files are deleted accidentally, something happened to the operating system or something happened to the VM. Then, in such a situation, guys, what is going to happen is that all these containers that you're running, okay, all these containers will die. Okay? These containers have no fault tolerance. These containers cannot overcome from a failure automatically. So, there's no fault tolerance. Fault tolerance means if the container is dead, it should get auto recreated. I have a single machine. This is a standalone VM. It's all a standalone VM. Okay? This is all a standalone VM and if I have any containers running on this standalone VM, then the big problem here is that on this VM, if the VM anything happens to the VM, all containers will be gone. Okay? So, there's no fault tolerance. There's no high availability. High availability means I have a single VM. Okay? And that's where the problem comes up. Okay? So, I do not have any fault tolerance, any high availability for my applications that are running in the containers. Right? So, now how I can get this? How I can actually get this? So, that's where I require some kind of container orchestrator. Okay, so when I say container orchestrator, it simply means that a tool I require a tool that will help me in providing me the high availability and the fault tolerance of containers. So, Kubernetes is one of the tool. We have multiple tools. Not only Kubernetes is there, but we have some tools like Docker Swarm. We have something called as Apache Mesosphere. Okay, we have multiple tools that are nothing but the container orchestrators. Okay, there are multiple tools in the market and the main job of these tool orchestrator. Okay, and the main job of this tool is to provide the high availability and fault tolerance of the containerized apps. Okay, how they provide? So, basically, if I talk about simple example with Kubernetes. So, in Kubernetes, you have multiple VMs. Okay, this is my virtual machine number one. This is virtual machine number two. This is virtual machine number three. Okay, and on top of that, I will be having on each VM, I will be having a operating system layer. OS will be there. There's also going to be OS. There's going to be an OS. Okay, there's also going to be a OS over here. Okay, on top of that, I will be having some container tools like Docker. Docker, Podman, Containerd, anything is fine. Because ultimately, these tools will help us in creating containers. Okay, so I will be having a container tool. And in short, what this Kubernetes is going to do? Kubernetes is going to create a cluster network between these VMs. It's going to create a cluster network. Okay, now that cluster network is also called as your container network. It is also called as your container network. What do I mean by that? That whenever you create a container over here, that container will take the IP from this. Okay, if you create a container over there, the container will take the IP. So now in this whole cluster, I have a cluster of four VMs, 1 2 3 and 4. So I have these four virtual machines. Now I create container on any VM, does not matter. Containers can talk to each other over this private network. Which is also called as the pod network or the container network. Okay, what is a pod? We'll discuss that pod as well. How to create a pod using YAML, that we will also discuss. Okay? So yes, if I want to create this container, then definitely the thing is that I can create it directly on Docker, but Docker do not give me high availability fault tolerance. So I have multiple VMs. Now in case this VM fails, this whole machine crashed, I do not have to worry. Automatically what is going to happen, this container this container will be moved to some other healthy VM. Okay, it will be recreated on some other healthy virtual machine of the cluster. So I have four VMs, VM 1, VM 2, VM 3 and VM 4. I have four VMs. So if the container fails okay, on this particular VM or on if the VM completely fails, no need to worry. Automatically this container will be recreated. So this is fault tolerance. Let's suppose fault tolerance means automatically recovering from a failure, self-healing nature, auto-healing nature. Okay? Let's suppose this is a container that I'm running over here and this container is a very critical application. Let's suppose this is MySQL. This is my SQL database. Okay, and I want to make sure that this application runs into multiple containers. I can do that. I can have one container of MySQL over here. I can have one container of MySQL over there. I can do those things. Right? So, this is nothing but a running multiple copies of the same application. I'm running my SQL into three containers. Okay. So, if any of the container fails, let's suppose machine two fails, I can still access my database from machine three and machine four. My SQL is running successfully on third and fourth. Right? It is running successfully on third and fourth. So, definitely this is one of a big plus point. It provides high availability. Having multiple copies of the same application Having multiple copies of the same application is nothing, but it is called as high availability. Understood? So, Kubernetes not only provides this network to us. Kubernetes also provides the fault tolerance and the high availability for our containerized application. If any of the VM is down, I do not have to worry about it. That VM will be automatically They will That will They will not be a single VM. There will be multiple VMs. So, if I'm running my container on any VM and if that VM crashes, automatically container will be recreated on some other VM. That's what Kubernetes or Docker Swarm or the Apache Mesosphere provide. Now, the big question comes up and our actual agenda. How do we create How do we create any container? Or basically in Kubernetes we call it as pod. Pod in Kubernetes. This is what we need to understand. And for that, we can do it in two ways. Either we can use a command or we write a YAML file and execute YAML file to create the pod. Now, what exactly is the pod? Okay. Pod is nothing but Pod is basically a wrapper around the container. Like Kubernetes, Kubernetes will never be managing container directly. In the container, your application is running. Okay? So, Kubernetes need to have another layer. Kubernetes has another layer which is called as pod, a wrapper around the container. So, as of now, you can think that a pod is equal to a container. Okay? However, this is not 100% true because in one pod, okay, in a single pod, you can have multiple containers. That is also true. So, pod is another layer for managing containers. Kubernetes will never interact with container directly. Kubernetes will always be managing these containers via the pods. Okay? So, the big question here is how to create that pod, how to create my application. I can do it by the command or I can do it by the YAML file. So, command is very simple. If I want to create a pod, kubectl Okay? kubectl uh run uh first pod Okay? And I can give minus minus image. And once I run this command, kubectl is the command line. Okay? The instruction. kubectl is the CLI for running any Kubernetes command. So, kubectl uh run run is the instruction that I want to run the pod. The name of the pod, and inside this pod, I want to run a Nginx container. Okay? So, automatically, this will create a pod on one of the node of the cluster. And on that node, Nginx container will be running successfully. Right? But, there's one more way, that is via the YAML file. So, you write you write the pod configs in the YAML file. You write the pod configurations in the YAML file. That's what you need to do. Right? Once you write the pod configurations in the YAML file, how to write that, we will see that. Okay? Execute the YAML file using the command kubectl minus kubectl create or simply kubectl apply with the file, whatever is the file, pod.yaml. That's it. Okay, so how to write this YAML file is important. How to write the configurations in a YAML file. This is important that we are going to see. Okay, execution is very simple. If you have the YAML file, you run the command cube CTL apply minus F and the minus F minus F stands for providing a file name. So cube CTL apply minus F and the file name, pod.yaml. That's it. If you give that command, the file will be executed and pod will be created. But the main thing is how to write this pod.yaml. So let's try to understand this now. Okay. So creating this pod.yaml is easy. Okay, it's not complex enough. So I will give you some tips and tricks to do that. So I have a documentation over here that I also want to open the API Kubernetes API doc. Okay, so I will open this. And from this documentation you can see what to write in the YAML file. Okay, so this is for the version 1.27. You can also open it for 1.33. And that is the documentation for the version 1.33. Okay, so now I want to create a pod. So click on pod. Okay. And in the pod, okay, first of all, what you need to write. See, if you scroll down, whatever in the red you see here is important. Okay, so you have to write in the YAML file API version, kind, metadata, and specification. Status is optional. Status we do not need to give. It is automatically populated by Kubernetes. So as a end user, as a Kubernetes administrator, I have to mainly focus on four things in the YAML file. API version, kind, metadata, and specifications. Let me copy one by one. Whatever is written in the red, you have to copy it as it is. Okay, so I'm writing the animal file now. API version colon. Okay, API version is the key whose value you have to give on the right-hand side. Left-hand side, it's actually the variable. Right-hand side after colon, it is the value. Okay, second is copy kind, copy this. Put it over here. Colon, space. After that, next one is metadata. Copy. Put it over here. Colon, space. And the last one is the spec, the specifications. Okay, I'm putting it over here. Okay. That's it. So, I'm giving four things over here. Now, from where I've given these four things, easy to remember? So, from here, you can see these 1 2 3 and 4. Right? Okay. Just give me a minute. Yeah, so over here let's start with the API version. So, what is API version? So, guys, API version, when I say API version, API version is nothing but I want to create a pod. Okay, so definitely the first two things are very easy to write. Okay, API version and kind. Okay, what is kind? Kind is the resource that you want to create. Kind is basically a string, API version is a string. Okay, it means for API version, there will be a value. Okay, for kind, there will also be a value. Okay. So, kind is a string, API version is a string. Okay, so what is kind? Kind is basically the type of object, the kind of object that you're creating. For example, if you do not know about API version and kind, no need to worry, just scroll up a bit and you will get everything about that. You can see that over here. Okay? GVK, group, version, and kind. So, if you do not know about kind, okay, let's suppose I want to create a replica set. For replica set, the kind will be replica set. If I want to create a pod, okay, for the pod, kind will be a pod. Copy this as it is, paste it. Done? So, over here I'm pasting, sorry. Right? So, kind Kind is nothing but kind is the resource that you want to create. That is the kind. You want to create a deployment, kind will be deployment. If you want to create pod, kind will be pod. If you want to create a replica set, kind will be replica set. Okay? So, next is the API version. Now, API version is nothing but your group forward slash the version. G and V, GVK. Okay? So, over here you can see what is GV. core V1 Okay? So, over here you can do API version as core {slash} V1. Okay? So, over here core {slash} V1 is the API version. Now, from where I'm getting all these things? From this API documentation, standard API documentation. Group and the version. Group forward slash version is the API version. And kind is pod. That's I'm simply copy and pasting. That's it. But, there is one catch. Okay? Whenever you're writing group version, if group is equal to core, do not use it as the word core is now deprecated. As the word core is now deprecated. Okay, so here this is one thing that you have to remember. That if the word group if the group is core for any resource. Now, it may be a pod. It may be a replication controller. See, for replication controller it is also core. If I want to create a service for service also it is core. So, for any resource that you are creating in Kubernetes, if the group is core drop the word core, only use version. Make sure of this small rule. For all other, you have to go with group {slash} version. For all other, this is you have to go Okay? So, over here right now I am removing core. API version is just V1. Okay, got the first two fields? How to write it? From the API documentation only I'm doing it. Okay? So, now what this is called as? This is called as a key-value pair in the YAML file. In the context of a YAML, we call it as a key-value pair. Where API version is the key, V1 is the value. Here, kind equal to pod, this is also a key-value pair. This is also a key-value pair, guys. Okay? Let me just give it a tab. Just a minute. Yeah. So, this is a key-value pair in the YAML file. This is a key-value pair in the YAML file. Key-value pair simply means that you have a key a variable on the left side, on the right side you have its value. So, if I talk about in YAML context, we call this as key value pair. Okay. Now, coming on to the next session, metadata. So, metadata in YAML is called as a dictionary. Dictionary in the YAML, it's a dictionary. These are data types. So, in YAML you have mainly three data types. YAML has a key value pair, key value pair or it has a dictionary, or it has an array. I'm I've talked about the first two. These are key value pairs. Metadata is not a key value pair. Metadata is a dictionary. Okay, but first thing we need to understand what to write in metadata. What to write under metadata. So, under metadata we define and why we call it as dictionary, that will also come. We define the data about about the resource that you are creating. We define the data about the resource that you're creating. So, I'm creating pod. So, anything about pod like the name of the pod, any label on the pod, any kind of name space for the pod, all those things will be defined under metadata. And why I'm calling it as a dictionary? Because we all know what is a dictionary. English dictionaries, right? A dictionary is a book, right? That contains multiple words and their meaning. Word and its meaning. Means a dictionary is a book that contains key value pair. Word and meaning. Word is the key and its meaning is the value. Right? Same thing applies over here. Metadata contains multiple key value pairs. So, we call it as a dictionary. Inside a dictionary you have multiple key value pairs. Key value pair 1 2 3 4. Inside a dictionary you can have another dictionary called as nested dictionary. Okay, so metadata does not have any value, but inside metadata we have something called as key value pairs. Okay, and how to define that? So, if you want to define anything under metadata, you have to give space. One space is fine. But just for a clear readability we give two spaces. So, that when I read the YAML file it looks very easy for me to read everything. So, one space is fine. Two spaces fine. Three, four, five, six, seven, eight. How many spaces you want to give you can give. Your wish. But just to make my file good to read, okay, I will use two spaces. And now I will write everything, whatever I write from here that was under metadata. Okay, so that's I'm calling metadata as a dictionary. So, what under metadata? Name of the pod. I say first pod. Okay, now the big question is how I come to know what to write in the metadata. Again, guys, the Bible for writing the the Bible for writing the entire YAML file is this documentation. So, if you understand this documentation, you will understand how to write the YAML file. Okay, so over here scroll down. I'm in the pod. Okay, if you're in the pod, scroll down metadata. Okay, standard object metadata. Okay, so click on this object meta. Okay, and you will understand what to write under metadata. It is not a string. It is not a string. API version kind is a string. They are key value pairs, but metadata is not a key value pair. It's a dictionary. So, I click on this object meta and you will see what to write. Scroll down a bit. Scroll down. Scroll down. Scroll down a bit. Don't go on this and you can see it from here. You can write annotations. You can put creation timestamps, deletion grace period, deletion timestamps, finalizers, generate name, generation, labels, manage fields, name, namespace, owner references, resource version, self link, UID. All these things you can put in the metadata. All these things that you see. Not this, but from here, starting The last one is UID. And the first one is annotation. Okay. So, over here, do I need to put all of them? No, not required. I need to put only those that are required for the very basic YAML file. Like I need name. Name. Name is a string. And that is what I've given, name. Okay. So, I'm not writing all these things by myself. I'm following the actual API documentation. I'm working on Kubernetes from last 7 to 8 years now. So, I remember this documentation most of the things on this documentation are by heart to me. Okay. So, even I do not refer this documentation, I will write a YAML file correctly. But as you are beginner, you need to understand. So, that's where this documentation can give you a lot of help while writing the YAML file. Okay. So, over here, the name is a string and that's what I've given over here. See this? Name colon first pod. And this is a key-value pair. After that, let's suppose I want to write multiple other things. Okay. So, in order to write multiple other things, what we have to do here is we just have to give multiple things. Like I want to give a namespace. See, you got You have that in the documentation. Namespace. It's a string. Okay, use it. So, I want to create this pod in the test namespace. Test namespace. I can give that, namespace. Now, what is a namespace? Namespace is basically a way to segregate resources. Okay, I want to create some testing pod in test namespaces, production pod in production namespace. I can do that. So, I can give a namespace like in which namespace the pod should be created. Now, it's a Kubernetes resource. Before creating this pod, you need to make sure that the namespace is created first. Then, you can create the pod in this namespace. Okay, let's suppose there's a namespace that is already available. Default namespace is already there. So, I can say, "Okay, use the namespace default." Good enough. Use it. Understood? Namespace. Default namespace is normally by default present. So, use it. I do not have to create the namespace. I can go and use this namespace directly. Because this namespace exist by default. Okay? And after that, I want to define some label. I want to define some tags on the pod. I can define labels. See, I can define labels as well. See this labels. And label is again a map of string keys and values. It's a map. Map means it's a dictionary again. Okay? Label is a dictionary. Whenever it comes up as map, an object Whenever it says object, it means it is a dictionary. Like for example, if you have seen metadata, metadata was also showing object. Object. Object means it's a map. Map means it's a dictionary. Okay? So, if I go under metadata, under metadata, you I want to write some labels. As I scroll down, I want to write some labels. Label is nothing but a tag for the pod. I want to define it. Okay? And that is also object. It means that it is a map of string keys and values. It is a dictionary. Okay? So, if I want to define labels, it's a dictionary. And this is a nested dictionary. It's a nested dictionary. And what is this first pod name? This is basically a key value pair. Okay, then this one is also a key value pair. Label is a nested dictionary. So as it is a dictionary, I will define anything under labels now. Give two spaces. I can define that this application is a web application, the web app. I can give one more label, okay, that it belongs to a demo environment. I'm just doing a demo. Environment is demo. That's what I'm giving over here. Labels and labels, two labels. This is a key value pair. This is a key value pair. Two key value pairs under a single heading, that is a dictionary. So label is a nested dictionary. Why nested dictionary? Because this is under metadata. Metadata is the main dictionary under which you have two key value pairs. First key value pair, second key value pair, and one dictionary. Okay, so this is how we write metadata. Everything coming from the documentation. You do not have to go anywhere. Just that documentation is your single point for writing anything in Kubernetes, for writing any YAML file in Kubernetes. Okay, now going over here to the specification. Now what under specification? So first let's talk about specification. Specification is basically, okay, we define the specifications of the resource. Means what that resource is going to have. Is going to host or is going to have. Like I'm going to create a pod. So that pod is going to have what? A container. A container name, container image, that is a part of specifications. Okay, so if I go on the specifications, let's go back to the pod first. Let's go to the pod. Okay. So, I'm in the pod as I scroll down a bit over here. Pod spec. Pod spec. Okay, so over here, what do define under specification? You see this. Spec is not a key value pair. Again, it is saying pod spec, it is a dictionary. That will contain multiple key value pairs or it will contain array. A dictionary can contain any Anything can be nested in anything. You have a dictionary which has a dictionary inside it. You have a dictionary that has an array. You have a array that has a dictionary. All the data types can be nested into one another. Okay, so here, my specifications is nothing, but this is also a dictionary. So, I click on pod spec. What to write under pod spec? See this. Now, under specification, you can write active deadline seconds. It's a key value pair, affinity. Affinity is again a dictionary. Automatic service account token, containers. I need to write this. DNS config. Okay, DNS policy. Okay, enable service link, ephemeral containers, host aliases. These are arrays. Arrays. Okay, host IPC, host network, host PID, host user. These are key value pairs. Host name. Image pull secret is an array. Init container is an array. Node name, node selector, OS. Okay, overhead, preemption policy, priority, priority class names, readiness gates, resource claims, resources, restart policy, run times, scheduler names, scheduling gates, security context, service account, service account name, set host name as FQDN. All these things you can see. All these things. Now, here, do I need to write all of them in the spec? No. Whatever you need at this moment, just write it and move move ahead. That's it. So, how I'm going to do that over here is spec. So, as it is again a dictionary, as I said, it is a dictionary. Okay? So, over here, I will first give two spaces. And now, what I need to write under spec is I want to create containers. So, I'll copy this containers. Whatever is in red red color, copy this as it is. Put it over here. Okay? Colon. Enter. And as containers is an array, anything that is an array will always start with a minus sign. Anything that is an array, whenever it says the documentation says that it is an array, it means you have to give a minus sign just below that. And now, whatever you will be writing will be writing one by one. How to write? I will show you that. Okay? Now, what to write under containers? Okay? Container is an array. How I come to know? From this keyword. If it is not written, it means it is a dictionary. Affinity is a dictionary. Okay? Container, see, simple thumb rule. Whenever you see this, and just below that you do not see any hyperlink, it means this is a key-value pair. It's a key-value pair. Right? Whenever you see affinity under below that you see a hyperlink, it means it is a dictionary. And when you see any field below that you see a hyperlink and sideways it is written array, it means it is an array in YAML. It will start with a minus sign. So, here affinity is a dictionary. Active deadline second is a key-value pair. Affinity is a dictionary. Container is an array. And anything that is an array has to start with a minus sign. And now, what to write under this? Let's understand that. So, I go back over here. I click on the container. Click on this hyperlink. Okay? Click here. And you will understand what to write in the container now. Scroll down a bit. You can write arguments, command, you can give environment variables, environment from image. This is important. Okay, you can also give a name to a container. There are multiple things that you can see that what you can give to a container. See this. There are multiple multiple multiple things. See this. So as of now, I'm just keeping very simple. I'm going to give a name to the container and the image. That's it. So give it. So I give a name to the container minus space name. And I give name as my first container. So I'm going to have a pod first pod inside this pod. I'm going to have a container first container. Okay, and after that I will go to the next line and give image. All under one line. Name image under one line. Okay, this shows that container is an array. Minus sign shows that it is an array. And there can be multiple key value pairs inside it. There can also be a dictionary inside containers. Right now, I'm not going to that. Any data type can be nested. Okay, when I say it starts with a minus sign, you can also have multiple containers in a pod. I will show you that. So when I say image, I'm going to use nginx image. Like the one that I was using in the command over there, nginx, same image I'm using over here. Nothing more than that. Similar image. So this is a simple pod YAML file that I've created. Okay, can I cut it short? Yes, I can cut it short. I can remove these four lines. Okay, I can remove these name space labels. It will automatically take the default name space if I remove this labels, it will be created without any label. That's fine. I do not want to give label. I can remove it. So if I want to cut this down, if I want to make it a short version, so I can just do this. Okay, remove all these comments. Let me remove all these comments first. Just a minute. Oh, sorry. API version is V1. Let me remove this. You do not need to give any tab, guys. Tab is not allowed over there, okay? Uh do not give any tabs. If you give a tab, your YAML execution will fail, actually. Okay? So, just remove all the tabs that if you have given anything. Okay, now you want to make it cut short, remove these lines. So, I'm creating a pod. The name of the pod is first pod. Inside that pod, there will be a container called as first container. And image that this container, the application that this container will be having is Nginx. Okay? So, now I can copy and run this. So, where I can run this? So, for that I need to have a cluster. So, I can go and deploy a cluster quickly. So, I have I'm I'm going to use this Google Cloud to deploy a cluster. Right now, I do not have any cluster, but that will take around 10 minutes of time to deploy a cluster. Okay? So, let me deploy that cluster quickly. I did not do that. So, let me activate the Cloud Shell. Okay? So, I'm just going to run a simple command to run the cluster. Let me copy this. I have I'm going to set my computing region and the zone. Okay? Let me set my compute region and the zone first. Okay? So, just a minute. Okay? So, let me try to paste it. So, I'm just setting the compute region, in which region I want to create the cluster, and in which data center I want to create the cluster. Now, I want to create a cluster with two nodes. So, just to make my life easier and to make it more faster, I'm just creating a Kubernetes cluster with a single node, with one node. Okay? Two nodes will take 10 minutes, one node will take 5 minutes. But normally, in a production, we need to have two or more than two nodes. Okay, but as of now, I'm just doing a testing over here to execute the YAML file. I'm just going to have a single node Kubernetes cluster, which is not a valid production configuration. In production, you need to have multiple nodes. Understand that. Okay, why? Because if one of the node fails, you can the containers will be moved or the pods will be moved from one failed node to the other failed or to the other working node. Okay? So, in production, guys, we always go with multiple nodes. So, I'm running a command over here, GKE load container clusters create. This is the command. Name of the cluster is hello cluster. The command is GKE container clusters create. The name of the cluster, any name you can give. Okay, after that, in this cluster, how many nodes you want? I want one node. And in the back end, I can show you that this node is getting provisioned. So, if I go to console.cloud.google.com, okay, you'll see that that there is one node that is getting provisioned. Okay, so I can show you that over there. First of all, see the Kubernetes cluster that is getting provisioned over here. Okay, uh cluster named hello cluster. Okay. See this hello cluster is getting provisioned in the US West 2A data center. And it will be having just one node. To see that node, okay, there's one node, okay? Now, you want to see that node, just go to the compute engine. You see the VM. Node is nothing but a virtual machine on top of which your pods will be created. And you will see that node getting created over here. Okay? So, over here, you can go and check. Okay? Let me go and show you the VM instances. Click on the VM instances. Okay? Once you see the VM instances, this is the node that is getting created. It's a Kubernetes node. Okay, and over here, in the back end, you see my cluster is getting spun up. Cluster has been health checked, it is working. In the meantime, let me copy and paste the animal file that I've created. So, I'm going to open one more new tab over here. Just add one more plus sign. Okay, and let me dismiss this. Let me paste the content of my file. So, here was my file. Right? This is my file. Copy this. Paste it over here. VI pod.yaml. Oh, let me just check if I have anything. Yeah, I have multiple things over here. There's a pod.yaml. VI pod.yaml. Okay, let me remove this. That's fine. Escape this. And let me paste the content. Okay, I'm just pasting the content. So, paste the content. Uh, sorry. Let me copy that one more time. Copy from the notepad. Paste it on the CLI. Paste it. Done. So, this is my file. API version V1. Kind pod. Name of the pod is first pod. Inside the pod, I'm going to have a container first container. Image nginx. Save and quit. And can we see the file? Yes, I can see the file very well. See, the file is visible. Absolutely, yes, the file is there. Okay? Now, I want to execute this file. So, I just have to wait for this cluster to be created. Once this cluster is created, I will run a very simple command. kubectl apply this file. Minus F the file name. That's it. Automatically, you will see pod getting created. And to delete the pod, I will run the command kubectl delete and the file name. Minus F the file name. Pod will be terminated. So, the file that you're using to create the resource, same file you can use to delete the resource as well. Okay, we will see both of them. But, here we have to just wait first until unless this cluster is not being created successfully, I cannot move ahead. I have to wait over here. Because if I run any command at this moment, it will say it can't reach the cluster. Kubectl get me the pod. See error. Could not get the API because right now the cluster is getting created. Okay, cluster is being health checked, working. Okay, so maybe another one to two more minutes, not more than that. Within the next 1 minute or 2 minute, it will be done. Okay, so it's just doing a health check for the entire cluster. In the back end, there's one server that is created, one node for my Kubernetes cluster. And I'm using Google Cloud to create this cluster. Okay? So, now we just have to wait until this is not completed, until I do not get the final output, I cannot do anything. In the back end, let's see my Kubernetes cluster. Let's go to Kubernetes Engine. Okay, and over here see hello cluster, standard cluster is being created, okay. It says 100% healthy, 100% up to date, one node is there. So, let's just wait for this to get completed, okay? Now it is just making it is saying control plane is healthy, okay, it is now working. So, maybe another one more minute of time and this will be done. Okay, so let's just wait for another one more minute. So, it says done, okay? So, now we can see the cluster is there. Okay, so this is the cluster that I have, a single node cluster. I can verify the nodes. Kubectl get me the nodes of the cluster. So, there will be just one node in the cluster. Okay? See the node in the cluster, T5QB running from last 39 seconds. This is the node. If you want to verify the node, you can see the node over here. If you go here in the compute engine, you will see that node is running successfully. Okay. Go to the VM instances. Okay, and over here, can you see the node T5QB? Okay, that is the node that I have right now. Okay, and I go back to my CLI. Okay. Now, can I create the pod? Can I see the pod first? Cube CTL get me the pod. So, you will see no pod. Because right now, the cluster is just now created. There's no pod. Okay, I'm going to create my first pod using the YAML file. I can use the command first. Let me show you the command. Cube CTL run the first pod minus minus image is equal to nginx. I can simply run the command to create the pod. Cube CTL get me the pod. PO or POD, one and the same thing. Cube CTL get pod. POD or PO. Short form for POD is PO. And you can see first pod container creating. I'm not using the YAML file. I'm simply run it via the command. And you can see the pod is running. Now, where this pod is running? I have one node. So, on that node it is running. If you want to verify, Cube CTL describe me the pod first pod. That's it. To describe the pod, simple command to describe the pod. Cube CTL describe the pod first pod. Now, when you describe the pod, you will automatically see that the pod is running on the node T5QB. Because I have a single node. So, on that node only my pod will be running. Right? So, it is using nginx, pulling image nginx, right? Successfully pulled image nginx in 7.96 seconds. Okay. Created container, started container. That's it. Right? So, this is via my command. I've created the pod via the command. Which is not the usual way of doing things in production. We always use the YAML way. So, now let me delete this pod and let me show you the YAML execution. So, kubectl get me the pod and kubectl delete the pod and the pod name. Copy and paste. It will delete the pod for me. Pod is gone. kubectl get the pod. It's gone. p o or p o d, one and the same thing. Okay? See, it's gone. Right? Now, this is my YAML file, guys, the one that we have created just now. I have to execute this. Command is very simple. kubectl apply minus f pod.yaml minus f pod.yaml. That's it. Just run the simple command and the YAML file will be executed and pod will be created. Hit enter. Okay. Pod first pod created. Right? If you want to see, kubectl get me the pod. Can I see the pod? Yes, first pod running. Can I describe this from last 9 second it is running. Can I describe this? kubectl describe me the pod first pod. You will get everything similar. Successfully assigned the pod to the node. Pulling image. Successfully pulled image. Created container first container. Started container first container. So, here, guys, my pod name is first pod. The name of the pod is first pod. That pod is running on the node p5qb. This is the IP address of the pod. 10.168.0.9 is the IP address of the node, sorry, node, not the pod. 10 68 10.168.0.9 is the IP address of this node. Okay? And that you can see over there. Now, the pod is created. This is the IP address of the pod. This is the pod IP. 10.0.0.14 is the pod IP. Right? Inside this pod, I'm running a container, first container. First pod is having a container, first container. From where it is picking? That is what I've given in the YAML file, first container. First pod, first container. Right? You can see first container. And that container is a container D container. It is not using Docker. The cluster Kubernetes cluster is using container D. Image is Nginx. Image is pulled from Docker Hub. See this. And my container is successfully running. The state of the container is running. Pod is running. This is the status of the pod. Inside the pod, container is also running. Right? And that's why you see the state. If you see kubectl get the pod, you see running. One by one, one by one means the pod has one container and that one is successfully running. Okay, if you see something like zero by one, zero by one means the pod has one container, total containers, and out of that zero is running. Running is zero. It means there's some issue with the container, that's why it is not running. Okay, but as of now I can see one by one, it means it is running fine. Now I want to terminate this. kubectl delete minus F the same file. That's it. Delete, terminate. Same file, the file that I used to create, same file I can use to delete it. Hit enter, it's gone. Gone. kubectl get me the pod. Gone. Right? Gone. You can't see it again. If you want to create, just apply it again. kubectl apply. And pod will be created again. Okay, kubectl get pod. Yes, I can see the pod now again. Delete cube CTL delete minus F the same file. It's gone. Okay, pod is deleted. And can I see the pod? No, I can't see the pod. That's it. So for writing YAML file for any resource, pod is just one resource. There are multiple resources like services, deployment, replica set, stateful set, daemon set. Multiples are there. For any resource that for which you want to write the YAML configuration, it has to be via this documentation only. Okay? In the end, I want to clean this cluster. So I'll simply run this command because I do not want this cluster to be running. I will be unnecessarily be charged up. So I'll run this simple command to delete the cluster, delete the Google Kubernetes cluster. Gcloud container clusters delete and the cluster name. It will ask me yes no. I will say yes. Cluster is gone. Done. Okay, so it will take another 5 minutes for deleting this. So that's it guys in the session over here from my side. Have a wonderful evening ahead. Till then guys, thank you and bye-bye. >> Mhm.