Static Pods in Kubernetes

Static Pods are managed directly by the Kubelet daemon on a specific node, without the API server observing them. Unlike Pods that are managed by the control plane (for example, a Deployment); instead, the Kubelet watches each static Pod (and restarts it if it fails).

The Kubelet relies on the Kube API Server 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.

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 pod definition files in the directory the Kubelet periodically checks the directory for files reads the 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 files within the directory, the Kubelet recreates the pod for those changes to take effect. If you remove a file from the directory the pod is deleted automatically. So, these pods that are created by the Kubelet on their own without the intervention from the API Server or the rest of the Kubernetes cluster components are known as static pods.

You can only create a pod 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 cluster plan components like the replication and deployment controller etc. The Kubelet works at a pod level.

What is that designated folder and how do you configure it?

It could be any directory on the host. And the location of the directory is passed into the Kubelet as an option while running the service. The option is named pod-manifest-path = etc/kubernetes/manifests.

View Kubelet option.

 ps -aux | grep kubelet
root       975  3.5  4.9 1939924 101844 ?      Ssl  04:00   6:57 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --network-plugin=cni
root      3977  9.9 16.3 1096280 332692 ?      Ssl  04:00  19:24 kube-apiserver --advertise-address= --allow-privileged=true --authorization-mode=Node,RBAC --client-ca-file=/etc/kubernetes/pki/ca.crt --enable-admission-plugins=NodeRestriction --enable-bootstrap-token-auth=true --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key --etcd-servers= --insecure-port=0 --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt --proxy-client-key-file=/etc/kubernetes/pki/front-proxy-client.key --requestheader-allowed-names=front-proxy-client --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=6443 --service-account-key-file=/etc/kubernetes/pki/ --service-cluster-ip-range= --tls-cert-file=/etc/kubernetes/pki/apiserver.crt --tls-private-key-file=/etc/kubernetes/pki/apiserver.key
vagrant  18015  0.0  0.0  14864  1024 pts/0    S+   07:16   0:00 grep --color=auto kubelet
$ cat config.yaml 
    enabled: false
    cacheTTL: 0s
    enabled: true
    clientCAFile: /etc/kubernetes/pki/ca.crt
  mode: Webhook
    cacheAuthorizedTTL: 0s
    cacheUnauthorizedTTL: 0s
cgroupDriver: systemd
clusterDomain: cluster.local
cpuManagerReconcilePeriod: 0s
evictionPressureTransitionPeriod: 0s
fileCheckFrequency: 0s
healthzPort: 10248
httpCheckFrequency: 0s
imageMinimumGCAge: 0s
kind: KubeletConfiguration
logging: {}
nodeStatusReportFrequency: 0s
nodeStatusUpdateFrequency: 0s
resolvConf: /run/systemd/resolve/resolv.conf
rotateCertificates: true
runtimeRequestTimeout: 0s
staticPodPath: /etc/kubernetes/manifests
streamingConnectionIdleTimeout: 0s
syncFrequency: 0s
volumeStatsAggPeriod: 0s

staticPodPath: /etc/kubernetes/manifests

The way the kubelet works is it can take in requests for creating pods from different inputs.

  1. the pod definition file in the staticPodPath folder.
  2. HTTP API endpoint. That is how the Kube API Server provides input ot kubelet.

Kubelet can create both kinds of Pods. The static pods and the ones from the Kube API Server at the same time, and if the pod is created by static pods, the Kube API server aware of the static pods create by Kubelet. So you can use kubectl get pods the command in the master node. But you can not delete the pod. You can only delete or modify pods from the staticPodPath in the node.

So, why would you want to use Static pods?

One use-case is control plane components. You almost never have to deal with static pods. Static pods are usually used by software bootstrapping Kubernetes itself. 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.

$ kubectl get pods -n kube-system
NAME                                 READY   STATUS    RESTARTS   AGE
coredns-f9fd979d6-wtk5k              1/1     Running   4          21d
coredns-f9fd979d6-x5zxv              1/1     Running   4          21d
etcd-kubemaster                      1/1     Running   4          21d
fluentd-elasticsearch-2mmgt          1/1     Running   0          18h
fluentd-elasticsearch-blvmc          1/1     Running   0          18h
fluentd-elasticsearch-cgn9r          1/1     Running   0          18h
kube-apiserver-kubemaster            1/1     Running   4          21d
kube-controller-manager-kubemaster   1/1     Running   19         21d
kube-proxy-jnf5q                     1/1     Running   4          21d
kube-proxy-m9krm                     1/1     Running   4          21d
kube-proxy-zfbsh                     1/1     Running   4          21d
kube-scheduler-kubemaster            1/1     Running   17         21d
weave-net-g4l7r                      2/2     Running   12         21d
weave-net-skdlq                      2/2     Running   13         21d
weave-net-xg67h                      2/2     Running   13         21d
Created by the kubeletCreated by Kube-API Server
Deploy Control Plane Components as Static podsDeploy Monitoring Agents, Logging Agents on nodes
Ignored by the Kube SchedulerIgnored by the Kube Scheduler
Static pods vs DaemonSets

Leave a Reply

Your email address will not be published.