Understanding Kubernetes Init Container&Static Pod— A Beginner’s Guide

Why do we need Static Pods?

Find Complete mind map of A Beginner’s Guide to Kubernetes

In this beginner-friendly guide, we will explore the concept of static pods, init container, their significance compared to regular pods, how they work, their key features, and provide an example to solidify your understanding.

Check out “Understanding Kubernetes — A Beginner’s Guide” for the comprehensive series🚀

What is Static Pods?

In a Kubernetes cluster, pods are the smallest and simplest units that can be deployed and managed.

Typically, pods are created and managed by the Kubernetes API server, which is part of the control plane.

However, there is another type of pod called “Static Pods” that are managed directly by the kubelet on a node, without the involvement of the API server.

for more details, please refer this article:

Init Containers

Init containers are special containers that run and complete before the main application containers start in a pod.

They are used for performing setup tasks, such as data population, configuration, or pre-processing, before the actual application containers start running.

Init containers are defined in the spec section of a pod and are executed in the order they are defined.

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-init-containers
spec:
  initContainers:
  - name: init-service
    image: busybox
    command: ["sh", "-c", "echo waiting for service; sleep 4"]
  - name: init-database
    image: busybox
    command: ["sh", "-c", "echo waiting for database; sleep 4"]
  containers:
  - name: app-container
    image: nginx

In this example, the pod pod-with-init-containers has two init containers: init-service and init-database.

These init containers will run and complete before the app-container starts running, allowing them to perform any necessary setup tasks before the main application container starts processing.

Pod Lifecycle and Terminating Pods

Pods in Kubernetes go through different lifecycle phases, including “waiting”, “running”, and “terminated”.

When you delete a pod or it gets terminated, it can happen due to various reasons such as manual deletion, node failure, or lack of resources. Here’s what happens during pod termination:

1. Grace Period Timer: When you delete a pod using kubectl delete pod <name>, the API server sets a grace period timer (default is 30 seconds) before the pod is terminated. During this time, the pod's status is changed to "Terminating".
2. SIGTERM Signal: The kubelet on the node where the pod is running sends a SIGTERM signal to the containers in the pod, allowing them to gracefully terminate and perform cleanup tasks.
3. Cleanup: If the containers exit before the grace period timer expires, the pod information is removed from the API server’s storage (etcd).
4. Force Termination: However, if the containers do not exit within the grace period, the kubelet sends a SIGKILL signal, forcefully terminating the containers.
5. API Server Update: Finally, the API server updates the storage to reflect the terminated state of the pod.

Alternatively, you can also forcefully delete a pod using kubectl delete pod <name> --grace-period=0 --force, which directly sends a SIGKILL signal to terminate the containers without waiting for the grace period.

Understanding the pod lifecycle and how pods are terminated in Kubernetes is important for managing pods effectively and ensuring smooth application deployments and updates.

🔔 Stay tuned or subscribe to my series: “Understanding Kubernetes — A Beginner’s Guide” to explore everything about Kubernetes. 🚀

➕Join the Medium Membership Program to support my work and connect with other writers.

📝 Have questions or suggestions? Leave a comment or message me through Medium. Let’s connect!

Thank you for your support! 🌟