Skip to main content
In this lesson we demonstrate Kubernetes deployment strategies and their behavior during application upgrades. You’ll see how the default RollingUpdate strategy replaces pods incrementally (minimizing downtime) and how the Recreate strategy brings down all old pods before starting new ones (causing downtime). We also run live tests to observe mixed-version responses during a rolling upgrade.

​
Environment: aliases and verification

I use the alias k for kubectl. Confirm the aliases:
The k alias points to kubectl which is further aliased to k3s kubectl on this control plane. Use k for the commands in this guide.

​
Inspect the deployed application

List pods and the Deployment to confirm the current state:
The application is reachable via the KodeKloud portal. The page shows the running pod name and the application version.
A plain blue webpage with a centered white heading that reads "Hello from frontend-5c74c57d95-xpwbt!" and a subheading "Application Version: v1" near the top. The rest of the page is an empty blue area.
Question: What is the current color of the web application?
  • The page is blue — the running pods serve version v1 (blue).
Run the provided test script (curl-test.sh) to repeatedly hit the application and confirm responses:

​
Which container image is used?

Describe the Deployment to inspect the image and rollout strategy:
  • Image in use: kodekloud/webapp-color:v1
  • Current strategy: RollingUpdate with maxUnavailable: 25% and maxSurge: 25%.
What does that mean?
  • With 4 replicas, 25% maxUnavailable allows at most 1 pod to be unavailable during the update. RollingUpdate replaces pods gradually to avoid full downtime.

​
Perform a rolling upgrade to v2

Update the Deployment image to v2:
Verify the Deployment now references v2 and watch the rollout progress:
While the rolling update is in progress, run the test script again to observe mixed responses:
  • During a RollingUpdate you will see a mix of v1 (blue) and v2 (green) responses as pods are replaced incrementally. The update is performed with minimal disruption.

​
Switch strategy to Recreate

To observe a different behavior, change the Deployment strategy to Recreate (this will terminate all old pods before creating new ones). Example Deployment snippet:
Verify the strategy change:
Recreate will terminate all existing pods before creating new ones. Expect downtime during an upgrade with this strategy, especially if you have a single replica or limited capacity.

​
Upgrade to v3 using Recreate and observe behavior

Change the image to v3 while the strategy is Recreate:
Run the test script while Recreate is in effect:
  • Early during the upgrade, requests may fail (e.g., load balancer or proxy returns “Bad Gateway”) while all old pods are terminated and the new pods are not yet ready.
  • After new pods are up, responses will come from v3 (red):
  • Under Recreate you will see downtime during the transition; once the new pods are ready, the application serves v3 (red).

​
Quick comparison: RollingUpdate vs Recreate

​
Useful commands

  • Update image: k set image deploy frontend simple-webapp=kodekloud/webapp-color:<tag>
  • Inspect rollout and strategy: k describe deployment frontend
  • Watch rollout status: k rollout status deployment/frontend
  • Roll back to previous revision: k rollout undo deployment/frontend

​
Summary

  • RollingUpdate (default) replaces pods incrementally; with maxUnavailable: 25% on 4 replicas, at most 1 pod is unavailable at a time.
  • Recreate stops all old pods before starting new ones — this can cause downtime.
  • Use kubectl set image to update the image and kubectl describe deployment or kubectl rollout status to monitor progress.

Watch Video