Kubernetes Deployment Update & Rollback: Real-World DevOps Scenario

Our course you can check :-   Udemy course  

Ques:-   

There is a production deployment planned for next week. DevOps team wants to test the deployment update and rollback on Dev environment first so that they can identify the risks in advance. Below you can find more details about the plan they want to execute.

Create a namespace datacenter. Create a deployment called httpd-deploy under this new namespace, It should have one container called httpd, use httpd:2.4.28 image and 3 replicas. The deployment should use RollingUpdate strategy with maxSurge=1, and maxUnavailable=2. Also create a NodePort type service named httpd-service and expose the deployment on nodePort: 30008.

Now upgrade the deployment to version httpd:2.4.43 using a rolling update.

Finally, once all pods are updated undo the recent update and roll back to the previous/original version.

Ans:-

Here’s a step-by-step guide to help you execute the deployment update and rollback scenario in your Dev Kubernetes environment:

Step 1: Create Namespace

raj@jumphost ~$ kubectl create namespace datacenter

namespace/datacenter created

Step 2: Create Deployment httpd-deploy and service

raj@jumphost ~$ cat pod.yaml

---

# Save this as httpd-deploy.yaml

apiVersion: apps/v1

kind: Deployment

metadata:

  name: httpd-deploy

  namespace: datacenter

spec:

  replicas: 3

  strategy:

    type: RollingUpdate

    rollingUpdate:

      maxSurge: 1

      maxUnavailable: 2

  selector:

    matchLabels:

      app: httpd

  template:

    metadata:

      labels:

        app: httpd

    spec:

      containers:

      - name: httpd

        image: httpd:2.4.28

        ports:

        - containerPort: 80

---

# Save this as httpd-service.yaml

apiVersion: v1

kind: Service

metadata:

  name: httpd-service

  namespace: datacenter

spec:

  type: NodePort

  selector:

    app: httpd

  ports:

  - port: 80

    targetPort: 80

    nodePort: 30008

raj@jumphost ~$ kubectl apply -f pod.yaml

deployment.apps/httpd-deploy created

service/httpd-service created

raj@jumphost ~$ kubectl describe deploy httpd-deploy -n datacenter | grep -i image

    Image:         httpd:2.4.28

Step 3: Upgrade Deployment to httpd:2.4.43

raj@jumphost ~$ kubectl set image deployment/httpd-deploy httpd=httpd:2.4.43 -n datacenter

deployment.apps/httpd-deploy image updated

raj@jumphost ~$ kubectl describe deploy httpd-deploy -n datacenter | grep -i image

    Image:         httpd:2.4.43

You can monitor the rollout status:

raj@jumphost ~$ kubectl rollout status deployment/httpd-deploy -n datacenter

deployment "httpd-deploy" successfully rolled out

Step 4: Rollback to Previous Version

raj@jumphost ~$ kubectl rollout undo deployment/httpd-deploy -n datacenter

deployment.apps/httpd-deploy rolled back

raj@jumphost ~$ kubectl describe deploy httpd-deploy -n datacenter | grep -i image

    Image:         httpd:2.4.28

Optional: Verify Revision History

raj@jumphost ~$ kubectl rollout history deployment/httpd-deploy -n datacenter

deployment.apps/httpd-deploy 

REVISION  CHANGE-CAUSE

2         <none>

3         <none>

raj@jumphost ~$ 

Here’s a detailed explanation of the Kubernetes deployment strategy block:

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 2

This configuration defines how Kubernetes updates the pods during a deployment change (like upgrading the image version). Let’s break it down:

---

🔄 type: RollingUpdate

This tells Kubernetes to use a rolling update strategy, which means:

• Pods are updated gradually, not all at once.
• It ensures high availability during the update.
• Old pods are terminated only after new pods are up and running.

---

⚙️ rollingUpdate Parameters

✅ maxSurge: 1

• This defines the maximum number of extra pods that can be created above the desired number of replicas during the update.
• In your case, the deployment has 3 replicas, so during the update, Kubernetes can temporarily run up to 4 pods (3 existing + 1 new).
• This helps speed up the update while maintaining availability.

❌ maxUnavailable: 2

• This defines the maximum number of pods that can be unavailable during the update.
• In your case, up to 2 pods can be taken down at a time while new ones are being created.
• This allows Kubernetes to replace pods faster, but it also means only 1 pod will be serving traffic during the update.

---

📊 How It Works Together

Let’s say you’re updating from httpd:2.4.28 to httpd:2.4.43:

1. Kubernetes starts by creating 1 new pod (due to maxSurge: 1).
2. It then terminates up to 2 old pods (due to maxUnavailable: 2).
3. This cycle continues until all old pods are replaced with new ones.
4. At any point, there will be at least 1 pod running, ensuring minimal downtime.

---

🛡️ Why This Matters in Production

• maxSurge helps maintain availability by adding new pods before removing old ones.
• maxUnavailable controls how many pods can be offline, balancing speed and reliability.
• This strategy is ideal for critical services where zero downtime is preferred but fast rollout is also needed.

Conclusion:-

Learn how to safely test and execute deployment updates and rollbacks in Kubernetes using a real-world DevOps scenario. In this hands-on tutorial, we’ll walk through:

• Creating a dedicated namespace for testing
• Deploying an httpd application with a rolling update strategy
• Exposing the deployment via a NodePort service
• Performing a version upgrade using kubectl set image
• Rolling back to the previous version without breaking revision history

This video is ideal for DevOps engineers, SREs, and Kubernetes learners who want to master deployment strategies and risk mitigation techniques before production releases.