Skip to main content
In this lab, we dive into rolling updates and rollbacks in Kubernetes, with a primary focus on rolling updates. For brevity, the alias “k” is used to represent “kubectl” throughout this guide. An alias has been set for kubectl:

​
Deploying and Inspecting the Application

We have deployed a simple web application. Begin by inspecting the pods and services to verify the deployment status. When running:
You should see an output similar to:
Similarly, check the deployment status:
Expected output:
Once fully deployed, open your browser and access the application. It should display “hello, front end” on the landing page.

​
Validating Application Color and Running Tests

By default, the application is set to blue. Validate this by checking the pods:
Output example:
And check the deployment:
The output confirms that the application is blue. Next, execute the test script curl-test.sh to simulate multiple user requests. The output should confirm the application’s version and color:
To further verify, inspect the deployment details:
Then view the container image used in the deployment:
Key details from the output:
  • Container image: kodekloud/webapp-color:v1
  • RollingUpdate strategy details (25% max unavailable, 25% max surge)
The rolling update strategy ensures that only a subset of pods is updated at a time, providing a smooth transition during application upgrades.

​
Reviewing the Rolling Update Strategy

The current deployment strategy is RollingUpdate, meaning that only a few pods are taken down at any given time during an upgrade. Verification using the following commands confirms the strategy in action:
Review the details showing:
  • StrategyType: RollingUpdate
  • RollingUpdateStrategy: 25% max unavailable, 25% max surge
With 4 replicas, only one pod is updated at a time. This minimizes downtime and ensures continuous service availability.

​
Upgrading the Application to v2

To simulate an upgrade, update the container image to kodekloud/webapp-color:v2. There are two methods available:
  1. Edit the deployment manually using kubectl edit deployment frontend.
  2. Use the kubectl set image command.
In this lab, we use the latter:
After executing the command, verify the update:
Key observations include:
  • The deployment revision increments (e.g., revision: 2).
  • The output shows a mix of updated and non-updated pods.
  • Running the test script now reveals mixed responses:
As the update progresses, eventually all pods will run version v2 and display green.

​
Adjusting the Deployment Strategy to Recreate

Next, we modify the deployment strategy from RollingUpdate to Recreate. In the Recreate strategy, all existing pods are shut down before new ones are created, which might result in temporary downtime. Edit the deployment using:
The image shows a terminal interface with instructions to upgrade a deployment image to "kodekloud/webapp-color:v2" without recreating it.
Using kubectl edit deployment frontend, update the strategy section. Change from:
to
After editing, the deployment configuration should resemble:
Verify the strategy change with:
The output should now display:
Switching to the Recreate strategy will result in downtime since all the pods are terminated before new ones are created.

​
Upgrading the Application to v3 with Recreate Strategy

Now that the deployment is set to the Recreate strategy, upgrade the application by updating the container image to kodekloud/webapp-color:v3:
Immediately after running the command, execute the test script:
During the upgrade, you might see several request failures:
These errors occur because all pods are temporarily down during the recreate process. Once the update completes, accessing the application will show version v3 with red color:
This concludes the lab on rolling updates and strategy changes in Kubernetes. Enjoy experimenting with dynamic update strategies and managing your deployments efficiently!

Watch Video