Hello and welcome to this lecture in this lecture we discuss about static pods in Kubernetes. Earlier,
in this course we talked about the Architecture and how the kubelet functions as one of the many control
plane components in Kubernetes.
The kubelet relies on the kube-apiserver for instructions on what PODs to load on its node,
which was based on a decision made by the kube-scheduler which was stored in the ETCD datastore.
What if there was no kube-apiserver, and kube-scheduler and no controllers and no ETCD cluster.
What if there was no master at all.
What if there were no other nodes.
What if you're all alone in the sea by yourself.
Not part of any cluster.
Is there anything that the kubelet can do as the captain on the ship?
Can it operate as an independent node?
If so who would provide the instructions required to create PODs?
Well, the kubelet can manage a node independently. On this ship…err..host,
we have the kubelet installed. And of course we have Docker as well to run containers.
There is no Kubernetes cluster. So there are no Kube API server or anything like that.
The one thing that the kubelet knows to do is create PODs. But we don’t have an API server here to provide
POD details.
By now we know that to create a POD you need the details of the POD in a POD definition file. But how
do you provide a pod definition file to the kubelet without a kube-api server?
You can configure the kubelet to read the pod definition files from a directory on the server designated
to store information about pods.
The pods definition files in this directory the Kubelet periodically checks this directory for files
reads these files and creates pods on the host.
Not only does it create the pod it can ensure that the pod stays alive.
If the application crashes, the kubelet attempts to restart it.
If you make a change to any of the file within this directory, the kubelet recreates the pod for those
changes to take effect.
If you remove a file from this directory the part is deleted automatically.
So these PODs that are created by the kubelet on its own without the intervention from the API server
or rest of the kuberentes cluster components are known as Static PODs. Remember you can only create
PODs this way.
You cannot create replicasets or deployments or services by placing a definition file in the designated
directory.
They are all concepts part of the whole Kubernetes architecture, that requires other control plane components
like the replication and deployment controllers etc. The kubelet works at a POD level and can only
understand PODs. Which is why it is able to create static pods
this way.
So what is that designated folder
and how do you configure it.
It could be any directory on the host. And the location of that directory is passed in to the kubelet
as a option while running the service.
The option is named pod manifest path
and here it is set to /etc/Kubernetes/manifests. There is also another way to configure this
Instead of specifying the option directly in the kubelet.service file,
you could provide a path to another config file using the config option, and define the directory path
as staticPodPath in that file.
Clusters setup by the kubeadmin tool uses this approach. If you are inspecting an existing cluster, you
should inspect this option of the kubelet to identify the path to the directory.
You will then know where to place the definition file for your static pods.
So keep this in mind when you go through the labs. You should know to view and configure this option
irrespective of the method used to set up the cluster first check the option pod manifest path in the
Kubelet service file if it's not there then look for the config option and identify the file used as
the config file and then within the config file look for these static pod path option.
Either of these should give you the right path once the static ports are created.
you can view them by running the Docker ps command. So why not the kubectl command as we have
been doing so far.
Remember we don’t have the rest of the Kubernetes cluster. Kubectl utility works with the
kube-apiserver.
Since we don’t have an API server now, no kubectl utility. which is why we're using the docker command.
So then how does it work when the node is part of a cluster.
When there is an API server requesting the Kubelet to create pods.
Can the kubelet create both kinds of PODs at the same time? Well, the way the kubelet works is it can
take in requests for creating parts from different inputs.
The first is through the POD definition files from the static pods folder,
as we just saw. The second, is through an HTTP API endpoint. And that is how the kube-apiserver provides
input to kubelet. The kubelet
can create both kinds of PODs – the staticpods and the ones from the api server - at the same time.
Well,
in that case is the API server aware of the static pods created by the kubelet?
Yes it is.
If you run the kubectl get pods command on the master node, the static pods will be listed as
any other pod.
Well how is that happening? When the kubelet creates a static pod,
if it is part of a cluster, it also creates a mirror object in the kubeapi server.
What you see from the kube-apiserver is just a read only mirror of the pod. You can view details
about the pod but you cannot edit or delete it like the usual parts.
You can only delete them by modifying the files from the nodes manifest folder.
Note that the name of the part is automatically appended with the node name.
In this case node01. So then why would you want to use Static PODs?
Since static pods are not dependent on the Kubernetes control plane, you can use static pods to deploy
the control plane components itself as pods on a node. Start by installing kubelet on all the
master nodes.
Then create pod definition files that uses Docker images of the various control plane components such
as the api server, controller, etcd etc.
Place the definition files in the designated manifests folder. And kubelet takes care of deploying
the control plane components themselves as PODs on the cluster.
This way you don't have to download the binaries configure services or worry about so the service is
crashing.
If any of these services were to crash since it's a static pod it will automatically be restarted by
the kubelet. Neat and simple.
That’s how the kubeadmin tool set’s up a Kubernetes cluster.
Which is why when you list the pods in the kube-system namespace, you see the control plane components
as PODs in a cluster setup by the kubeadmin tool.
We will explore that setup in the upcoming practice test. Before I let you go,
one question that I get often is about the different between Static PODs and DaemonSets.
DaemonSets as we saw earlier are used to ensure one instance of an application is available on all
nodes in the cluster. It is handled by a daemonset controller through the kube-api server. Whereas static
pods, as we saw in this lecture, are created directly by the kubelet without any interference from the
kube-api server or rest of the Kubernetes control plane components. Static pods can be used to deploy
the Kubernetes control plane components itself. Both static pods and pods created by daemonsets are
ignored by the kube-scheduler. The kube-scheduler has no affect on these pods.
Well that’s it for this lecture.
Head over to the practice test and practice working with Static Pods.