1 00:00:00,420 --> 00:00:07,700 Hello and welcome to this lecture in this lecture we discuss about static pods in Kubernetes. Earlier, 2 00:00:07,700 --> 00:00:14,300 in this course we talked about the Architecture and how the kubelet functions as one of the many control 3 00:00:14,300 --> 00:00:15,870 plane components in Kubernetes. 4 00:00:15,930 --> 00:00:23,120 The kubelet relies on the kube-apiserver for instructions on what PODs to load on its node, 5 00:00:23,510 --> 00:00:30,710 which was based on a decision made by the kube-scheduler which was stored in the ETCD datastore. 6 00:00:30,760 --> 00:00:38,210 What if there was no kube-apiserver, and kube-scheduler and no controllers and no ETCD cluster. 7 00:00:38,230 --> 00:00:40,810 What if there was no master at all. 8 00:00:40,810 --> 00:00:42,790 What if there were no other nodes. 9 00:00:42,790 --> 00:00:45,930 What if you're all alone in the sea by yourself. 10 00:00:45,970 --> 00:00:47,800 Not part of any cluster. 11 00:00:48,070 --> 00:00:52,910 Is there anything that the kubelet can do as the captain on the ship? 12 00:00:53,020 --> 00:00:56,170 Can it operate as an independent node? 13 00:00:56,170 --> 00:01:00,730 If so who would provide the instructions required to create PODs? 14 00:01:00,880 --> 00:01:08,140 Well, the kubelet can manage a node independently. On this ship…err..host, 15 00:01:08,140 --> 00:01:14,160 we have the kubelet installed. And of course we have Docker as well to run containers. 16 00:01:14,200 --> 00:01:19,810 There is no Kubernetes cluster. So there are no Kube API server or anything like that. 17 00:01:19,820 --> 00: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 18 00:01:27,800 --> 00:01:29,450 POD details. 19 00:01:29,480 --> 00: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 20 00:01:37,130 --> 00:01:43,540 do you provide a pod definition file to the kubelet without a kube-api server? 21 00:01:43,630 --> 00:01:51,340 You can configure the kubelet to read the pod definition files from a directory on the server designated 22 00:01:51,340 --> 00:01:54,760 to store information about pods. 23 00:01:54,870 --> 00:02:02,370 The pods definition files in this directory the Kubelet periodically checks this directory for files 24 00:02:02,940 --> 00:02:06,920 reads these files and creates pods on the host. 25 00:02:06,960 --> 00:02:12,460 Not only does it create the pod it can ensure that the pod stays alive. 26 00:02:12,690 --> 00:02:17,020 If the application crashes, the kubelet attempts to restart it. 27 00:02:17,070 --> 00:02:22,920 If you make a change to any of the file within this directory, the kubelet recreates the pod for those 28 00:02:22,920 --> 00:02:25,070 changes to take effect. 29 00:02:25,200 --> 00:02:30,340 If you remove a file from this directory the part is deleted automatically. 30 00:02:30,570 --> 00:02:37,200 So these PODs that are created by the kubelet on its own without the intervention from the API server 31 00:02:37,410 --> 00:02:44,980 or rest of the kuberentes cluster components are known as Static PODs. Remember you can only create 32 00:02:45,040 --> 00:02:46,340 PODs this way. 33 00:02:46,480 --> 00:02:52,540 You cannot create replicasets or deployments or services by placing a definition file in the designated 34 00:02:52,540 --> 00:02:53,760 directory. 35 00:02:53,820 --> 00:03:00,760 They are all concepts part of the whole Kubernetes architecture, that requires other control plane components 36 00:03:00,760 --> 00:03:08,170 like the replication and deployment controllers etc. The kubelet works at a POD level and can only 37 00:03:08,200 --> 00:03:12,870 understand PODs. Which is why it is able to create static pods 38 00:03:12,880 --> 00:03:14,520 this way. 39 00:03:14,600 --> 00:03:17,290 So what is that designated folder 40 00:03:17,330 --> 00:03:19,330 and how do you configure it. 41 00:03:19,340 --> 00:03:25,340 It could be any directory on the host. And the location of that directory is passed in to the kubelet 42 00:03:25,340 --> 00:03:28,610 as a option while running the service. 43 00:03:28,610 --> 00:03:31,770 The option is named pod manifest path 44 00:03:31,820 --> 00:03:39,570 and here it is set to /etc/Kubernetes/manifests. There is also another way to configure this 45 00:03:39,830 --> 00:03:44,860 Instead of specifying the option directly in the kubelet.service file, 46 00:03:44,870 --> 00:03:51,890 you could provide a path to another config file using the config option, and define the directory path 47 00:03:52,070 --> 00:03:55,090 as staticPodPath in that file. 48 00:03:55,400 --> 00:04:02,800 Clusters setup by the kubeadmin tool uses this approach. If you are inspecting an existing cluster, you 49 00:04:02,800 --> 00:04:07,990 should inspect this option of the kubelet to identify the path to the directory. 50 00:04:07,990 --> 00:04:12,830 You will then know where to place the definition file for your static pods. 51 00:04:12,910 --> 00:04:18,310 So keep this in mind when you go through the labs. You should know to view and configure this option 52 00:04:18,670 --> 00:04:28,030 irrespective of the method used to set up the cluster first check the option pod manifest path in the 53 00:04:28,090 --> 00:04:34,840 Kubelet service file if it's not there then look for the config option and identify the file used as 54 00:04:34,840 --> 00:04:41,480 the config file and then within the config file look for these static pod path option. 55 00:04:41,500 --> 00:04:47,470 Either of these should give you the right path once the static ports are created. 56 00:04:47,470 --> 00:04:53,440 you can view them by running the Docker ps command. So why not the kubectl command as we have 57 00:04:53,440 --> 00:04:54,820 been doing so far. 58 00:04:54,820 --> 00:05:00,850 Remember we don’t have the rest of the Kubernetes cluster. Kubectl utility works with the 59 00:05:00,850 --> 00:05:02,190 kube-apiserver. 60 00:05:02,350 --> 00:05:08,880 Since we don’t have an API server now, no kubectl utility. which is why we're using the docker command. 61 00:05:08,920 --> 00:05:12,710 So then how does it work when the node is part of a cluster. 62 00:05:13,000 --> 00:05:17,510 When there is an API server requesting the Kubelet to create pods. 63 00:05:17,560 --> 00:05:23,940 Can the kubelet create both kinds of PODs at the same time? Well, the way the kubelet works is it can 64 00:05:23,940 --> 00:05:27,750 take in requests for creating parts from different inputs. 65 00:05:27,750 --> 00:05:32,310 The first is through the POD definition files from the static pods folder, 66 00:05:32,310 --> 00:05:39,540 as we just saw. The second, is through an HTTP API endpoint. And that is how the kube-apiserver provides 67 00:05:39,630 --> 00:05:42,150 input to kubelet. The kubelet 68 00:05:42,150 --> 00:05:48,210 can create both kinds of PODs – the staticpods and the ones from the api server - at the same time. 69 00:05:49,510 --> 00:05:49,660 Well, 70 00:05:49,660 --> 00:05:54,970 in that case is the API server aware of the static pods created by the kubelet? 71 00:05:55,030 --> 00:05:56,200 Yes it is. 72 00:05:56,200 --> 00:06:01,720 If you run the kubectl get pods command on the master node, the static pods will be listed as 73 00:06:01,810 --> 00:06:03,200 any other pod. 74 00:06:03,430 --> 00:06:08,520 Well how is that happening? When the kubelet creates a static pod, 75 00:06:08,590 --> 00:06:14,580 if it is part of a cluster, it also creates a mirror object in the kubeapi server. 76 00:06:14,820 --> 00:06:21,220 What you see from the kube-apiserver is just a read only mirror of the pod. You can view details 77 00:06:21,220 --> 00:06:25,430 about the pod but you cannot edit or delete it like the usual parts. 78 00:06:25,780 --> 00:06:30,860 You can only delete them by modifying the files from the nodes manifest folder. 79 00:06:30,910 --> 00:06:35,160 Note that the name of the part is automatically appended with the node name. 80 00:06:35,290 --> 00:06:41,400 In this case node01. So then why would you want to use Static PODs? 81 00:06:42,410 --> 00:06:48,740 Since static pods are not dependent on the Kubernetes control plane, you can use static pods to deploy 82 00:06:48,740 --> 00:06:55,230 the control plane components itself as pods on a node. Start by installing kubelet on all the 83 00:06:55,230 --> 00:06:56,270 master nodes. 84 00:06:56,520 --> 00:07:02,970 Then create pod definition files that uses Docker images of the various control plane components such 85 00:07:02,970 --> 00:07:06,200 as the api server, controller, etcd etc. 86 00:07:06,370 --> 00:07:12,330 Place the definition files in the designated manifests folder. And kubelet takes care of deploying 87 00:07:12,330 --> 00:07:16,740 the control plane components themselves as PODs on the cluster. 88 00:07:16,740 --> 00:07:22,560 This way you don't have to download the binaries configure services or worry about so the service is 89 00:07:22,560 --> 00:07:23,790 crashing. 90 00:07:23,790 --> 00:07:30,570 If any of these services were to crash since it's a static pod it will automatically be restarted by 91 00:07:30,570 --> 00:07:33,130 the kubelet. Neat and simple. 92 00:07:33,420 --> 00:07:37,650 That’s how the kubeadmin tool set’s up a Kubernetes cluster. 93 00:07:37,650 --> 00:07:43,500 Which is why when you list the pods in the kube-system namespace, you see the control plane components 94 00:07:43,590 --> 00:07:47,740 as PODs in a cluster setup by the kubeadmin tool. 95 00:07:47,910 --> 00:07:53,200 We will explore that setup in the upcoming practice test. Before I let you go, 96 00:07:53,280 --> 00:07:58,310 one question that I get often is about the different between Static PODs and DaemonSets. 97 00:07:59,340 --> 00:08:05,910 DaemonSets as we saw earlier are used to ensure one instance of an application is available on all 98 00:08:05,910 --> 00:08:13,140 nodes in the cluster. It is handled by a daemonset controller through the kube-api server. Whereas static 99 00:08:13,140 --> 00:08:19,020 pods, as we saw in this lecture, are created directly by the kubelet without any interference from the 100 00:08:19,020 --> 00:08:25,860 kube-api server or rest of the Kubernetes control plane components. Static pods can be used to deploy 101 00:08:25,860 --> 00:08:32,520 the Kubernetes control plane components itself. Both static pods and pods created by daemonsets are 102 00:08:32,520 --> 00:08:38,520 ignored by the kube-scheduler. The kube-scheduler has no affect on these pods. 103 00:08:38,640 --> 00:08:40,940 Well that’s it for this lecture. 104 00:08:41,010 --> 00:08:45,270 Head over to the practice test and practice working with Static Pods.