Deployments are how you run apps for real — declare replicas, scale them, roll out new versions with zero downtime, and roll back instantly when a release goes wrong.
Why: these three are a chain. You manage a Deployment; it creates a ReplicaSet (which keeps N identical pods alive); the ReplicaSet creates the Pods. replicas says how many copies you want, and the selector tells the Deployment which pods it owns by matching their labels. If a pod dies, the ReplicaSet replaces it — that is the self-healing you saw earlier.
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
replicas: 3 # keep 3 copies running
selector:
matchLabels:
app: web # this Deployment owns pods labelled app=web
template: # the pod blueprint
metadata:
labels:
app: web
spec:
containers:
- name: nginx
image: nginx:1.27Scaling means changing how many replicas run. Do it declaratively by editing replicas in the file and re-applying, or imperatively with kubectl scale for a quick change. Kubernetes adds or removes pods to match the new number — no app restart, no downtime.
Quick imperative scale to 5 replicas
kubectl scale deployment web --replicas=5See the pods rebalance
kubectl get pods -l app=webChange the image in the Deployment and Kubernetes performs a rolling update: it brings up new pods and retires old ones a few at a time, so the app stays available throughout. rollout status blocks until the new version is fully live, which makes it perfect for CI pipelines.
Update the image — triggers a rolling update
kubectl set image deployment/web nginx=nginx:1.28Watch the rollout progress to completion
kubectl rollout status deployment/webKubernetes keeps a history of a Deployment's rollouts. If a new version misbehaves, undo returns to the previous one immediately — the fastest incident mitigation you have. You can inspect the history and roll back to any specific revision.
See the rollout history
kubectl rollout history deployment/webInstantly revert to the previous version
kubectl rollout undo deployment/webOr to a specific revision number
kubectl rollout undo deployment/web --to-revision=2Why: the RollingUpdate strategy controls how aggressive the swap is. maxUnavailable is how many pods may be down during the update; maxSurge is how many extra you may create above the desired count. Setting maxUnavailable: 0 guarantees full capacity throughout — at the cost of briefly running extra pods.
spec:
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 0 # never drop below the desired replica count
maxSurge: 1 # add at most 1 extra pod at a time