So in this video, I'm going to explain what Kubernetes is. We're going to start off with the definition to see what official definition is and what it does. Then we're going to look at the problem solution case study of Kubernetes. Basically, why did Kubernetes even come around and what problems does it solve? We're going to look at the basic architecture.
What are the master nodes and the slave nodes? And what are the Kubernetes processes that actually make up the platform mechanism? Then we're going to see some basic concepts and the components of Kubernetes, which are pods and containers and services. And what is the role of each one of those components?
And finally, we're going to look at a simple configuration that you as a Kubernetes cluster user would use to create those components and configure the cluster to your needs. So let's jump in right into the definition. What is Kubernetes?
So Kubernetes is an open source container orchestration framework, which was originally developed by Google. So on the foundation, it manages containers, be Docker containers or from some other technology, which basically means that Kubernetes helps you manage applications that are made up of hundreds or maybe thousands of containers. And it helps you manage them in different environments like physical machines, virtual machines or cloud environments or even hybrid deployment environments.
So what problems does Kubernetes solve and what are the tasks of a container orchestration tool? Actually, so to go through this chronologically, the rise of microservices cost increased usage of container technologies. because the containers actually offer the perfect host for small, independent applications like microservices and the rise of containers and the microservice technology actually resulted in applications that they're now comprised of hundreds or sometimes maybe even thousands of containers. Now, managing those loads of containers across multiple environments using scripts and self-made tools can be really complex. and sometimes even impossible.
So that specific scenario actually caused the need for having container orchestration technologies. So what those orchestration tools like Kubernetes do is actually guarantee following features. One is high availability. In simple words, high availability means that the application has no downtime, so it's always accessible by the users. A second one is...
scalability, which means that application has a high performance. It loads fast and the users have a very high response rates from the application. And the third one is disaster recovery, which basically means that if an infrastructure has some problems like data is lost or the servers explode or something bad happens with the service center, the structure has to have some kind of mechanism to pick up the data and to restore it to the latest state.
so that application doesn't actually lose any data and the containerized application can run from the latest state after the recovery. And all of these are functionalities that container orchestration technologies like Kubernetes offer. So how does the Kubernetes basic architecture actually look like?
The Kubernetes cluster is made up with at least one master node and then connected to it you have. A couple of worker nodes where each node has a cubelet process running on it and cubelet is actually a Kubernetes process that makes it possible for the cluster to talk to each other, to communicate to each other and actually execute some tasks on those nodes like running application processes. Each worker node has Docker containers of different applications deployed on it.
So depending on how the workload is distributed, you would have different number of Docker containers running on worker nodes and worker nodes are where the actual work is happening. So here is where where your applications are running. So the question is, what is running on master node? Master node actually runs several Kubernetes. processes that are absolutely necessary to run and manage the cluster properly.
One of such processes is an API server, which also is a container. An API server is actually the entry point to the Kubernetes cluster. So this is the process which the different Kubernetes clients will talk to, like why if you're using Kubernetes dashboard and API, if you're using some scripts and automating technologies and a command line tool.
So all of these will talk to the API server and other process that is running on master node is a controller manager, which basically keeps an overview of what's happening in the cluster, whether something needs to be repaired or maybe if a container died and it needs to be restarted, et cetera. And another one is scheduler, which is basically responsible for scheduling containers on different nodes based on the workload and the available. server resources on each node. So it's an intelligent process that decides on which worker node the next container should be scheduled on based on the available resources on those worker nodes and the load that that container needs. And another very important component of the whole cluster is actually an etcd key value storage, which basically holds at any time the current state of the Kubernetes cluster.
So it has all the configuration data inside and all the status data of each node and each container inside of that node and the backup and restore that we mentioned previously is actually made from this ETCD snapshots because you can recover the whole cluster state using that ETCD snapshot. And last but not least, also a very important component of Kubernetes. which enables those notes, worker notes, master notes talk to each other is the virtual network that spends all the notes that are part of the cluster. And in simple words, virtual network actually turns all the notes inside of the cluster into one powerful machine that has the sum of all the resources of individual notes. One thing to be noted here is that worker nodes, because they actually have most load.
because they are running the applications on inside of it, usually are much bigger and have more resources because they will be running hundreds of containers inside of them. Whereas master node will be running just a handful of master processes like we see in this diagram. So it doesn't need that many resources.
However, as you can imagine, master node is much more important than the individual worker nodes, because if, for example, you lose a master node, access, you will not be able to access the cluster anymore. And that means that you absolutely have to have a backup of your master at any time. So in production environments, usually you would have at least two masters inside of your Kubernetes cluster.
But in more cases, of course, you're going to have multiple masters where if one master node is down, the cluster continues to function smoothly because you have other masters available. So now let's look at some Kubernetes basic concepts like pods and containers. In Kubernetes pod is the smallest unit that you as a Kubernetes user will configure and interact with. And pod is basically a wrapper of a container. And on each worker node, you're going to have multiple pods.
And inside of a pod, you can actually have multiple containers. Usually, Per application, you would have one pod, so the only time you would need more than one containers inside of a pod is when you have a main application that needs some helper containers. So usually you would have one pod per application.
So a database, for example, would be one pod, a message broker will be another pod, a server will be again another pod and your. Node.js application, for example, or a Java application will be its own pod. And as we mentioned previously as well, there is a virtual network that spends the Kubernetes cluster. So what that does is that it assigns each pod its own IP address. So each pod is its own self containing server with its own IP address and the way that they can communicate with each other is using that internal IP addresses.
And to note here, we don't actually configure or create containers inside of Kubernetes cluster, but we only work with the pods, which is an abstraction layer over containers and pod is a component of Kubernetes. that manages the containers running inside itself without our intervention. So, for example, if a container stops or dies inside of a pod, it will be automatically restarted inside of the pod. However, pods are ephemeral components, which means that pods can also die very frequently.
And when a pod dies, a new one gets created. And here is where the notion of service comes into. play. So what happens is that whenever a pod gets restarted or recreated, a new pod is created and it gets a new IP address. So, for example, if you have your application talking to a database pod using the IP address, the pods have and the pod restarts, it gets a new IP address.
Obviously, it would be very inconvenient with just that IP address all the time. So because of that, another component of. Kubernetes called service is used, which basically is an alternative or a substitute to those IP addresses.
So instead of having these dynamic IP addresses, their services sitting in front of each pod that talk to each other. So now if a pod behind the service dies and gets recreated, the service stays in place because their life cycles are not tied to each other. And the service has two main functionalities.
One is an IP address. So it's a permanent IP address which you can use to communicate between the pods. And at the same time, it is a load balancer.
So now that we have seen the basic concepts of Kubernetes, how do we actually create those components like pods and services to configure the Kubernetes cluster? All the configuration in Kubernetes cluster actually goes. through a master node with the process called API server, which we mentioned briefly earlier.
So Kubernetes clients, which could be a UI, Kubernetes dashboard, for example, or an API, which could be a script or curl command or a command line tool like kubectl, they all talk to the API server and they send their configuration requests to the API server, which is the main entry point or the only entry point into the cluster. And this requests. have to be either in YAML format or JSON format. And this is how an example configuration in YAML format actually looks like. So with this, we are sending a request to Kubernetes to configure a component called deployment, which is basically a template or a blueprint for creating pods.
And in this specific configuration example, we tell Kubernetes to create two replica pods for us called my app with each pod replica. having a container based on my image running inside. In addition to that, we configure what the environment variables and the port configuration of this container inside of the pod should be. And as you see, the configuration requests in Kubernetes are declarative form. So we declare what is our desired outcome from Kubernetes and Kubernetes tries to meet those requirements.
Meaning, for example, since we declare We want to replica parts of my deployment to be running in the cluster in one of those parts dies. The controller manager will see that the ease and should states now are different. The actual state is one part. Our desired state is two. So it goes to work to make sure that this desired state is recovered, automatically restarting the second replica of that part.
And this is how Kubernetes configuration works. with all of its components, be it the pods or the services or deployments, what have you. Thanks for watching the video, I hope it was helpful and if it was don't forget to like it.
If you want to be notified whenever a new video comes out then subscribe to my channel. If you have any questions, if something wasn't clear in the video, please post them in the comment section below and I will try to answer them. So thank you and see you in the next video!