Understanding Kubernetes Pods: Concepts, Usage Patterns, and Lifecycle

A pod is the smallest deployable unit in Kubernetes, consisting of one or more containers that share the same network and storage namespaces and are scheduled as a single entity.

Pods are required because running multiple tightly coupled processes in a single container violates the container principle of one process per container, leading to management and logging complexities; pods provide a higher‑level abstraction to group related containers.

The pause container is a minimal container that holds the shared namespaces for the pod, allowing other containers in the pod to share network, IPC, and PID namespaces.

When a process runs in Linux, it inherits the parent’s namespaces; using unshare or setns you can create or join new namespaces, which is how the pause container implements namespace sharing.

sudo unshare --pid --uts --ipc --mount -f chroot rootfs /bin/sh

Example commands to create a pause container and attach other containers to its namespaces:

## First run a pause container
docker run -d --name pause -p 8880:80 --ipc=shareable gcr.io/google_containers/pause-amd64:3.0

## Create an nginx container and join its network, IPC and PID namespaces
cat <
> nginx.conf
error_log stderr;
events { worker_connections  1024; }
http {
    access_log /dev/stdout combined;
    server {
        listen 80 default_server;
        server_name example.com www.example.com;
        location / {
            proxy_pass http://127.0.0.1:2368;
        }
    }
}
EOF

docker run -d --name nginx -v `pwd`/nginx.conf:/etc/nginx/nginx.conf \
    --net=container:pause --ipc=container:pause --pid=container:pause nginx

## Run a ghost container and join the same namespaces
docker run -d --name ghost --net=container:pause --ipc=container:pause --pid=container:pause ghost

Inside the ghost container, ps shows the processes from pause, nginx, and ghost, demonstrating shared namespaces.

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0   1032     4 ?        Ss   10:06   0:00 /pause
root         8  0.0  0.1   8864  3120 ?        Ss   10:15   0:00 nginx: master process nginx -g daemon off;
101         38  0.0  0.1   9312  3088 ?        S    10:15   0:00 nginx: worker process
node        48  0.3  6.9 969996 142296 ?       Ssl  10:18   0:09 node current/index.js

Pods can be used in two main ways: (1) a pod containing a single container, acting as a wrapper; (2) a pod containing multiple containers that tightly share resources, such as a file‑updating sidecar and a web server.

To create a pod, you can apply a YAML manifest with kubectl apply -f nginx-pod.yaml and inspect it with kubectl get pod or kubectl describe pod nginx . The manifest defines the API version, kind, metadata, and container specifications.

apiVersion: v1
kind: Pod
metadata:
  name: nginx  # pod name
spec:
  containers:   # container list
  - name: nginx # container name
    image: nginx:1.14.2 # container image
    ports:
    - containerPort: 80

A pod’s lifecycle progresses through phases: Pending, Running, Succeeded, Failed, and Unknown, reflecting scheduling, container health, and termination status.

The pod creation workflow involves the user submitting a pod manifest to the API server, which stores it in etcd; controllers generate events; the scheduler selects a node; the kubelet pulls images via the CRI, creates containers, mounts volumes, and configures networking through CNI.

Overall, pods provide an abstraction that simplifies deployment, scaling, and resource management for groups of containers in Kubernetes.