Solution Rolling update

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:

alias k='kubectl'
alias kubectl='k3s kubectl'
alias vi='vim'

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:

k get pod

You should see an output similar to:

NAME                                READY   STATUS    RESTARTS   AGE
frontend-5c74c57d95-mkgjh           1/1     Running   0          48s
frontend-5c74c57d95-dkbbj           1/1     Running   0          48s
frontend-5c74c57d95-gk60xp          1/1     Running   0          48s
frontend-5c74c57d95-xpwbt           1/1     Running   0          48s

Similarly, check the deployment status:

k get deploy

Expected output:

NAME       READY   UP-TO-DATE   AVAILABLE   AGE
frontend   4/4     4            4           55s

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:

k get pod

Output example:

NAME                             READY   STATUS    RESTARTS   AGE
frontend-5c74c57d95-nkgjh       1/1     Running   0          48s
frontend-5c74c57d95-dkbj1       1/1     Running   0          48s
frontend-5c74c57d95-gk6xp       1/1     Running   0          48s
frontend-5c74c57d95-xpwbt       1/1     Running   0          48s

And check the deployment:

k get deploy

NAME      READY   UP-TO-DATE   AVAILABLE   AGE
frontend  4/4     4            4           55s

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:

Hello, Application Version: v1 ; Color: blue OK
Hello, Application Version: v1 ; Color: blue OK
Hello, Application Version: v1 ; Color: blue OK
Hello, Application Version: v1 ; Color: blue OK
Hello, Application Version: v1 ; Color: blue OK
Hello, Application Version: v1 ; Color: blue OK
Hello, Application Version: v1 ; Color: blue OK
Hello, Application Version: v1 ; Color: blue OK
Hello, Application Version: v1 ; Color: blue OK
Hello, Application Version: v1 ; Color: blue OK
Hello, Application Version: v1 ; Color: blue OK
Hello, Application Version: v1 ; Color: blue OK

To further verify, inspect the deployment details:

k get deploy

NAME      READY   UP-TO-DATE   AVAILABLE   AGE
frontend  4/4     4            4           2m41s

Then view the container image used in the deployment:

k describe deploy frontend

Key details from the output:

• Container image: kodekloud/webapp-color:v1
• RollingUpdate strategy details (25% max unavailable, 25% max surge)

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:

k get deploy

NAME     READY   UP-TO-DATE   AVAILABLE   AGE
frontend 4/4     4            4           2m41s

k describe deploy frontend

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:

k set image deploy frontend simple-webapp=kodekloud/webapp-color:v2

After executing the command, verify the update:

k describe deploy frontend

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:

Hello, Application Version: v1 ; Color: blue OK
...
Hello, Application Version: v2 ; Color: green OK
...

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:

Using kubectl edit deployment frontend, update the strategy section. Change from:

strategy:
  rollingUpdate:
    maxSurge: 25%
    maxUnavailable: 25%
  type: RollingUpdate

to

strategy:
  type: Recreate

After editing, the deployment configuration should resemble:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
  namespace: default
spec:
  minReadySeconds: 20
  replicas: 4
  selector:
    matchLabels:
      name: webapp
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        name: webapp
    spec:
      containers:
      - name: simple-webapp
        image: kodekloud/webapp-color:v2
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 8080

Verify the strategy change with:

k describe deploy frontend

The output should now display:

StrategyType:           Recreate

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:

k set image deploy frontend simple-webapp=kodekloud/webapp-color:v3

Immediately after running the command, execute the test script:

./curl-test.sh

During the upgrade, you might see several request failures:

Failed
Failed
Failed
Failed
Failed
Failed
Failed

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:

Hello, Application Version: v3 ; Color: red OK
Hello, Application Version: v3 ; Color: red OK
Hello, Application Version: v3 ; Color: red OK
Hello, Application Version: v3 ; Color: red OK
Hello, Application Version: v3 ; Color: red OK
Hello, Application Version: v3 ; Color: red OK
Hello, Application Version: v3 ; Color: red OK
Hello, Application Version: v3 ; Color: red OK
Hello, Application Version: v3 ; Color: red OK
Hello, Application Version: v3 ; Color: red OK
Hello, Application Version: v3 ; Color: red OK
Hello, Application Version: v3 ; Color: red OK

This concludes the lab on rolling updates and strategy changes in Kubernetes. Enjoy experimenting with dynamic update strategies and managing your deployments efficiently!