Session 2: why you almost never create a pod directly

Last session I created a pod, deleted it, and nothing brought it back. That is the whole reason Deployments exist.

A Deployment is a controller that says “keep N pods of this shape running, at all times.” If a pod crashes, the Deployment creates a new one. If a node dies, the Deployment reschedules the pods elsewhere. It watches. Constantly.

You describe a Deployment in YAML:

• What the pod looks like (image, ports, env, resource limits)
• How many replicas
• What rollout strategy (rolling update, recreate)

The Deployment creates a ReplicaSet, which creates the pods. Three layers: Deployment → ReplicaSet → Pod. The Deployment owns the rollout logic. The ReplicaSet owns the count. The Pod runs the container.

kubectl commands I ran today:

• kubectl create deployment demo --image=nginx --replicas=3 (creates a Deployment with 3 nginx pods)
• kubectl get deployments (lists Deployments)
• kubectl get replicasets (shows the ReplicaSet it created)
• kubectl get pods -l app=demo (shows the 3 pods)
• kubectl delete pod <one-of-the-pod-names> (delete one and watch it come back)
• kubectl get pods -l app=demo (a new pod is already being created)
• kubectl scale deployment demo --replicas=5 (scale up)
• kubectl scale deployment demo --replicas=1 (scale down)
• kubectl delete deployment demo (deletes the Deployment, which deletes the ReplicaSet, which deletes the pods)

Things I noticed:

• Delete a pod: it comes back. Delete the Deployment: everything goes.
• The pod names have random suffixes (like demo-6b8f7c-abc12) because they are managed, not hand-named.
• The ReplicaSet has one job: keep N pods running. It does not know about rolling updates. That is the Deployment’s job.

The mental model.

Pods are cattle. Deployments are the ranch that keeps producing cattle. You interact with the Deployment, not the pods.

Next: rolling updates. How Deployments upgrade without downtime.