WEBVTT 00:00.390 --> 00:02.100 Hello and welcome to this lecture. 00:02.100 --> 00:07.060 We start with a basic overview of the Kubernetes cluster architecture. 00:07.080 --> 00:12.980 We first look at the architecture at a high level and then we drill down into each of these components 00:13.640 --> 00:17.890 we see what their roles and responsibilities are and how they are configured. 00:17.910 --> 00:24.300 And finally, you go through a practice test where you look at an existing cluster and are asked to identify 00:24.300 --> 00:28.090 various details with respect to these components in the cluster. 00:28.170 --> 00:33.780 We're going to use an analogy of ships to understand the architecture of Kubernetes. 00:34.020 --> 00:41.130 The purpose of Kubernetes is to host your applications in the form of containers in an automated fashion 00:41.160 --> 00:48.720 so that you can easily deploy as many instances of your application as required and easily enable communication 00:48.780 --> 00:52.140 between different services within your application. 00:52.140 --> 00:57.080 So there are many things involved that work together to make this possible. 00:57.090 --> 01:00.980 So let's take a 10000 feet look at the Kubernetes architecture. 01:01.050 --> 01:02.580 We have two kinds of ships. 01:02.610 --> 01:09.300 In this example cargo ships that does the actual work of carrying containers across to sea and control 01:09.300 --> 01:13.730 ships that are responsible for monitoring and managing the cargo ships. 01:13.800 --> 01:20.010 The Kubernetes cluster consists of a set of nodes which may be physical or virtual on-premise or 01:20.010 --> 01:24.290 on cloud that host applications in the form of containers. 01:24.300 --> 01:26.090 These relate to the cargo ships. 01:26.100 --> 01:31.820 In this analogy, the worker nodes in the cluster are ships that can load containers. 01:32.100 --> 01:38.700 But somebody needs to load the containers on the ships and not just load plan how to load identify the 01:38.700 --> 01:44.430 right ships store information about the ships monitor and track the location of containers on the ships 01:44.850 --> 01:47.550 manage the whole loading process etc.. 01:47.790 --> 01:54.330 This is done by the control ships that host different offices and departments monitoring equipments 01:54.570 --> 02:01.350 communication equipments cranes for moving containers between ships etc. The control ships relate to 02:01.380 --> 02:07.510 the master node in the Kubernetes cluster the master node is responsible for managing the Kubernetes 02:07.560 --> 02:13.650 cluster storing information regarding the different nodes planning which containers cause where monitoring 02:13.650 --> 02:21.240 the notes and containers on them etc. The Master node does all of these using a set of components together 02:21.240 --> 02:24.320 known as the control plane components. 02:24.450 --> 02:27.350 We will look at each of these components now. 02:27.510 --> 02:32.990 Now there are many containers being loaded and unloaded from the ships on a daily basis. 02:33.150 --> 02:38.550 And so you need to maintain information about the different ships what container is on which ship and 02:38.550 --> 02:45.990 what time it was loaded etc. All of these are stored in a highly available key value store known as 02:46.070 --> 02:52.380 Etcd the Etcd is a database that stores information in a key-value format. 02:52.380 --> 02:58.320 We will look more into what Etcd cluster actually is what data is stored in it and how it stores the 02:58.320 --> 03:00.780 data in one of the upcoming lectures. 03:01.170 --> 03:08.220 When ships arrive you load containers on them using cranes the cranes identify the containers that need 03:08.220 --> 03:09.610 to be placed on ships. 03:09.630 --> 03:15.540 It identifies the right ship based on its size its capacity the number of containers already on the 03:15.540 --> 03:19.480 ship and any other conditions such as the destination of the ship. 03:19.650 --> 03:25.380 The type of containers it is allowed to carry etc. So those are schedulers in a Kubernetes cluster 03:25.650 --> 03:30.480 as scheduler identifies the right note to place a container on based on the containers. 03:30.510 --> 03:36.570 Resource requirements the worker nodes capacity or any other policies or constraints such as tents and 03:36.570 --> 03:39.720 tolerations or node affinity rules that are on them. 03:39.780 --> 03:45.100 We will look at these in much more detail with examples and practice tests later in this course. 03:45.150 --> 03:48.340 We have a whole section on scheduling alone. 03:48.390 --> 03:53.390 There are different offices in the dock that are assigned to special tasks or departments. 03:53.400 --> 03:59.940 For example the operations team takes care of ship handling traffic control etc. they deal with issues 03:59.940 --> 04:06.480 related to damages the routes the different ship state etc. The cargo team takes care of containers 04:06.680 --> 04:08.880 when continuous are damaged or destroyed. 04:08.880 --> 04:11.870 They make sure new containers are made available. 04:11.880 --> 04:18.170 You have these services office that takes care of the I.T. and communications between different ships. 04:18.180 --> 04:24.390 Similarly, in Kubernetes we have controllers available that take care of different areas. 04:24.390 --> 04:26.930 The node-controller takes care of nodes. 04:27.000 --> 04:29.370 They're responsible for onboarding new nodes to 04:29.400 --> 04:36.300 the cluster handling situations where nodes become unavailable or get gets destroyed and the replication 04:36.300 --> 04:42.570 controller ensures that the desired number of containers are running at all times in your replication 04:42.570 --> 04:43.170 group. 04:43.170 --> 04:49.500 So we have seen different components like the different offices the different ships the data store the 04:49.500 --> 04:50.490 cranes. 04:50.580 --> 04:53.240 But how do these communicate with each other. 04:53.250 --> 04:58.530 How does one office reach the other office and who manages them all at a high level. 04:58.590 --> 05:05.840 The kube-apiserver is the primary management component of kubernetes. The kube-api server is responsible for 05:05.930 --> 05:09.410 orchestrating all operations within the cluster. 05:09.410 --> 05:15.500 It exposes the Kubernetes API which is used by externals users to perform management operations on 05:15.500 --> 05:21.590 the cluster as well as the various controllers to monitor the state of the cluster and make the necessary 05:21.590 --> 05:26.480 changes as required and by the worker nodes to communicate with the server. 05:26.510 --> 05:29.320 Now we are working with containers here. 05:29.330 --> 05:34.970 Containers are everywhere so we need everything to be container compatible. 05:34.970 --> 05:40.910 Our applications are in the form of containers the different components that form the entire management 05:40.910 --> 05:41.780 system. 05:41.780 --> 05:45.790 On the master nodes could be hosted in the form of containers. 05:45.950 --> 05:51.050 The DNS service networking solution can all be deployed in the form of containers. 05:51.140 --> 05:56.410 So we need these software that can run containers and that's the container runtime engine. 05:56.570 --> 05:58.340 A popular one being Docker. 05:58.460 --> 06:04.610 So we need Docker or it's supported equivalent installed on all the nodes in the cluster including the 06:04.610 --> 06:05.730 master nodes. 06:05.840 --> 06:11.540 if you wish to host the control plane components as containers. Now it doesn’t always have to be Docker. 06:11.700 --> 06:16.910 Kubernetes supports other run time engines as well like ContainerD or Rocket. 06:20.080 --> 06:23.200 let's now turn our focus onto the cargo ships. 06:23.300 --> 06:25.110 Now every ship has a captain. 06:25.150 --> 06:29.910 The captain is responsible for managing all activities on these ships. 06:29.920 --> 06:35.410 The captain is responsible for liaising with the master ships starting with letting the master ship 06:35.440 --> 06:40.420 know that they are interested in joining the group receiving information about the containers to be 06:40.420 --> 06:46.540 loaded on the ship and loading the appropriate containers as required sending reports back to the master 06:46.540 --> 06:53.030 about the status of this ship and the status of the containers on the ship etc. 06:53.050 --> 06:59.710 Now the captain of the ship is the kubelet in Kubernetes. A kubelet is an agent that runs on 06:59.770 --> 07:01.590 each node in a cluster. 07:01.590 --> 07:07.150 It listens for instructions from the kube-api server and deploys or destroys containers on the nodes 07:07.210 --> 07:08.470 as required. 07:08.470 --> 07:14.890 The kube-api server periodically fetches status reports from the kubelet to monitor the state of nodes 07:15.340 --> 07:17.340 and containers on them. 07:17.340 --> 07:22.510 The kubelet was more of a captain on the ship that manages containers on the ship. But the applications 07:22.510 --> 07:26.160 running on the worker notes need to be able to communicate with each other. 07:26.170 --> 07:31.840 For example you might have a web server running in one container on one of the nodes and a database 07:31.840 --> 07:33.790 server running on another container. 07:33.790 --> 07:38.740 on another node. How would the web server reach the database server on the other node 07:38.740 --> 07:44.620 Communication between worker nodes are enabled by another component that runs on the worker node known 07:44.710 --> 07:52.270 as the Kube-proxy service. The Kube-proxy service ensures that the necessary rules are in place on the 07:52.270 --> 07:57.220 worker nodes to allow the containers running on them to reach each other. 07:57.220 --> 08:02.200 So to summarize we have master and worker nodes on the master. 08:02.200 --> 08:05.710 we have the ETCD cluster which stores information about the cluster 08:05.740 --> 08:11.200 we have the Kube scheduler that is responsible for scheduling applications or containers on Nodes 08:11.200 --> 08:16.090 We have different controllers that take care of different functions like the node control, replication, 08:16.090 --> 08:17.460 controller etc.. 08:17.470 --> 08:22.810 we have the Kube api server that is responsible for orchestrating all operations within the cluster. 08:23.440 --> 08:24.280 on the worker node. 08:24.280 --> 08:30.520 we have the kubelet that listens for instructions from the Kube-apiserver and manages containers and 08:30.520 --> 08:31.710 the kube-proxy 08:31.840 --> 08:37.270 That helps in enabling communication between services within the cluster. 08:37.270 --> 08:40.060 So that's a high level overview of the various components. 08:40.090 --> 08:43.820 We will drill down into each of these in the upcoming lectures. 08:43.870 --> 08:46.710 That's it for now and I will see you in the next lecture.