Kubernetes Deployments: Rolling Updates, Rollbacks and Scaling

Overview

This tutorial covers the core lifecycle management features of Kubernetes Deployments: performing rolling updates with zero downtime, rolling back failed releases, and scaling workloads horizontally. These are foundational skills for any Kubernetes administrator and represent a significant portion of the Certified Kubernetes Administrator (CKA) exam.

Prerequisites:

• A running Kubernetes cluster (minikube, kind, or a cloud provider)
• kubectl configured and connected to your cluster
• Basic understanding of Pods and ReplicaSets
• Familiarity with YAML syntax

For the CKA exam, Deployment management falls under the Workloads and Scheduling domain, which accounts for approximately 15% of the exam score. Understanding rollout strategies, revision history, and scaling commands is non-negotiable for passing.

Getting Started

Begin by creating a baseline Deployment using the NGINX image. This will serve as the foundation for all subsequent operations in this tutorial.

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.21
        ports:
        - containerPort: 80
        resources:
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "128Mi"
            cpu: "500m"

Apply the Deployment and verify it is healthy before proceeding:

kubectl apply -f deployment.yaml
kubectl rollout status deployment/nginx-deployment
kubectl get pods -l app=nginx
kubectl get deployment nginx-deployment

You should see 3 running pods and the rollout status reporting successfully rolled out. Note the maxSurge and maxUnavailable fields — these control the rolling update behaviour and are frequently tested on the CKA exam.

Rolling Updates

A rolling update replaces old Pod instances with new ones incrementally, ensuring your application remains available throughout the update process. Kubernetes achieves this by creating a new ReplicaSet and gradually shifting traffic from the old set to the new one.

Update the NGINX image from version 1.21 to 1.25 using the imperative command, then observe the rollout in real time:

kubectl set image deployment/nginx-deployment nginx=nginx:1.25 --record
kubectl rollout status deployment/nginx-deployment
kubectl get replicasets -l app=nginx

Alternatively, patch the Deployment declaratively by editing the YAML and re-applying:

# Updated container spec block only
containers:
- name: nginx
  image: nginx:1.25
  ports:
  - containerPort: 80

kubectl apply -f deployment.yaml
kubectl describe deployment nginx-deployment | grep -A5 "RollingUpdateStrategy"

Inspect the rollout history, which is critical for performing rollbacks:

kubectl rollout history deployment/nginx-deployment
kubectl rollout history deployment/nginx-deployment --revision=2

Common Pitfalls:

• Missing --record flag: Without it, revision history shows no change cause. Note: --record is deprecated in newer Kubernetes versions; use annotations instead.
• maxUnavailable: 0 with maxSurge: 0: This is an invalid combination and will block your rollout entirely.
• No resource limits set: Pods without resource requests may be evicted during updates on resource-constrained nodes, causing unexpected failures mid-rollout.
• Liveness/Readiness probes missing: Without probes, Kubernetes cannot determine if a new Pod is actually healthy before terminating old ones.

Rollbacks and Scaling

When a bad release reaches production, the ability to rollback quickly is essential. Kubernetes maintains a configurable revision history via the revisionHistoryLimit field on the Deployment spec.

Simulate a bad deployment by pushing a non-existent image tag:

kubectl set image deployment/nginx-deployment nginx=nginx:broken-tag
kubectl rollout status deployment/nginx-deployment
# This will hang — press Ctrl+C after observing the failure
kubectl get pods -l app=nginx
# You will see pods in ImagePullBackOff or ErrImagePull state

Roll back to the previous stable revision immediately:

# Rollback to the immediately previous revision
kubectl rollout undo deployment/nginx-deployment

# Rollback to a specific revision number
kubectl rollout undo deployment/nginx-deployment --to-revision=1

# Confirm the rollback succeeded
kubectl rollout status deployment/nginx-deployment
kubectl describe deployment nginx-deployment | grep Image

To control how many revisions Kubernetes retains, set revisionHistoryLimit in your Deployment spec:

spec:
  revisionHistoryLimit: 5
  replicas: 3
  selector:
    matchLabels:
      app: nginx

