Kubernetes Architecture explained | Kubernetes Tutorial 15

in this video we're gonna talk about basic architecture of kubernetes now kubernetes is a complete framework which is very powerful but at the same time very complex and a lot of people when they read the documentation of kubernetes they actually get overwhelmed because they read the description of how kubernetes mechanism is built and how all the processes inside of that mechanism actually work to make up the cluster and make it possible to manage and orchestrate the containers so we're gonna look at two types of notes that kubernetes operates on one is master in another one is slave and we're gonna see what is the difference between those and which role each one of them has inside of the cluster and we're going to go through the basic concepts of how kubernetes does what it does and how the cluster is self-managed and self-healing and automated and how you as a operator of the kubernetes cluster should end up having much less manual effort [Music] and we're gonna start with this basic setup of OneNote with two application pots running on it so one of the main components of kubernetes architecture are its worker servers or nodes and each node will have multiple application pots with containers running on that node and the way communities does it is using three processes that must be installed on every node that are used to schedule and manage those pots so nodes are the cluster servers that actually do the work that's why sometimes also called worker nodes so the first process that needs to run on every node is the container runtime in my example I have docker but it could be some other technology as well so because application pods have containers running inside a container runtime needs to be installed on every node but the process that actually schedules those can those pots and the containers then underneath is cubelet which is a process of kubernetes itself unlike container runtime that has interface with both container runtime and the machine the node itself because at the end of the day cubelet is responsible for taking that configuration and actually running a pod or starting a pod with a container inside and then assigning resources from that node to the container like CPU RAM and storage resources so usually kubernetes cluster is made up of multiple nodes which also must have container runtime and cubelet services installed and you can have hundreds of those worker nodes which will run other pots and containers and replicas of the existing pots like my app and database pots in this example and the way that communication between them works is using services which is sort of a load balancer that basically catches the requests directed to the pot or the application like database for example and then forwards it to the respective pot and the third process that is responsible for forwarding requests from services to pots is actually cute proxy that also must be installed on every node and queue proxy has actually intelligent forwarding logic inside that makes sure that the communication also works in a performant way with low overhead for example if an application my app replica is making a request database instead of service just randomly forwarding the request to any replica it will actually forward it to the replica that is running on the same node as the pot that initiated the request thus this way avoiding the network overhead of sending the request to another machine so to summarize to kubernetes processes cubelet and queue proxy must be installed on every kubernetes worker node along with an independent container runtime in order for kubernetes cluster to function properly but now the question is how do you interact with this cluster or do you decide on which node a new application pod or database pot should be scheduled or if replica pod dies what process actually monitors it and then reschedules it or restarts it again or when we add another server how does he own the cluster to become another node and get pods and other components created on it and the answer is all these managing processes are done by master nodes so master servers or master notes have completely different processes running inside and these are four processes that run on every master node that control the cluster state and the worker nodes as well so the first service is API server so when you as a user want to deploy a new application in a kubernetes cluster you interact with the API server using some client it could be a UI like kubernetes dashboard could be command line tool like cubelet or acuminate this API so API server is like a cluster gateway which gets the initial requests of any updates into the cluster or even the queries from the cluster and it also acts as a gatekeeper for authentication to make sure that only authenticated and authorized requests get through to the cluster that means whenever you want to schedule new pods deploy new applications create new service or any other components you have to talk to the API server on the master node and the API server then validate your request and if everything is fine then it will forward your request to other processes in order to schedule the pod or create this component that you requested and also if you want to query the status of your deployment or the cluster health etc you make a request of the API server and it gives you the response which is good for security because you just have one entry point into the cluster another master process is a scheduler so as I mentioned if you send an API server a request to schedule a new pod API server after it's validates your request will actually hand it over to the scheduler in order to start the application pod on one of the worker nodes and of course instead of just randomly assigning to any node schedule has this whole intelligent way of deciding on which specific worker node the next pod will be scheduled or next component will be scheduled so first it will look at your request and see how much resources the application that you want to schedule will need how much CPU how much RAM and then it's gonna look at and it's going to go through the worker notes and see the available resources on each one of them and if it sees that one note is the least busy or has the most resources available it will schedule the new pod on that note an important point here is that scheduler just decides on which note a new pod will be scheduled the process that actually does the scheduling that actually starts that pod with a container is the cubelet so it gets the request from the scheduler and execute the request on that note the next component is controller manager which is another crucial component because what happens when pods die on any note there must be a way to detect that notes died and then reschedule those pods as soon as possible so what controller manager does is detect state changes like crashing of pods for example so when pods die controller manager detects that and tries to recover the cluster state as soon as possible and for that it makes a request to the scheduler to reschedule those dead parts in the same cycle happens here where the scheduler decides based on the resource calculation which worker notes should restart those pots again and makes requests so the corresponding cubelets on those worker notes to actually restart the pods and finally the last master process is set CD which is a key value store of a cluster state you can think of it as a cluster brain actually which means that every change in the cluster for example when a new pod gets scheduled when a pod dies all of these changes get saved or updated into this key value store of Ed CD and the reason why at CD store is a cluster brain is because all of these mechanism with scheduler controller manager etc works because of its data so for example how to scheduler know what resources are available on on each worker node or how does controller manager know that a cluster state changed in some way for example pots diet or that cubelet restarted new pots upon the request of a scheduler or when you make a query request to API server about the cluster health or for example your application deployment state where as API server get all this state information from so all of this information is stored in its D cluster what is not stored in its D key value store is the actual application data for example if you have a database application running inside of the cluster the data will be stored somewhere else not in the ED CD this is just a cluster state information which is used for master processes to communicate with them work processes and vice versa so now you probably already see that master processes are absolutely crucial for the cluster operation especially the H CD store which contains some data must be reliably stored or replicated so in practice communities cluster is usually made up of multiple masters where each master node runs its master processes where of course the API server is load balanced and the Etsy store forms a distributed storage across all the master notes so now that we saw what processes run on worker notes and master notes let's actually have a look at a realistic example of a cluster setup so in a very small cluster you'd probably have two master notes and three worker notes also to note here the hardware resources of master and note servers actually differ master processes are more important but they actually have less load of work so they need less resources like CPU RAM and storage whereas the worker nodes do the actual job of running those thoughts with containers inside therefore they need more resources and as your application complexity and its demand of resources increases you may actually add more master and note servers to your cluster and thus forming a more powerful and robust cluster to meet your application resource requirements so in an existing kubernetes cluster you can actually add new master or node servers pretty easily so if you want to add a master server you just get a new bear server you install all the master processes on it and edit to the communities cluster same way if you need to worker nodes you get their servers you install all the worker node processes like container runtime cubelet and key proxy on it and add it to the Covenant is cluster that's it and this way you can infinitely increase the power and resources of your communities cluster is a replication complexity and it's resource demand increases thanks for watching the video I hope it was helpful and if it was don't forget to like it this is a video series so I will create a new one every week so 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

Channel: TechWorld with Nana

Views: 238,755

Keywords: what is kubernetes, kubernetes explained, what is kubernetes for dummies, kubernetes tutorial for beginners, kubernetes architecture explained, kubernetes explained simply, kubernetes for dummies, kubernetes architecture, kubernetes basic concepts, k8s explained, kodekloud, kubernetes components architecture, kubernetes architecture made easy, kubernetes architecture tutorial, kubernetes architecture deep dive, kubernetes architecture edureka, techworld with nana, k8s

Id: umXEmn3cMWY

Length: 13min 7sec (787 seconds)

Published: Thu Jan 23 2020