Pods Explained
A Pod is the smallest and simplest deployable unit in Kubernetes. Rather than scheduling individual containers, Kubernetes always schedules Pods -- a Pod wraps one or more containers that share the same network namespace, IP address, and storage volumes, and are always scheduled together on the same node.
Cricket analogy: Like an opening pair always walking out to bat together as a unit rather than one batter at a time, a Pod schedules its containers together on the same node, sharing one IP and one set of stumps to defend.
Why Group Containers Into a Pod?
Most Pods contain a single container, but Kubernetes supports multi-container Pods for tightly coupled helper processes -- for example, a 'sidecar' container that ships logs, or an 'init container' that runs setup logic before the main application starts. Containers in the same Pod can communicate over localhost and share mounted volumes, because they share the same network and storage context.
Cricket analogy: Like a substitute fielder brought on just to carry drinks during a session while the main XI plays, a sidecar container ships logs or handles setup alongside the main app, communicating over localhost within the same Pod.
A Minimal Pod Manifest
A Pod is typically defined in a YAML manifest with apiVersion, kind, metadata, and spec fields. The spec's containers list describes what image to run, which ports it exposes, and any resource requests or limits.
Cricket analogy: Like a team sheet listing the format, venue, and playing XI with each player's batting position, a Pod's YAML manifest lists apiVersion, kind, metadata, and a spec describing each container's image and exposed ports.
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.25
ports:
- containerPort: 80
resources:
requests:
cpu: "100m"
memory: "64Mi"
limits:
cpu: "250m"
memory: "128Mi"# Create the pod from the manifest above
kubectl apply -f nginx-pod.yaml
# Confirm it's running
kubectl get pods
# Clean it up when done
kubectl delete pod nginx-podPod Lifecycle Phases
A Pod moves through phases: Pending (accepted by the cluster but containers not yet running, e.g., still pulling images or waiting to be scheduled), Running (bound to a node and at least one container is running), Succeeded (all containers terminated successfully, typical for batch jobs), Failed (all containers terminated and at least one exited with failure), and Unknown (state could not be determined, often due to a node communication problem).
Cricket analogy: Like a match going through stages — toss pending, play in progress, result declared, abandoned, or umpires unsure due to bad light — a Pod moves through Pending, Running, Succeeded, Failed, and Unknown phases.
Container-level states within a Pod include Waiting, Running, and Terminated -- visible in the 'containerStatuses' section of 'kubectl describe pod' output, which is invaluable for debugging startup issues.
Pods Are Ephemeral
Pods are not meant to be durable, long-lived entities. If a Pod's node fails or the Pod is deleted, it is gone permanently -- Kubernetes does not resurrect the exact same Pod. This is why bare Pods are rarely used directly in production; instead, higher-level controllers like Deployments and ReplicaSets manage Pods, creating replacement Pods automatically when one disappears. Every Pod also gets its own unique cluster-internal IP address, shared by all its containers, which can reach each other via 'localhost' and share mounted volumes. Creating bare, unmanaged Pods directly (as shown above) is fine for learning and quick debugging, but in production you should almost always create Pods indirectly through a Deployment, StatefulSet, or Job so Kubernetes can recreate them automatically on failure.
Cricket analogy: Like a specific player who retires never literally returning, so a franchise's talent pipeline (like a Deployment) recruits a new player to fill the role rather than resurrecting the exact same career, Pods are replaced, never resurrected identically.
- A Pod is the smallest deployable unit in Kubernetes; Kubernetes never schedules bare containers directly.
- Containers within a Pod share the same network namespace (including IP address) and can share storage volumes.
- A Pod's lifecycle phases are Pending, Running, Succeeded, Failed, and Unknown.
- Pods are ephemeral -- once deleted or lost, they are not recreated automatically unless managed by a controller.
- In production, Pods are almost always created via Deployments, StatefulSets, or Jobs rather than directly.
- Each Pod gets a unique cluster-internal IP shared by all its containers.
Practice what you learned
1. What is the smallest deployable unit that Kubernetes schedules onto a node?
2. What do containers within the same Pod share?
3. Which Pod phase indicates all containers have terminated successfully, typical of a batch job?
4. Why are bare Pods rarely used directly in production?
5. In the minimal Pod manifest example, what does 'resources.limits' define for the container?
Was this page helpful?
You May Also Like
Deployments and ReplicaSets
Learn how Deployments manage ReplicaSets to declaratively run, scale, and update stateless Pod replicas in Kubernetes.
kubectl Basics
A practical introduction to kubectl, the command-line tool used to interact with a Kubernetes cluster's API server.
Kubernetes Architecture
A tour of Kubernetes cluster architecture, covering control plane components and worker node components and how they interact.
Persistent Volumes and Claims
Learn how Kubernetes decouples storage from Pods using PersistentVolumes, PersistentVolumeClaims, and StorageClasses for durable, dynamically provisioned data.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsCI/CD Tools & Pipelines Study Notes
YAML · 37 topics