Static PODs
In this tutorial we will discuss about Static PODs in Kubernetes. Static pods are a type of pod that is not managed via Kube API Server and is directly bound to the Kubelet agent on the node.
The kubelet agent is responsible to watch each static Pod and restart it if it crashes.
The static Pods running on a node are visible on the API server but cannot be controlled by the API Server.
Real time example
For example, As we already know the Kubelet relies on the Kube API server for instructions on what PODs to load on its node, which is based on a decision made by the Kube Scheduler which was stored in the ETCD data store.
What if there was no Kube API server, Kube Scheduler and no controllers and no ETCD cluster? What if there was no master at all, there were no other nodes and only single node alone not part of any cluster?
Well, the kubelet can manage a node independently. On this node we have 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 any thing like that.
Is there anything that Kubelet can do? Can it operate as an independent node? If so who would provide the instructions required to create PODs?
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 with out 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. Place POD definition files in this directory.
The Kubelet periodically checks this directory for files, read this files and create 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.
Kubelet will delete your POD automatically when you remove a file from this directory.
Static PODs
The PODs that are created by the kubelet on its own without the interaction from the API server or rest of Kubernetes cluster components are known as Static PODs.
Remember you can only create PODs this way. You can’t create Replica Sets, Deployments or Services by placing a definition file in the designated directory.
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 we configure it? It could be any directory on the host and location of that directory is passed in to the Kubelet.service as an 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 static POD path in that file.
staticPodPath=/etc/kubernetes/manifests
Once the static PODs are created, you can view them using docker ps command.
So, why not the kubectl command as we have been so far? Remember we don’t have the rest of the Kubernetes cluster. Kubectl utility works with the Kube API Server.
Since we don’t have an API server there is no kubectl utility. So we need to use docker command.
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 PODs from different inputs.
- Through the POD definition files from the static PODs folder
- Through an HTTP API end point. (i.e., how the Kube API Server provides input to kubelet)
The Kubelet can create both kinds of PODs (Static PODs and the ones from the API Server).
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 happen?
When the kubelet creates a Static POD, if it is part of a cluster, it also creates a mirror object in the Kube API Server. What we see from the Kube API Server 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 PODs.
You can only delete them by modifying the files from the nodes manifest folder. Note that the name of the POD is automatically appended with the node name.
Why do we 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 node.