Static pods in Kubernetes

A collection of technical articles and blogs published or curated by Google Cloud Developer Advocates. The views expressed are those of the authors and don't necessarily reflect those of Google.

As we already know, a pod is the smallest deployable unit that can be created and managed. Typically, pods are managed by controllers such as Deployments, ReplicaSets, and StatefulSets, which handle the lifecycle of pods according to the desired state defined by the user. However, there are scenarios where you might want to create and manage pods directly on a specific node without involving these higher-level abstractions. This is where static pods come into play.

Image by Author

Static pods are managed directly by the kubelet on a specific node and are not part of the Kubernetes API server’s management. They are defined in the node’s filesystem and are useful in situations where you need to ensure that certain critical pods are always running on specific nodes.

How Static Pods Work?¶

Static pods are created and managed by the kubelet rather than the Kubernetes API server. The kubelet watches the specified directory on the node’s filesystem for static pod manifests (YAML files). When it detects a new pod manifest, it creates the pod and starts the containers defined within it. The kubelet is responsible for monitoring and restarting the static pod if it crashes.

Creating Static Pods¶

To create a static pod, you need to place a pod manifest file in a specific directory on the node. By default, this directory is /etc/kubernetes/manifests, but it can be configured differently depending on your kubelet setup. Here’s an example of a simple static pod manifest file:

apiVersion: v1
kind: Pod
metadata:
  name: static-webserver
  labels:
    app: webserver
spec:
  containers:
  - name: webserver
    image: nginx:latest
    ports:
    - containerPort: 80

Save this file as static-webserver.yaml and place it in the /etc/kubernetes/manifests directory on the node. The kubelet will automatically detect this file and create the pod.

Scenarios Where Static Pods Are Useful¶

1. Bootstrapping a Kubernetes Cluster¶

Static pods are often used during the initial bootstrapping of a Kubernetes cluster. For instance, the control plane components such as kube-apiserver, kube-scheduler, and kube-controller-manager are usually deployed as static pods to ensure they are always running on the master nodes.

2. Running Critical System Components¶

Certain critical system components that need to be running before the Kubernetes API server is fully operational can be deployed as static pods. This ensures that these components are always available, even if the API server is down.

3. Custom Node-Level Services¶

If you have custom services that need to run on specific nodes and should not be managed by the Kubernetes scheduler, static pods are an ideal solution. For example, monitoring agents, logging agents, or node-specific daemons can be deployed as static pods.

4. Ensuring High Availability¶

Static pods can be used to ensure high availability of essential services by running them on specific nodes. This is particularly useful in edge computing scenarios where certain services need to be guaranteed to run on remote or isolated nodes.

Example: Monitoring Agent as a Static Pod¶

Consider a scenario where you need to run a monitoring agent on each node in your Kubernetes cluster to collect and send metrics to a central monitoring system. Using static pods is a straightforward and reliable way to achieve this.

Step-by-Step Example¶

Create the Pod Manifest

apiVersion: v1
kind: Pod
metadata:
  name: node-monitor-agent
  labels:
    app: monitor-agent
spec:
  containers:
  - name: monitor-agent
    image: monitoring-agent:latest
    volumeMounts:
    - name: host-root
      mountPath: /host
      readOnly: true
  volumes:
  - name: host-root
    hostPath:
      path: /
      type: Directory

Save the Manifest File: Save the above manifest as node-monitor-agent.yaml.
Deploy the Static Pod: Place the node-monitor-agent.yaml file in the /etc/kubernetes/manifests directory on each node.

The kubelet on each node will detect the manifest file and create the monitoring agent pod, ensuring that the agent runs on every node in the cluster.

Conclusion¶

By bypassing the Kubernetes API server, they ensure that vital components are always available, even during API server outages. Understanding and leveraging static pods can significantly enhance the reliability and availability of your Kubernetes deployments.

Whether you are bootstrapping a cluster, running node-specific services, or ensuring high availability, static pods offer a simple yet powerful tool to achieve your goals

If you’ve learned a new thing today then I deserve few claps and a slap on that follow button

The kube guy

. Also share it with your friends and colleagues

Last published 2 days ago

A collection of technical articles and blogs published or curated by Google Cloud Developer Advocates. The views expressed are those of the authors and don't necessarily reflect those of Google.

I'll help you sail through the ocean of Kubernetes with minimal efforts

More from The kube guy and Google Cloud - Community¶

Recommended from Medium¶

[

See more recommendations

](https://medium.com/?source=post_page---read_next_recirc--703357901d7d---------------------------------------)