WEBVTT 00:00.770 --> 00:03.320 Hello and welcome to this lecture in this lecture. 00:03.320 --> 00:07.230 In this lecture we will talk about the Kube-API server in kubernetes. 00:07.460 --> 00:14.660 Earlier we discussed that the Kube-api server is the primary management component in kubernetes. When 00:14.660 --> 00:21.710 you run a kubectl command, the kubectl utility is infact reaching to the kube-apiserver. 00:21.710 --> 00:28.010 The kube-api server first authenticates the request and validates it. It then retrieves the data from the 00:28.010 --> 00:31.910 ETCD cluster and responds back with the requested information. 00:32.930 --> 00:35.580 You don’t really need to use the kubectl command line. 00:35.660 --> 00:42.650 Instead, you could also invoke the API directly by sending a post request like this let's look at an 00:42.650 --> 00:50.950 example of creating a pod when you do that as before the request is authenticated first and then validated. 00:51.110 --> 00:57.980 In this case, the API server creates a POD object without assigning it to a node, updates the information 00:57.980 --> 01:02.000 in the ETCD server updates the user that the POD has been created. 01:03.720 --> 01:10.170 The scheduler continuously monitors the API server and realizes that there is a new pod with no node 01:10.170 --> 01:16.500 assigned the scheduler identifies the right node to place the new POD on and communicates that back 01:16.500 --> 01:18.220 to the kube-apiserver. 01:18.480 --> 01:25.350 The API server then updates the information in the ETCD cluster. The API server then passes that information 01:25.350 --> 01:28.060 to the kubelet in appropriate worker node. 01:28.520 --> 01:34.200 The kubelet then creates the POD on the node and instructs the container runtime engine to deploy the 01:34.200 --> 01:36.000 application image. 01:36.060 --> 01:43.110 Once done, the kubelet updates the status back to the API server and the API server then updates the 01:43.110 --> 01:50.810 data back in the ETCD cluster. A similar pattern is followed every time a change is requested. 01:50.810 --> 01:56.560 The kube-apiserver is at the center of all the different tasks that needs to be performed to make a 01:56.560 --> 01:58.370 change in the cluster. 01:58.370 --> 02:04.430 To summarize, the kube-api server is responsible for Authenticating and validating requests, retrieving 02:04.430 --> 02:07.090 and updating data in ETCD data store, 02:07.130 --> 02:13.460 in fact, kube-api server is the only component that interacts directly with the etcd datastore. 02:13.460 --> 02:16.760 The other components such as the scheduler, kube-controller-manager & kubelet 02:16.760 --> 02:21.860 uses the API server to perform updates in the cluster in their respective areas. 02:23.090 --> 02:28.970 If you bootstrapped your cluster using kubeadm tool then you don't need to know this but if you are 02:28.970 --> 02:34.670 setting up the hard way, then kube-apiserver is available as a binary in the kubernetes release 02:34.670 --> 02:40.820 page. Download it and configure it to run as a service on your kubernetes master node. 02:41.120 --> 02:47.520 The kube-api server is run with a lot of parameters as you can see here. Throughout this section 02:47.630 --> 02:52.410 we are going to take a peak at how to install and configure these individual components of the kubernetes 02:52.430 --> 02:53.960 architecture. 02:53.960 --> 02:59.630 You don't have to understand all of the options right now but I think having a high level understanding 02:59.750 --> 03:05.960 on some of these now will make it easier later when we configure the whole cluster and all of its components 03:06.170 --> 03:07.730 from scratch. 03:07.730 --> 03:13.040 The kubernetes architecture consists of a lot of different components working with each other, talking 03:13.040 --> 03:19.350 to each other in many different ways so they all need to know where the other components are. 03:19.490 --> 03:24.920 There are different modes of authentication, authorization, encryption and security. And that’s why you 03:24.920 --> 03:30.590 have so many options when we go through the relevant section in the course we will pull up this file 03:30.620 --> 03:32.390 and look at the relevant options. 03:32.510 --> 03:35.850 For now we will look at a few important ones. 03:35.960 --> 03:40.700 A lot of them are certificates that are used to secure the connectivity between different components. 03:40.730 --> 03:46.070 We look at these certificates in more detail when we go through the SSL/TLS certificates lecture later 03:46.070 --> 03:47.510 in this course. 03:47.510 --> 03:51.410 There is a whole section just for it. So we will get rid of them for now. 03:51.410 --> 03:56.300 But just remember all of the various components we are going to look at in this section will have certificates 03:56.390 --> 04:02.880 associated with them. The option ETCD-servers is where you specify the location of the ETCD servers. 04:02.900 --> 04:06.290 This is how the kube-api server connects to the etcd servers. 04:06.800 --> 04:10.940 So how do you view the kube-api server options in an existing cluster 04:10.970 --> 04:13.560 It depends on how you set up your cluster. 04:13.610 --> 04:19.070 . If you set it up with kubeadm tool, kubeadm deploys the kube-api server as a pod in the kube- 04:19.070 --> 04:25.130 system namespace on the master node you can see the options within the pod definition file located at 04:25.430 --> 04:32.990 etc kubernetes manifests folder. etc kubernetes manifests folder. 04:32.990 --> 04:41.270 kube-apiserver service located at /etc/systemd/system/kube-apiserver.service.You can also see 04:41.270 --> 04:46.490 the running process and the effective options by listing the process on the master node and searching 04:46.490 --> 04:48.680 for kube-apiserver. 04:48.680 --> 04:50.300 Well that's it for this lecture.