Static Pods in Kubernetes
This is the normal Kubernetes cluster components
Learn more about the Control plane components here.
Now, let’s imagine there is a Kubernetes cluster with no Schedular or Controller or even no Master Node.
There are worker nodes. On each worker node, there is kubelet running.
Now, how can we tell
kubelet to run a Pod itself?
We can do that by putting a Pod specification YAML file under
Let’s say this is the spec. We save it a YAML file put it under the manifests folder.
apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: nginx:1.18.0 ports: - containerPort: 80
kubelet will periodically check the folder and create the Pod.
We should be seeing the
nginx Pod up and running shortly.
We can customize the folder path with
--pod-manifest-path when we run
The Control plane from the Master Node is not involved in creating a static Pod.
Yet, once the
api-server is reachable, kubelet will notify a record on the
api-server as a mirror Pod record. So that we can see the pods when we do
kubectl get pods.
When is this actually useful?
Most of the time, we won’t have to create one like this. Static pods are usually used by software bootstrapping Kubernetes itself. One use is kubeadm. During the setup, kubeadm uses static pods to bring up Kubernetes control plane components like api-server, controller-manager.
This only works for the Pods and not for