Pods

A pod is the smallest deployable unit in Kubernetes. It represents one or more containers that share the same network namespace and storage volumes. Pods are ephemeral by design — if a pod is deleted or its node fails, Kubernetes creates a replacement rather than restarting the original.

Why Pods Wrap Containers

Kubernetes wraps containers in pods to allow tightly coupled processes to share resources. Two containers in the same pod share the same IP address and port space, can communicate via localhost, and can read from the same mounted volumes. A common pattern is the sidecar: a helper container (for logging, proxying, or syncing) running alongside the main application container in the same pod.

Writing a Pod Manifest

apiVersion: v1
kind: Pod
metadata:
  name: my-app
  labels:
    app: my-app
spec:
  containers:
    - name: app
      image: nginx:1.25
      ports:
        - containerPort: 80
      resources:
        requests:
          cpu: "100m"
          memory: "128Mi"
        limits:
          cpu: "500m"
          memory: "256Mi"

Key fields:

• metadata.name — unique name within the namespace
• metadata.labels — arbitrary key/value pairs used by selectors
• spec.containers — list of container definitions
• resources.requests — minimum resources the scheduler reserves on a node
• resources.limits — maximum resources the container can consume before being throttled (CPU) or killed (memory)

Pod Lifecycle

A pod moves through several phases:

• Pending — accepted by the cluster but not yet scheduled or images not yet pulled
• Running — at least one container is running
• Succeeded — all containers exited with status 0 (typical for batch jobs)
• Failed — at least one container exited with a non-zero status
• Unknown — the node is unreachable

Interacting with Pods

# Apply a pod manifest
kubectl apply -f pod.yaml

# List pods in the current namespace
kubectl get pods

# Show detailed information including events
kubectl describe pod my-app

# Stream logs from a running pod
kubectl logs -f my-app

# Open an interactive shell inside a pod
kubectl exec -it my-app -- /bin/sh

Probes

Kubernetes supports three types of health probes:

• livenessProbe — if this fails, Kubernetes restarts the container
• readinessProbe — if this fails, the pod is removed from Service endpoints so it receives no traffic
• startupProbe — delays liveness checking until the container has had time to initialise