WEBVTT 00:00.420 --> 00:07.700 Hello and welcome to this lecture in this lecture we discuss about static pods in Kubernetes. Earlier, 00:07.700 --> 00:14.300 in this course we talked about the Architecture and how the kubelet functions as one of the many control 00:14.300 --> 00:15.870 plane components in Kubernetes. 00:15.930 --> 00:23.120 The kubelet relies on the kube-apiserver for instructions on what PODs to load on its node, 00:23.510 --> 00:30.710 which was based on a decision made by the kube-scheduler which was stored in the ETCD datastore. 00:30.760 --> 00:38.210 What if there was no kube-apiserver, and kube-scheduler and no controllers and no ETCD cluster. 00:38.230 --> 00:40.810 What if there was no master at all. 00:40.810 --> 00:42.790 What if there were no other nodes. 00:42.790 --> 00:45.930 What if you're all alone in the sea by yourself. 00:45.970 --> 00:47.800 Not part of any cluster. 00:48.070 --> 00:52.910 Is there anything that the kubelet can do as the captain on the ship? 00:53.020 --> 00:56.170 Can it operate as an independent node? 00:56.170 --> 01:00.730 If so who would provide the instructions required to create PODs? 01:00.880 --> 01:08.140 Well, the kubelet can manage a node independently. On this ship…err..host, 01:08.140 --> 01:14.160 we have the kubelet installed. And of course we have Docker as well to run containers. 01:14.200 --> 01:19.810 There is no Kubernetes cluster. So there are no Kube API server or anything like that. 01:19.820 --> 01:27.770 The one thing that the kubelet knows to do is create PODs. But we don’t have an API server here to provide 01:27.800 --> 01:29.450 POD details. 01:29.480 --> 01:37.130 By now we know that to create a POD you need the details of the POD in a POD definition file. But how 01:37.130 --> 01:43.540 do you provide a pod definition file to the kubelet without a kube-api server? 01:43.630 --> 01:51.340 You can configure the kubelet to read the pod definition files from a directory on the server designated 01:51.340 --> 01:54.760 to store information about pods. 01:54.870 --> 02:02.370 The pods definition files in this directory the Kubelet periodically checks this directory for files 02:02.940 --> 02:06.920 reads these files and creates pods on the host. 02:06.960 --> 02:12.460 Not only does it create the pod it can ensure that the pod stays alive. 02:12.690 --> 02:17.020 If the application crashes, the kubelet attempts to restart it. 02:17.070 --> 02:22.920 If you make a change to any of the file within this directory, the kubelet recreates the pod for those 02:22.920 --> 02:25.070 changes to take effect. 02:25.200 --> 02:30.340 If you remove a file from this directory the part is deleted automatically. 02:30.570 --> 02:37.200 So these PODs that are created by the kubelet on its own without the intervention from the API server 02:37.410 --> 02:44.980 or rest of the kuberentes cluster components are known as Static PODs. Remember you can only create 02:45.040 --> 02:46.340 PODs this way. 02:46.480 --> 02:52.540 You cannot create replicasets or deployments or services by placing a definition file in the designated 02:52.540 --> 02:53.760 directory. 02:53.820 --> 03:00.760 They are all concepts part of the whole Kubernetes architecture, that requires other control plane components 03:00.760 --> 03:08.170 like the replication and deployment controllers etc. The kubelet works at a POD level and can only 03:08.200 --> 03:12.870 understand PODs. Which is why it is able to create static pods 03:12.880 --> 03:14.520 this way. 03:14.600 --> 03:17.290 So what is that designated folder 03:17.330 --> 03:19.330 and how do you configure it. 03:19.340 --> 03:25.340 It could be any directory on the host. And the location of that directory is passed in to the kubelet 03:25.340 --> 03:28.610 as a option while running the service. 03:28.610 --> 03:31.770 The option is named pod manifest path 03:31.820 --> 03:39.570 and here it is set to /etc/Kubernetes/manifests. There is also another way to configure this 03:39.830 --> 03:44.860 Instead of specifying the option directly in the kubelet.service file, 03:44.870 --> 03:51.890 you could provide a path to another config file using the config option, and define the directory path 03:52.070 --> 03:55.090 as staticPodPath in that file. 03:55.400 --> 04:02.800 Clusters setup by the kubeadmin tool uses this approach. If you are inspecting an existing cluster, you 04:02.800 --> 04:07.990 should inspect this option of the kubelet to identify the path to the directory. 04:07.990 --> 04:12.830 You will then know where to place the definition file for your static pods. 04:12.910 --> 04:18.310 So keep this in mind when you go through the labs. You should know to view and configure this option 04:18.670 --> 04:28.030 irrespective of the method used to set up the cluster first check the option pod manifest path in the 04:28.090 --> 04:34.840 Kubelet service file if it's not there then look for the config option and identify the file used as 04:34.840 --> 04:41.480 the config file and then within the config file look for these static pod path option. 04:41.500 --> 04:47.470 Either of these should give you the right path once the static ports are created. 04:47.470 --> 04:53.440 you can view them by running the Docker ps command. So why not the kubectl command as we have 04:53.440 --> 04:54.820 been doing so far. 04:54.820 --> 05:00.850 Remember we don’t have the rest of the Kubernetes cluster. Kubectl utility works with the 05:00.850 --> 05:02.190 kube-apiserver. 05:02.350 --> 05:08.880 Since we don’t have an API server now, no kubectl utility. which is why we're using the docker command. 05:08.920 --> 05:12.710 So then how does it work when the node is part of a cluster. 05:13.000 --> 05:17.510 When there is an API server requesting the Kubelet to create pods. 05:17.560 --> 05:23.940 Can the kubelet create both kinds of PODs at the same time? Well, the way the kubelet works is it can 05:23.940 --> 05:27.750 take in requests for creating parts from different inputs. 05:27.750 --> 05:32.310 The first is through the POD definition files from the static pods folder, 05:32.310 --> 05:39.540 as we just saw. The second, is through an HTTP API endpoint. And that is how the kube-apiserver provides 05:39.630 --> 05:42.150 input to kubelet. The kubelet 05:42.150 --> 05:48.210 can create both kinds of PODs – the staticpods and the ones from the api server - at the same time. 05:49.510 --> 05:49.660 Well, 05:49.660 --> 05:54.970 in that case is the API server aware of the static pods created by the kubelet? 05:55.030 --> 05:56.200 Yes it is. 05:56.200 --> 06:01.720 If you run the kubectl get pods command on the master node, the static pods will be listed as 06:01.810 --> 06:03.200 any other pod. 06:03.430 --> 06:08.520 Well how is that happening? When the kubelet creates a static pod, 06:08.590 --> 06:14.580 if it is part of a cluster, it also creates a mirror object in the kubeapi server. 06:14.820 --> 06:21.220 What you see from the kube-apiserver is just a read only mirror of the pod. You can view details 06:21.220 --> 06:25.430 about the pod but you cannot edit or delete it like the usual parts. 06:25.780 --> 06:30.860 You can only delete them by modifying the files from the nodes manifest folder. 06:30.910 --> 06:35.160 Note that the name of the part is automatically appended with the node name. 06:35.290 --> 06:41.400 In this case node01. So then why would you want to use Static PODs? 06:42.410 --> 06:48.740 Since static pods are not dependent on the Kubernetes control plane, you can use static pods to deploy 06:48.740 --> 06:55.230 the control plane components itself as pods on a node. Start by installing kubelet on all the 06:55.230 --> 06:56.270 master nodes. 06:56.520 --> 07:02.970 Then create pod definition files that uses Docker images of the various control plane components such 07:02.970 --> 07:06.200 as the api server, controller, etcd etc. 07:06.370 --> 07:12.330 Place the definition files in the designated manifests folder. And kubelet takes care of deploying 07:12.330 --> 07:16.740 the control plane components themselves as PODs on the cluster. 07:16.740 --> 07:22.560 This way you don't have to download the binaries configure services or worry about so the service is 07:22.560 --> 07:23.790 crashing. 07:23.790 --> 07:30.570 If any of these services were to crash since it's a static pod it will automatically be restarted by 07:30.570 --> 07:33.130 the kubelet. Neat and simple. 07:33.420 --> 07:37.650 That’s how the kubeadmin tool set’s up a Kubernetes cluster. 07:37.650 --> 07:43.500 Which is why when you list the pods in the kube-system namespace, you see the control plane components 07:43.590 --> 07:47.740 as PODs in a cluster setup by the kubeadmin tool. 07:47.910 --> 07:53.200 We will explore that setup in the upcoming practice test. Before I let you go, 07:53.280 --> 07:58.310 one question that I get often is about the different between Static PODs and DaemonSets. 07:59.340 --> 08:05.910 DaemonSets as we saw earlier are used to ensure one instance of an application is available on all 08:05.910 --> 08:13.140 nodes in the cluster. It is handled by a daemonset controller through the kube-api server. Whereas static 08:13.140 --> 08:19.020 pods, as we saw in this lecture, are created directly by the kubelet without any interference from the 08:19.020 --> 08:25.860 kube-api server or rest of the Kubernetes control plane components. Static pods can be used to deploy 08:25.860 --> 08:32.520 the Kubernetes control plane components itself. Both static pods and pods created by daemonsets are 08:32.520 --> 08:38.520 ignored by the kube-scheduler. The kube-scheduler has no affect on these pods. 08:38.640 --> 08:40.940 Well that’s it for this lecture. 08:41.010 --> 08:45.270 Head over to the practice test and practice working with Static Pods.