Scaling a Deployment adjusts the number of Pod replicas running at any given time. Kubernetes supports both imperative and declarative scaling approaches.

Scale the Deployment imperatively using kubectl:

# Scale up to 6 replicas
kubectl scale deployment/nginx-deployment --replicas=6

# Verify the new replica count
kubectl get deployment nginx-deployment
kubectl get pods -l app=nginx --watch

For production environments, use Horizontal Pod Autoscaler (HPA) to scale automatically based on CPU or memory utilisation:

# hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-deployment
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60

kubectl apply -f hpa.yaml
kubectl get hpa nginx-hpa
kubectl describe hpa nginx-hpa

Best Practices:

• Always define readinessProbes so Kubernetes only routes traffic to Pods that are genuinely ready to serve requests.
• Set minReadySeconds on the Deployment to add a buffer before a Pod is considered available, reducing the risk of routing traffic to an unstable Pod.
• Keep revisionHistoryLimit at 5-10 in production — too low and you lose rollback options; too high and you accumulate stale ReplicaSets.
• Use PodDisruptionBudgets (PDB) in conjunction with rolling updates to enforce minimum availability guarantees during cluster maintenance events.

Exam Tips for Certified Kubernetes Administrator (CKA)

The CKA is a performance-based exam conducted in a live terminal. Speed and accuracy with kubectl are paramount. The following tips are based on real exam scenarios.

Key Concepts Tested:

• Creating and modifying Deployments with specific replica counts and image versions
• Performing rolling updates and verifying rollout status
• Rolling back to a previous revision using --to-revision
• Scaling Deployments using both kubectl scale and editing the spec
• Understanding the relationship between Deployments, ReplicaSets, and Pods

Quick Reference Commands:

# Create a deployment imperatively (fastest in exam)
kubectl create deployment nginx-deployment --image=nginx:1.21 --replicas=3

# Update image
kubectl set image deployment/nginx-deployment nginx=nginx:1.25

# Check rollout status
kubectl rollout status deployment/nginx-deployment

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

# Rollback to previous
kubectl rollout undo deployment/nginx-deployment

# Rollback to specific revision
kubectl rollout undo deployment/nginx-deployment --to-revision=2

# Scale replicas
kubectl scale deployment/nginx-deployment --replicas=5

# Edit deployment live
kubectl edit deployment/nginx-deployment

# Pause a rollout (useful for canary-style updates)
kubectl rollout pause deployment/nginx-deployment

# Resume a paused rollout
kubectl rollout resume deployment/nginx-deployment

Common Exam Scenarios:

1. You are given a Deployment running image v1 and asked to update to v2 and verify the rollout completes successfully.
2. A Deployment has a bad image and you must roll it back to a specific working revision.
3. Scale an existing Deployment to a given replica count without restarting running Pods.
4. Configure a Deployment with a specific rolling update strategy limiting disruption to one Pod at a time.

Time-saving alias to set in exam terminal:

alias k=kubectl
export do="--dry-run=client -o yaml"

# Example usage
k create deployment test --image=nginx $do > test-deploy.yaml

Summary

In this tutorial you learned how to manage the complete lifecycle of a Kubernetes Deployment: creating a baseline Deployment with a defined rolling update strategy, updating images with zero downtime, inspecting and using revision history for rollbacks, and scaling workloads both manually and automatically with HPA.

Key Takeaways:

• RollingUpdate is the default strategy and is controlled by maxSurge and maxUnavailable parameters
• Every image update creates a new ReplicaSet revision tracked in rollout history
• Use kubectl rollout undo for fast incident recovery in production and exam scenarios
• Always pair Deployments with readiness probes and resource limits for production-grade reliability
• HPA provides dynamic scaling but requires the Metrics Server to be installed in the cluster

Next Steps:

• Explore StatefulSets for managing stateful applications like databases
• Learn DaemonSets for node-level workloads such as log collectors and monitoring agents
• Study PodDisruptionBudgets to enforce availability guarantees during rolling updates and node drains
• Practice these commands daily in a kind or minikube cluster to build exam-level speed

Continue your CKA preparation with our full certification guide at CloudNinjas.ca/cka, where we cover all exam domains with hands-on labs and practice questions.