Kubernetes - Static pods

We know that the pods are created and managed by the Api-server. Though the pods are created in the worker nodes by the kubelet running on those nodes, the details are first managed by the api-server and will ask this kubelet to create the pod. This means the management of this pod will be taken care of by the api-server. These pods are continuously managed and observed by the api-server

But there is another type of pod that is managed directly by the kubelet rather than the api-server. This means the pod created by the kubelet is managed by the kubelet by itself. Control plane is not involved in the lifecycle of the static pod. In addition to this, kubelet also tries to create a mirror pod on the kubernetes api-server for each static pod so that the static pods are visible when we list the pods.Static pods are usually used by software bootstrapping kubernetes itself. For example, kubeadm uses static pods to bring up kubernetes control plane components like api-server, controller-manager as static pods. Since the static pods are managed by the Kubelet itself, we need to create these static pods on any of the worker nodes.

kubelet can watch a directory on the host file system (configured using --pod-manifest-path argument to kubelet) or sync pod manifests from a web url periodically (configured using --manifest-url argument to kubelet). When kubeadm is bringing up the kubernetes control plane, it generates pod manifests for api-server, controller-manager in a directory which kubelet is monitoring. Then kubelet brings up these control plane components as static pods. In this article, we will see how we can create a Static pod, 

 

Create a Simple pod definition file as below,

[root@ec2-18-217-122-218 kubelet]# cat /root/staticPod/static-pod.yml 

apiVersion: v1

kind: Pod

metadata:

  name: static-pod

  labels:

    role: app

spec:

  containers:

    - name: app

      image: busybox:1.28

      ports:

        - name: app

          containerPort: 443

          protocol: TCP

Now once the pod definition file is available, we need to identify the kubelet watch directory.  Now check the static pod location where kubelet tries to read. To find this go to,

[root@ec2-18-217-122-218 kubelet]# cd /var/lib/kubelet/

[root@ec2-18-217-122-218 kubelet]# cat config.yaml | grep static

staticPodPath: /etc/kubernetes/manifests

We can see the location where kubelet reads for static pod is /etc/kubernetes/manifests

Copy your static pod file over this location and restart the kubelet as below

[root@ec2-18-217-122-218 manifests]#  systemctl restart kubelet

Now after a few seconds, if we do a kubectl get pods from the master node, we can see the mirror pod details as below,

We can see that the static nignx pod, is running.

If we try to delete the pod from the master node, it deletes but the kubelet again starts the pod as below,

kubelet periodically scans the configured directory for static pods and if there are any changes, the kubelet performs them accordingly.

Identify status pod

Since static pods are not controlled by an api-server, the controlled by Element in the pod description shows a different value.  Checking the owner reference of a static pod using kubectl describe command should indicate that such a pod is not controlled by a ReplicaSet but rather from Node/controlplane

So Static pods are introduced for running pods across all or a subset of chosen nodes. This was useful for system service components like log forwarders like fluentd , networking components like kube-proxy. Because of the limitation with the static pods like no health check ets, kubernetes came up with Daemon Sets. 

Hope this helps in understanding Static Pods