Imperative vs declarative
In the last lab you ran a bare pod. The problem: if it crashes, it's
gone. A Deployment wraps pods so the cluster keeps a replica
count alive, supports rolling updates, and remembers history for
rollbacks.
You can create one imperatively — handy for quick experiments:
kubectl create deployment nginx-1 --image nginx:1.25.3
See what Kubernetes did under the hood. A Deployment created a
ReplicaSet, which created a Pod:
kubectl get deployments,replicasets,pods
Kill the pod and watch Kubernetes recreate it (the ReplicaSet keeps
the desired count satisfied):
kubectl delete pod -l app=nginx-1
kubectl get pods -l app=nginx-1
A new pod appears almost immediately. That's the self-healing
behaviour Deployments give you for free.
Click Verify step when the Deployment exists.
Hint
`kubectl create deployment nginx-1 --image nginx:1.25.3` creates a Deployment that immediately spins up one ReplicaSet → one pod.
Declarative deployment from YAML
In real projects you'll keep manifests in git, not run ad-hoc
commands. Look at the starter:
cat deployments/nginx-deployment.yaml
Note the three key fields:
replicas: 3 — the desired pod count.selector.matchLabels — which pods this Deployment owns.template — the pod spec to stamp out.
Apply it:
kubectl apply -f deployments/nginx-deployment.yaml
Watch three pods appear:
kubectl get deployments,pods -l app=nginx
kubectl apply is idempotent — running it twice does nothing the
second time. Try it:
kubectl apply -f deployments/nginx-deployment.yaml
You'll see unchanged instead of configured.
Click Verify step when nginx-deployment shows 3/3 ready.
Hint
`kubectl apply -f deployments/nginx-deployment.yaml` then `kubectl get deployments`.
Scale up and down
Scaling a Deployment changes its replica count. The ReplicaSet
underneath adds or removes pods to match.
Scale up to five:
kubectl scale --replicas=5 deployment/nginx-deployment
Watch new pods appear:
kubectl get pods -l app=nginx
Scale down to zero — useful for cost control on staging clusters:
kubectl scale --replicas=0 deployment/nginx-deployment
All pods terminate. The Deployment object stays — just with 0 desired
replicas.
Scale back up:
kubectl scale --replicas=3 deployment/nginx-deployment
The same effect is possible by editing replicas: in the YAML and
running kubectl apply -f again. Most teams scale imperatively in
emergencies and keep the YAML at the steady-state value.
Click Verify step when the Deployment is back at 3/3.
Hint
`kubectl scale --replicas=5 deployment/nginx-deployment`.
Roll out a new image
Updating a Deployment's container image triggers a rolling update:
Kubernetes creates a new ReplicaSet with the new image, scales it up
while scaling the old one down, and keeps the service available the
whole time.
Look at what's running now:
kubectl get deployment nginx-deployment -o wide
The IMAGES column shows nginx:1.25.3. Roll out a new version:
kubectl set image deployment/nginx-deployment nginx=nginx:1.26.0
Watch the rollout progress:
kubectl rollout status deployment/nginx-deployment
You'll see lines like Waiting for deployment "nginx-deployment" rollout to finish: 2 of 3 updated replicas are available... then
successfully rolled out.
See the two ReplicaSets — one with the old image (now at 0 replicas),
one with the new image at 3:
kubectl get rs -l app=nginx
Confirm the new image is running:
kubectl get deployment nginx-deployment -o jsonpath='{.spec.template.spec.containers[0].image}{"\n"}'
Click Verify step.
Hint
`kubectl set image deployment/nginx-deployment nginx=nginx:1.26.0` then `kubectl rollout status deployment/nginx-deployment`.
Roll back
The new version is broken. (Pretend it is.) Roll back to the previous
image without re-running kubectl set image.
See the rollout history:
kubectl rollout history deployment/nginx-deployment
Roll back one revision:
kubectl rollout undo deployment/nginx-deployment
Watch the rollout reverse:
kubectl rollout status deployment/nginx-deployment
Confirm the image is back to nginx:1.25.3:
kubectl get deployment nginx-deployment -o jsonpath='{.spec.template.spec.containers[0].image}{"\n"}'
Kubernetes keeps the last 10 revisions by default (configurable via
spec.revisionHistoryLimit). Each rollout writes a new ReplicaSet,
which makes rollback as cheap as scaling the old ReplicaSet back
up.
Click Verify step.
Hint
`kubectl rollout undo deployment/nginx-deployment` rolls back to the previous revision.