1 00:00:00,390 --> 00:00:02,100 Hello and welcome to this lecture. 2 00:00:02,100 --> 00:00:07,060 We start with a basic overview of the Kubernetes cluster architecture. 3 00:00:07,080 --> 00:00:12,980 We first look at the architecture at a high level and then we drill down into each of these components 4 00:00:13,640 --> 00:00:17,890 we see what their roles and responsibilities are and how they are configured. 5 00:00:17,910 --> 00:00:24,300 And finally, you go through a practice test where you look at an existing cluster and are asked to identify 6 00:00:24,300 --> 00:00:28,090 various details with respect to these components in the cluster. 7 00:00:28,170 --> 00:00:33,780 We're going to use an analogy of ships to understand the architecture of Kubernetes. 8 00:00:34,020 --> 00:00:41,130 The purpose of Kubernetes is to host your applications in the form of containers in an automated fashion 9 00:00:41,160 --> 00:00:48,720 so that you can easily deploy as many instances of your application as required and easily enable communication 10 00:00:48,780 --> 00:00:52,140 between different services within your application. 11 00:00:52,140 --> 00:00:57,080 So there are many things involved that work together to make this possible. 12 00:00:57,090 --> 00:01:00,980 So let's take a 10000 feet look at the Kubernetes architecture. 13 00:01:01,050 --> 00:01:02,580 We have two kinds of ships. 14 00:01:02,610 --> 00:01:09,300 In this example cargo ships that does the actual work of carrying containers across to sea and control 15 00:01:09,300 --> 00:01:13,730 ships that are responsible for monitoring and managing the cargo ships. 16 00:01:13,800 --> 00:01:20,010 The Kubernetes cluster consists of a set of nodes which may be physical or virtual on-premise or 17 00:01:20,010 --> 00:01:24,290 on cloud that host applications in the form of containers. 18 00:01:24,300 --> 00:01:26,090 These relate to the cargo ships. 19 00:01:26,100 --> 00:01:31,820 In this analogy, the worker nodes in the cluster are ships that can load containers. 20 00:01:32,100 --> 00:01:38,700 But somebody needs to load the containers on the ships and not just load plan how to load identify the 21 00:01:38,700 --> 00:01:44,430 right ships store information about the ships monitor and track the location of containers on the ships 22 00:01:44,850 --> 00:01:47,550 manage the whole loading process etc.. 23 00:01:47,790 --> 00:01:54,330 This is done by the control ships that host different offices and departments monitoring equipments 24 00:01:54,570 --> 00:02:01,350 communication equipments cranes for moving containers between ships etc. The control ships relate to 25 00:02:01,380 --> 00:02:07,510 the master node in the Kubernetes cluster the master node is responsible for managing the Kubernetes 26 00:02:07,560 --> 00:02:13,650 cluster storing information regarding the different nodes planning which containers cause where monitoring 27 00:02:13,650 --> 00:02:21,240 the notes and containers on them etc. The Master node does all of these using a set of components together 28 00:02:21,240 --> 00:02:24,320 known as the control plane components. 29 00:02:24,450 --> 00:02:27,350 We will look at each of these components now. 30 00:02:27,510 --> 00:02:32,990 Now there are many containers being loaded and unloaded from the ships on a daily basis. 31 00:02:33,150 --> 00:02:38,550 And so you need to maintain information about the different ships what container is on which ship and 32 00:02:38,550 --> 00:02:45,990 what time it was loaded etc. All of these are stored in a highly available key value store known as 33 00:02:46,070 --> 00:02:52,380 Etcd the Etcd is a database that stores information in a key-value format. 34 00:02:52,380 --> 00:02:58,320 We will look more into what Etcd cluster actually is what data is stored in it and how it stores the 35 00:02:58,320 --> 00:03:00,780 data in one of the upcoming lectures. 36 00:03:01,170 --> 00:03:08,220 When ships arrive you load containers on them using cranes the cranes identify the containers that need 37 00:03:08,220 --> 00:03:09,610 to be placed on ships. 38 00:03:09,630 --> 00:03:15,540 It identifies the right ship based on its size its capacity the number of containers already on the 39 00:03:15,540 --> 00:03:19,480 ship and any other conditions such as the destination of the ship. 40 00:03:19,650 --> 00:03:25,380 The type of containers it is allowed to carry etc. So those are schedulers in a Kubernetes cluster 41 00:03:25,650 --> 00:03:30,480 as scheduler identifies the right note to place a container on based on the containers. 42 00:03:30,510 --> 00:03:36,570 Resource requirements the worker nodes capacity or any other policies or constraints such as tents and 43 00:03:36,570 --> 00:03:39,720 tolerations or node affinity rules that are on them. 44 00:03:39,780 --> 00:03:45,100 We will look at these in much more detail with examples and practice tests later in this course. 45 00:03:45,150 --> 00:03:48,340 We have a whole section on scheduling alone. 46 00:03:48,390 --> 00:03:53,390 There are different offices in the dock that are assigned to special tasks or departments. 47 00:03:53,400 --> 00:03:59,940 For example the operations team takes care of ship handling traffic control etc. they deal with issues 48 00:03:59,940 --> 00:04:06,480 related to damages the routes the different ship state etc. The cargo team takes care of containers 49 00:04:06,680 --> 00:04:08,880 when continuous are damaged or destroyed. 50 00:04:08,880 --> 00:04:11,870 They make sure new containers are made available. 51 00:04:11,880 --> 00:04:18,170 You have these services office that takes care of the I.T. and communications between different ships. 52 00:04:18,180 --> 00:04:24,390 Similarly, in Kubernetes we have controllers available that take care of different areas. 53 00:04:24,390 --> 00:04:26,930 The node-controller takes care of nodes. 54 00:04:27,000 --> 00:04:29,370 They're responsible for onboarding new nodes to 55 00:04:29,400 --> 00:04:36,300 the cluster handling situations where nodes become unavailable or get gets destroyed and the replication 56 00:04:36,300 --> 00:04:42,570 controller ensures that the desired number of containers are running at all times in your replication 57 00:04:42,570 --> 00:04:43,170 group. 58 00:04:43,170 --> 00:04:49,500 So we have seen different components like the different offices the different ships the data store the 59 00:04:49,500 --> 00:04:50,490 cranes. 60 00:04:50,580 --> 00:04:53,240 But how do these communicate with each other. 61 00:04:53,250 --> 00:04:58,530 How does one office reach the other office and who manages them all at a high level. 62 00:04:58,590 --> 00:05:05,840 The kube-apiserver is the primary management component of kubernetes. The kube-api server is responsible for 63 00:05:05,930 --> 00:05:09,410 orchestrating all operations within the cluster. 64 00:05:09,410 --> 00:05:15,500 It exposes the Kubernetes API which is used by externals users to perform management operations on 65 00:05:15,500 --> 00:05:21,590 the cluster as well as the various controllers to monitor the state of the cluster and make the necessary 66 00:05:21,590 --> 00:05:26,480 changes as required and by the worker nodes to communicate with the server. 67 00:05:26,510 --> 00:05:29,320 Now we are working with containers here. 68 00:05:29,330 --> 00:05:34,970 Containers are everywhere so we need everything to be container compatible. 69 00:05:34,970 --> 00:05:40,910 Our applications are in the form of containers the different components that form the entire management 70 00:05:40,910 --> 00:05:41,780 system. 71 00:05:41,780 --> 00:05:45,790 On the master nodes could be hosted in the form of containers. 72 00:05:45,950 --> 00:05:51,050 The DNS service networking solution can all be deployed in the form of containers. 73 00:05:51,140 --> 00:05:56,410 So we need these software that can run containers and that's the container runtime engine. 74 00:05:56,570 --> 00:05:58,340 A popular one being Docker. 75 00:05:58,460 --> 00:06:04,610 So we need Docker or it's supported equivalent installed on all the nodes in the cluster including the 76 00:06:04,610 --> 00:06:05,730 master nodes. 77 00:06:05,840 --> 00:06:11,540 if you wish to host the control plane components as containers. Now it doesn’t always have to be Docker. 78 00:06:11,700 --> 00:06:16,910 Kubernetes supports other run time engines as well like ContainerD or Rocket. 79 00:06:20,080 --> 00:06:23,200 let's now turn our focus onto the cargo ships. 80 00:06:23,300 --> 00:06:25,110 Now every ship has a captain. 81 00:06:25,150 --> 00:06:29,910 The captain is responsible for managing all activities on these ships. 82 00:06:29,920 --> 00:06:35,410 The captain is responsible for liaising with the master ships starting with letting the master ship 83 00:06:35,440 --> 00:06:40,420 know that they are interested in joining the group receiving information about the containers to be 84 00:06:40,420 --> 00:06:46,540 loaded on the ship and loading the appropriate containers as required sending reports back to the master 85 00:06:46,540 --> 00:06:53,030 about the status of this ship and the status of the containers on the ship etc. 86 00:06:53,050 --> 00:06:59,710 Now the captain of the ship is the kubelet in Kubernetes. A kubelet is an agent that runs on 87 00:06:59,770 --> 00:07:01,590 each node in a cluster. 88 00:07:01,590 --> 00:07:07,150 It listens for instructions from the kube-api server and deploys or destroys containers on the nodes 89 00:07:07,210 --> 00:07:08,470 as required. 90 00:07:08,470 --> 00:07:14,890 The kube-api server periodically fetches status reports from the kubelet to monitor the state of nodes 91 00:07:15,340 --> 00:07:17,340 and containers on them. 92 00:07:17,340 --> 00:07:22,510 The kubelet was more of a captain on the ship that manages containers on the ship. But the applications 93 00:07:22,510 --> 00:07:26,160 running on the worker notes need to be able to communicate with each other. 94 00:07:26,170 --> 00:07:31,840 For example you might have a web server running in one container on one of the nodes and a database 95 00:07:31,840 --> 00:07:33,790 server running on another container. 96 00:07:33,790 --> 00:07:38,740 on another node. How would the web server reach the database server on the other node 97 00:07:38,740 --> 00:07:44,620 Communication between worker nodes are enabled by another component that runs on the worker node known 98 00:07:44,710 --> 00:07:52,270 as the Kube-proxy service. The Kube-proxy service ensures that the necessary rules are in place on the 99 00:07:52,270 --> 00:07:57,220 worker nodes to allow the containers running on them to reach each other. 100 00:07:57,220 --> 00:08:02,200 So to summarize we have master and worker nodes on the master. 101 00:08:02,200 --> 00:08:05,710 we have the ETCD cluster which stores information about the cluster 102 00:08:05,740 --> 00:08:11,200 we have the Kube scheduler that is responsible for scheduling applications or containers on Nodes 103 00:08:11,200 --> 00:08:16,090 We have different controllers that take care of different functions like the node control, replication, 104 00:08:16,090 --> 00:08:17,460 controller etc.. 105 00:08:17,470 --> 00:08:22,810 we have the Kube api server that is responsible for orchestrating all operations within the cluster. 106 00:08:23,440 --> 00:08:24,280 on the worker node. 107 00:08:24,280 --> 00:08:30,520 we have the kubelet that listens for instructions from the Kube-apiserver and manages containers and 108 00:08:30,520 --> 00:08:31,710 the kube-proxy 109 00:08:31,840 --> 00:08:37,270 That helps in enabling communication between services within the cluster. 110 00:08:37,270 --> 00:08:40,060 So that's a high level overview of the various components. 111 00:08:40,090 --> 00:08:43,820 We will drill down into each of these in the upcoming lectures. 112 00:08:43,870 --> 00:08:46,710 That's it for now and I will see you in the next lecture.