Lesson 2 of 6

Pods

Kubernetes never runs a bare container. Its smallest deployable unit is the pod — a thin wrapper around one (usually) or more (occasionally) containers that always live and die together on the same machine. Almost everything else in Kubernetes exists to create, replace, or route traffic to pods, so this is the object to understand deeply.

💡 The Bottom Line

A pod = one or more containers sharing one network identity (one IP, one localhost) and one lifecycle. In practice, the overwhelming default is one container per pod — think of a pod as "a container plus the Kubernetes-shaped envelope around it."

Your first manifest

apiVersion: v1
kind: Pod
metadata:
  name: web
  labels:
    app: web
spec:
  containers:
    - name: web
      image: nginx:1.27
      ports:
        - containerPort: 80

Every Kubernetes manifest has this same four-part shape, worth memorizing now:

apiVersion + kind — what type of object this is.
metadata — its name and labels (key/value tags — these look decorative now but become the glue that wires everything together in Lessons 3 and 4).
spec — the desired state: which image, which ports.

Apply it and check on it:

kubectl apply -f pod.yaml
kubectl get pods
kubectl describe pod web
kubectl logs web

The debugging trio

These three commands are how every Kubernetes debugging session starts, forever:

kubectl get pods — the headline: is it Running, Pending, CrashLoopBackOff? How many restarts?
kubectl describe pod web — the full story: which node it's on, and crucially the Events section at the bottom — image pulls, failures, scheduling decisions.
kubectl logs web — what the app itself printed. Add --previous to see the logs of the crashed attempt before the current one.

🙋 There Are No Dumb Questions

Q: Why does Kubernetes wrap containers in pods at all? Why not just run containers?
A: Because some workloads genuinely need two processes glued together — an app plus a log shipper, or a proxy "sidecar" — sharing localhost and fate. The pod makes "these containers are one unit" a first-class concept instead of a fragile convention. You'll write single-container pods 95% of the time, but the abstraction is why sidecar patterns work cleanly when you need them.

⚠️ Watch Out

A bare pod like the one above is not self-healing. If its node dies, the pod is gone — nothing recreates it, because nothing owns it. Bare pods are for learning and one-off debugging only. Real workloads are always created through a Deployment, which is exactly what the next lesson adds.

🔧 Try It Yourself

Save the manifest above as pod.yaml, apply it, and interrogate it:

kubectl apply -f pod.yaml
kubectl get pods -o wide        # note the pod's IP and node
kubectl describe pod web        # read the Events section
kubectl port-forward pod/web 8080:80   # visit http://localhost:8080
kubectl delete pod web

port-forward is the quick local-access trick — real traffic routing comes in Lesson 4.

✅ Quick Check

What is a Kubernetes pod?

Next up: making pods survivable — Deployments and ReplicaSets, the objects that keep the right number of pods alive and roll out new versions safely.

← Back to