Kubernetes Pods The Smallest Unit You Deploy

A Pod is the smallest deployable unit in Kubernetes. You do not run containers directly in Kubernetes — you run Pods, and each Pod holds one or more containers. Understanding Pods is the foundation for everything else in Kubernetes.

What a Pod Actually Is

Think of a Pod as a small apartment. A container is a person living in that apartment. The apartment gives the person a home address (IP address), shared storage (volumes), and a front door (network namespace). All containers in one Pod share the same IP address and can talk to each other using localhost.

┌──────────────────────────────────────┐
│                  POD                 │
│  IP: 10.1.0.5                        │
│                                      │
│  ┌───────────────┐  ┌─────────────┐  │
│  │  Main App     │  │  Sidecar    │  │
│  │  Container    │  │  Container  │  │
│  │  port: 8080   │  │  port: 9090 │  │
│  └───────────────┘  └─────────────┘  │
│                                      │
│  Shared Volume: /data                │
└──────────────────────────────────────┘
        One IP · Shared Storage

Why Pods Exist Instead of Running Containers Directly

Kubernetes groups containers into Pods for situations where two processes must run together and share resources. A web application might need a logging agent that reads its log files. If both containers share the same Pod, the agent reads logs directly from a shared volume without any network hop. They live together and die together — when Kubernetes terminates a Pod, it terminates all containers inside it at once.

Single-Container vs. Multi-Container Pods

The most common pattern is one container per Pod. You use multi-container Pods for specific helper patterns called sidecars.

Sidecar Pattern

A sidecar container adds a feature to the main container without modifying the main container's code. Examples include: a log shipper that reads logs and sends them to Elasticsearch, a proxy that handles TLS termination, or a config-watcher that reloads configuration when files change.

Main Container (your app)
       |
Sidecar Container (helper)
       |
Both share the same Pod network and volume

Writing a Pod YAML File

Every Kubernetes resource uses a YAML file to define its configuration. Here is a simple Pod:

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

Every YAML file in Kubernetes has four top-level fields: apiVersion, kind, metadata, and spec. The spec section defines what containers to run, what image to use, and which ports to open.

Pod Lifecycle Phases

A Pod moves through several phases from creation to termination:

Pod Restart Policies

The restart policy tells Kubernetes what to do when a container inside a Pod exits:

• Always — Restart the container every time it exits. This is the default for long-running apps.
• OnFailure — Restart only if the container exits with an error. Used for batch jobs.
• Never — Do not restart. Used for one-time tasks.

Probes: Checking If Your App Is Healthy

Kubernetes uses probes to check container health. Without probes, Kubernetes assumes a container is healthy as long as the process is running — even if the app is stuck in an error loop.

Liveness Probe

A liveness probe checks whether the container is alive. If the probe fails repeatedly, Kubernetes kills and restarts the container. It is like a doctor checking a patient's pulse — if there is no pulse, they intervene.

Readiness Probe

A readiness probe checks whether the container is ready to receive traffic. If the probe fails, Kubernetes removes the Pod from the Service's load balancer without killing it. This prevents new requests from going to a container that is still warming up.

Startup Probe

A startup probe gives slow-starting apps extra time before the liveness probe kicks in. Once the startup probe passes, the liveness probe takes over.

Container starts
     ↓
Startup Probe passes?
     Yes → Readiness Probe runs → Pod receives traffic
                                 → Liveness Probe monitors continuously
     No (repeated failures) → Container killed and restarted

Example liveness probe in YAML:

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5
  failureThreshold: 3

Why You Rarely Create Pods Directly

Pods are ephemeral — when a Pod dies, Kubernetes does not automatically replace it unless a higher-level resource like a Deployment manages it. If you create a Pod manually and the node it runs on fails, that Pod is gone. Deployments, ReplicaSets, and StatefulSets create and manage Pods on your behalf, ensuring the right number always runs. You will use those in the next topics.

Inspecting a Running Pod

kubectl get pod my-web-app
kubectl describe pod my-web-app    # Events and detailed state
kubectl logs my-web-app            # Container logs
kubectl exec -it my-web-app -- sh  # Open a shell inside

Key Points

• A Pod is the smallest deployable unit in Kubernetes — it wraps one or more containers.
• All containers in a Pod share the same IP address and volumes.
• Use liveness probes to restart broken containers and readiness probes to stop traffic to unhealthy containers.
• Pods are ephemeral — always manage them through a Deployment or similar controller, not by creating them manually.