Pods & Deployments
From a single Pod to a self-healing, scalable Deployment.
You almost never create a bare Pod in production. Instead you create a Deployment, which manages a set of identical Pods for you — keeping the right number running, replacing failed ones, and rolling out new versions safely.
🎯 Learning Objectives
By the end of this lesson you will:
- Write and apply a Pod manifest
- Understand why Deployments are preferred over bare Pods
- Scale an app up and down
- Perform a rolling update and a rollback
A Pod Manifest
Kubernetes objects are described in YAML. Here’s the simplest Pod:
apiVersion: v1
kind: Pod
metadata:
name: web
spec:
containers:
- name: nginx
image: nginx:1.27
ports:
- containerPort: 80Apply it with kubectl apply -f pod.yaml. But there’s a problem: if this Pod’s node dies, the Pod is gone forever. Nothing recreates it.
⚠ Don't run bare Pods in production
A standalone Pod has no self-healing. If it dies, it stays dead. Always use a controller like a Deployment, which recreates Pods to maintain your desired count.
The Deployment
A Deployment wraps your Pods and guarantees a desired number of replicas:
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
replicas: 3 # keep 3 Pods running at all times
selector:
matchLabels:
app: web
template: # the Pod blueprint
metadata:
labels:
app: web
spec:
containers:
- name: nginx
image: nginx:1.27
ports:
- containerPort: 80Apply it and Kubernetes creates three Pods. Kill one, and a replacement appears within seconds.
Scaling
Change the replica count anytime — declaratively or with a quick command:
kubectl scale deployment web --replicas=5 # scale up
kubectl get pods # now 5 pods
kubectl scale deployment web --replicas=2 # scale down💡 Prefer editing the YAML
kubectl scale is handy for a quick change, but in real GitOps workflows you edit the replicas value in the manifest and commit it. The manifest in Git stays the single source of truth.
Rolling Updates & Rollbacks
When you change the image version, the Deployment rolls it out gradually — replacing Pods a few at a time so the app never goes fully down:
kubectl set image deployment/web nginx=nginx:1.28 # trigger rollout
kubectl rollout status deployment/web # watch it
kubectl rollout undo deployment/web # roll back if brokenIf the new version is broken, kubectl rollout undo instantly returns to the previous working version.
🧪 Hands-on Lab
Deploy, Scale, and Self-Heal
- Create a Deployment of nginx with 3 replicas
- Delete one Pod and watch Kubernetes recreate it
- Scale to 5 replicas, then update the image and roll it out
🧠 Knowledge Check
Why is a Deployment preferred over creating a bare Pod?
A new version you rolled out is broken. What's the fastest safe recovery?
💼 Interview Preparation
How does Kubernetes achieve zero-downtime deployments?
Summary
You can now run apps with Pods, use Deployments for replicas and self-healing, scale on demand, and roll out or roll back versions safely. But how does traffic reach these ever-changing Pods? That’s the job of Services — up next.