Deployments Explained

Deployments Explained

A Deployment tells Kubernetes to maintain a desired number of Pod replicas and to handle updates safely. When you update the container image in a Deployment, Kubernetes performs a rolling update: it starts new pods with the new image before terminating old pods, so the application stays available throughout the update. When something goes wrong, you can roll back to the previous version with a single command. Deployments are the standard way to run stateless applications in Kubernetes.

Why Deployments?

Deployment: desired state = 3 replicas of v1.0

  Deployment
      |
      +-- ReplicaSet (v1.0)
              |-- Pod 1 (nginx:1.0)  Running on worker-01
              |-- Pod 2 (nginx:1.0)  Running on worker-02
              +-- Pod 3 (nginx:1.0)  Running on worker-01

  Node worker-02 crashes:
  → ReplicaSet notices: only 2 pods running
  → Schedules replacement Pod on worker-01
  → Desired state (3 replicas) restored automatically

Writing a Deployment manifest

nano nginx-deployment.yaml

nginx-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3                    # Run 3 pods at all times
  selector:
    matchLabels:
      app: nginx                 # This Deployment manages pods with this label
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1                # Create 1 extra pod during update
      maxUnavailable: 0          # Never reduce below 3 running pods during update
  template:                      # Pod template — all Pod fields go here
    metadata:
      labels:
        app: nginx               # Must match selector.matchLabels
    spec:
      containers:
        - name: nginx
          image: nginx:1.24
          ports:
            - containerPort: 80
          resources:
            requests:
              memory: "64Mi"
              cpu: "100m"
            limits:
              memory: "128Mi"
              cpu: "200m"

# Apply the deployment:
kubectl apply -f nginx-deployment.yaml

# Watch pods roll out:
kubectl rollout status deployment/nginx-deployment

# View the deployment and its pods:
kubectl get deployment nginx-deployment
kubectl get pods -l app=nginx

kubectl get deployment output

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           2m
# READY 3/3 = all 3 desired replicas are running

Scaling and rolling updates

# Scale up to 5 replicas:
kubectl scale deployment nginx-deployment --replicas=5

# Scale down to 2:
kubectl scale deployment nginx-deployment --replicas=2

# Update the container image (triggers rolling update):
kubectl set image deployment/nginx-deployment nginx=nginx:1.25

# Watch the rolling update in progress:
kubectl rollout status deployment/nginx-deployment

rollout status output

Waiting for deployment "nginx-deployment" rollout to finish: 1 out of 3 new replicas have been updated...
Waiting for deployment "nginx-deployment" rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for deployment "nginx-deployment" rollout to finish: 1 old replicas are pending termination...
deployment "nginx-deployment" successfully rolled out

Rollback

# View rollout history:
kubectl rollout history deployment/nginx-deployment

rollout history output

REVISION  CHANGE-CAUSE
1         
2         
# Revisions increment with each change

# Roll back to the previous revision:
kubectl rollout undo deployment/nginx-deployment

# Roll back to a specific revision:
kubectl rollout undo deployment/nginx-deployment --to-revision=1

# Check the current image after rollback:
kubectl describe deployment nginx-deployment | grep Image

Conclusion

Deployments with maxUnavailable: 0 and maxSurge: 1 in the rolling update strategy give you zero-downtime deployments out of the box. The Deployment controller maintains revision history, making rollback a one-command operation. Always set resource requests and limits in your Pod template — without them, the Kubernetes scheduler cannot make good placement decisions, and a misbehaving pod can starve all other pods on the same node.