1 00:00:00,001 --> 00:00:02,567 [No Audio] 2 00:00:02,567 --> 00:00:05,567 From a bird's eye view, the architecture of 3 00:00:05,567 --> 00:00:08,167 Kubernetes cluster would look pretty simple. 4 00:00:08,367 --> 00:00:13,567 We have two types of instances, Master and Nodes. 5 00:00:14,001 --> 00:00:16,501 They both run Kubernetes, but serve different 6 00:00:16,501 --> 00:00:19,867 purposes just like manager and worker of Swarm. 7 00:00:20,934 --> 00:00:24,934 Let's have a deeper look inside Master. Master acts 8 00:00:24,967 --> 00:00:27,067 as a controlling node and while working with 9 00:00:27,067 --> 00:00:29,601 Kubernetes, we communicate with Master for the 10 00:00:29,601 --> 00:00:33,234 most part. It runs a set of applications, which 11 00:00:33,234 --> 00:00:36,834 include kube-apiserver, which serves all of the 12 00:00:36,834 --> 00:00:39,934 REST requests provided by user and obtains 13 00:00:39,934 --> 00:00:43,334 responses from other nodes. You can consider it as 14 00:00:43,334 --> 00:00:45,801 a central serving unit or front end of the 15 00:00:45,801 --> 00:00:49,167 cluster. Then we have kube-controllermanager, 16 00:00:49,334 --> 00:00:52,634 which serves as a parent or managing process for a 17 00:00:52,634 --> 00:00:55,534 number of controller processes. These controller 18 00:00:55,534 --> 00:00:58,734 processes manage the controller objects like 19 00:00:58,734 --> 00:01:01,367 ReplicaSet controller, or deployment controller, 20 00:01:01,634 --> 00:01:05,467 which we will study soon enough. Next, we have 21 00:01:05,467 --> 00:01:08,934 kube-scheduler, which schedules our container 22 00:01:08,934 --> 00:01:13,034 under a supervisory sandbox environment called pod. 23 00:01:13,801 --> 00:01:16,234 kube-scheduler also decides which of the 24 00:01:16,234 --> 00:01:19,601 nodes will be serving which set of containers. 25 00:01:19,601 --> 00:01:22,967 The API requests from kube-controllermanager 26 00:01:22,967 --> 00:01:26,901 and kube-scheduler are served by kube-apiserver. 27 00:01:27,467 --> 00:01:30,867 Finally, we have etcd, which is the 28 00:01:30,867 --> 00:01:34,801 distributed key value data store. etcd stores the 29 00:01:34,801 --> 00:01:37,767 data obtained from all other components in key 30 00:01:37,767 --> 00:01:40,634 value pairs. This may include our cluster 31 00:01:40,634 --> 00:01:44,067 configuration, input desired state, actual 32 00:01:44,067 --> 00:01:47,767 cluster state, event logs, object details, 33 00:01:47,901 --> 00:01:52,534 anything and everything. etcd only communicates 34 00:01:52,534 --> 00:01:56,501 with kube-apiserver for security reasons. So in a 35 00:01:56,501 --> 00:01:59,067 nutshell, kube-controllermanager controls 36 00:01:59,101 --> 00:02:02,367 objects, kube-scheduler schedules containers and 37 00:02:02,367 --> 00:02:05,767 their API's are served by kube-apiserver, which 38 00:02:05,767 --> 00:02:08,967 stores all of their data as a key value pair in 39 00:02:08,967 --> 00:02:12,633 etcd and fetches the data from the same place as well. 40 00:02:12,633 --> 00:02:15,167 This simple yet robust architecture of 41 00:02:15,167 --> 00:02:19,701 Master is one of the reasons for thriving success of Kubernetes. 42 00:02:19,701 --> 00:02:22,434 Now let's talk about nodes. 43 00:02:22,534 --> 00:02:25,867 They're pretty simple compared to Master, they only run 44 00:02:25,867 --> 00:02:30,434 two components to be precise. One is Mr. Talk talk, 45 00:02:30,434 --> 00:02:36,267 and one is Mr. Do do. kubelet is Mr. Do do as 46 00:02:36,267 --> 00:02:38,934 it performs the actions suggested by Master 47 00:02:38,934 --> 00:02:42,067 components like kube scheduler, apiserver, 48 00:02:42,067 --> 00:02:46,001 or controllermanager. Master and nodes are virtually 49 00:02:46,001 --> 00:02:48,634 or physically different machines, which means 50 00:02:48,634 --> 00:02:52,434 kubelet acts as supervisory process on nodes to 51 00:02:52,434 --> 00:02:56,734 allocate resources and create containers or pod processes. 52 00:02:56,901 --> 00:03:00,367 kube-proxy is Mr. Talk talk. It manages 53 00:03:00,367 --> 00:03:03,534 nodes communication with other nodes, Master 54 00:03:03,534 --> 00:03:05,801 and the world outside the cluster. 55 00:03:05,801 --> 00:03:08,434 [No Audio] 56 00:03:08,434 --> 00:03:12,201 In regular case, it is kube-apiserver of Master, 57 00:03:12,201 --> 00:03:15,234 which talks to kube-proxy of the node. 58 00:03:15,234 --> 00:03:18,234 So kube-apiserver gets data 59 00:03:18,234 --> 00:03:21,634 from etcd, it gets requests from controllermanager 60 00:03:21,634 --> 00:03:25,701 and scheduler and passes it to the node via kube-proxy. 61 00:03:25,701 --> 00:03:28,301 Whereas kube-proxy passes it to the 62 00:03:28,301 --> 00:03:31,667 kubelet, which in return provides the response to 63 00:03:31,667 --> 00:03:34,967 these requests, which are again passed to Master 64 00:03:35,067 --> 00:03:38,067 by a proxy and stored on etcd. 65 00:03:38,067 --> 00:03:41,267 [No Audio] 66 00:03:41,267 --> 00:03:43,334 But if the cluster is hosted on 67 00:03:43,334 --> 00:03:46,101 Kubernetes supported Cloud platform, 68 00:03:46,401 --> 00:03:49,734 kube-controllermanager talks to kube-proxy via 69 00:03:49,734 --> 00:03:53,134 Cloud VPC or other such relevant infrastructure, 70 00:03:53,134 --> 00:03:57,367 since it has a component called Cloud controller manager. 71 00:03:58,201 --> 00:04:01,567 Now let's focus on how we as users 72 00:04:01,567 --> 00:04:05,634 interact with Kubernetes. Users talk to the Master 73 00:04:05,634 --> 00:04:09,467 via commands. Let's say we command Master to 74 00:04:09,467 --> 00:04:13,067 create an object, Master passes this instruction as 75 00:04:13,067 --> 00:04:17,601 an API Request. Once kubelet performs its request, 76 00:04:17,601 --> 00:04:20,801 it returns the state of the node as a response, 77 00:04:20,834 --> 00:04:24,733 which Master stores in its etcd and pass it to us. 78 00:04:25,000 --> 00:04:28,000 Objects can be of multiple types, such as 79 00:04:28,000 --> 00:04:34,001 Workloads, Config objects, Connectivity objects, or Storage objects. 80 00:04:34,967 --> 00:04:37,901 Whereas states are of two types, 81 00:04:37,901 --> 00:04:40,801 desired state and current state. 82 00:04:40,801 --> 00:04:44,667 Kubernetes always keeps on checking if the desired state and 83 00:04:44,667 --> 00:04:46,434 current state match. 84 00:04:47,367 --> 00:04:51,234 If they don't match, Kubernetes tries its best to 85 00:04:51,234 --> 00:04:54,801 make sure that they do. And if they do match, 86 00:04:54,801 --> 00:04:58,067 it keeps on checking again and again to make sure 87 00:04:58,067 --> 00:05:02,167 this harmony isn't affected. This endless loop is 88 00:05:02,167 --> 00:05:05,134 called Reconciliation Loop which makes sure that 89 00:05:05,134 --> 00:05:09,967 our cluster is in the most desired state as much as possible. 90 00:05:10,534 --> 00:05:13,001 All in all, this is how Kubernetes 91 00:05:13,001 --> 00:05:16,734 infrastructure functions. Next, we will go through 92 00:05:16,734 --> 00:05:20,267 the objects of Kubernetes and learn how to use them. 93 00:05:20,267 --> 00:05:23,201 And while we do so, you will get a broader 94 00:05:23,201 --> 00:05:26,867 sense and deeper idea of how this infrastructure 95 00:05:26,867 --> 00:05:30,301 is used while creating and using objects.