What is a Pod?
In the last lesson we deployed a container using a Deployment. But Kubernetes
never actually runs a container by itself — it runs a Pod, and the
Deployment was managing Pods on our behalf the whole time.
What a Pod actually is
A Pod is the smallest thing you can deploy in Kubernetes. Most of the time it wraps a single container, but a Pod can hold multiple containers that are meant to run together, on the same machine, sharing:
- the same network namespace (they can reach each other on
localhost, and share one IP address as far as the rest of the cluster is concerned) - optionally, the same storage volumes
You could create one directly:
apiVersion: v1
kind: Pod
metadata:
name: hello-world
spec:
containers:
- name: hello-world
image: nginxdemos/hello
ports:
- containerPort: 80kubectl apply -f pod.yaml
kubectl get pods
kubectl logs hello-worldWhy you almost never do that
A bare Pod has no memory of what it's supposed to be. If the machine it's running on dies, that Pod is just gone — nothing notices, nothing replaces it. Remember the reconciliation loop from the last lesson: Kubernetes watches actual state and reconciles it against desired state. A lone Pod has no desired state attached to it beyond "exist," so there's nothing to reconcile back to once it disappears.
That's exactly the gap a Deployment fills. When you write:
spec:
replicas: 3you're not creating 3 Pods yourself — you're telling Kubernetes "there should always be 3 Pods matching this template." The Deployment creates and watches the Pods, and recreates them the moment reality drifts from that number. This is why, in practice, you write Deployments (or similar controllers) and let Kubernetes create the Pods, rather than writing Pod manifests directly.
What's next
Pods are also disposable in a more subtle way: every time one gets
recreated, it usually gets a new IP address. The next lesson covers how
a Service gives a moving, ever-changing set of Pods one stable address
the rest of your system can actually depend on.