Introduction to Kubernetes Deployment Strategies - Part 3

Table of contents

Reading Time: 5 minutes

Kubernetes provides many deployment strategies helps in maintaining the desired state of the application. In the previous blog we have covered the overview of 4 deployment strategies in K8s:

Rolling Update
Recreate
Canary
Blue/Green

You may go through the Introduction to Kubernetes Deployment Strategies (Introduction to Kubernetes Deployment Strategies – Knoldus Blogs) and another blog on the Recreate Strategy (Introduction to Kubernetes Deployment Strategies – Part 2 – Knoldus Blogs). In this Blog we will discuss the rolling update strategy in detail.

Rolling Update

This is the default strategy used by Kubernetes. Rolling update is slowly roll out the pods of new version so that it will not affect the application (no downtime during update).

Hands On

Below is a template of a deployment using the rolling update strategy

apiVersion: apps/v1
kind: Deployment
metadata: 
    name: nginx-deployment-rolling-update 
    namespace: nginx-app 
    labels: 
        app: nginx-rolling-update
    annotations: 
        description: "nginx deployment with rolling update strategy"
spec:
    selector:
        matchLabels:
            app: nginx-rolling-update
    replicas: 4
    strategy:
        type: RollingUpdate
        rollingUpdate:
            maxSurge: 25%
            maxUnavailable: 25%
    template:
        metadata:
            name: nginx
            labels:
                app: nginx-rolling-update
        spec:
            containers:
                - name: nginx
                  image: nginx:1.16-perl
                  ports:
                      - containerPort: 8080
                  resources:
                      requests:
                          memory: "64Mi"
                          cpu: "250m"
                      limits:
                          memory: "128Mi"
                          cpu: "500m"

Create a Deploment

Save the template as rolling-update.yml.
Then we create the deployment using kubectl command. This will be v1 of the app.

kubectl apply -f rolling-update.yml

kubectl apply may give error like Error from server (NotFound): error when creating "rolling-update.yml": namespaces "nginx-app" not found, this is because the above template create the deployment innginx-app namespace. To give a namespace for the deployment to be created in add namespace in .metadata.

By default, Kubernetes uses rolling update as the deployment strategy for the deployment. But we can further customize this strategy by adding the maxSurgeand maxUnavailable.
maxSurge tells the number of pods created at a time during the update. By default, it is 25% that means at most 125% of the desired number of replicas/pods are up.
maxUnavialable tells the number of pods down at a time during the update. By default, it is 25% that means at least 75% of the desired number of replicas/pods are up.

Check the Deployment created

kubectl get deployments

NAME lists the name of the deployments.
READY gives the number of the replicas of application. Format it uses to display the result is ready/desired. .spec.replicas tells the number of the desired replicas.
UP-TO-DATE gives that the number of replicas updated to achieve the desired state.
AVAILABLE tells the number of replicas available for user to use.
AGE tells the amount of time deployment is running.

Describe the deployment

kubectl describe deployment nginx-deployment-rolling-update -n nginx-app

Check the ReplicaSet created by the deployment

kubectl get rs -n nginx-app

NAME lists the name of the ReplicaSets.

ReplicaSet name follows format <Deployment Name>-<Random String>

DESIRED gives the desired number of the replicas of application. .spec.replicas tells the number of the desired replicas.
CURRENT tells that the number of replicas currently running.
READY gives the number of the replicas available to the user.
AGE gives the amount of time deployment is running.

Check the Pods created by ReplicaSet

kubectl get pods -n nginx-app

NAME lists the name of the ReplicaSets.

Pod name follows format <ReplicaSet Name>-<Random String>

READY lists the number container ready for the user inside the pod.
STATUS tells the current state of the pod.
RESTARTS gives the number of times a pod is restarted.
AGE gives the amount of time deployment is running.
Pods name follows format <ReplicaSet Name>-<Random String>

Updating the Deployment

Update the nginx container image from 1.16-perl to 1.18.0-perl

Update the nginx image version using kubectl command

kubectl set image deployment nginx-deployment-rolling-update nginx=nginx:1.18.0-perl

Check for the rollout status

kubectl rollout status nginx-deployment-rolling-update -n nginx-app

the out of the command may be

Waiting for rollout to finish: 1 out of 4 new replicas have been updated...

This means that rollout is in progress. After it gets completed, the output shows successfully rolled out.

Describe the deployment

kubectl describe deployment nginx-deployment-rolling-update -n nginx-app

describe kubernetes deployment after update

Roll back the Deployment Update

Roll back the update means to undoing the rollout (go back to the previous version of the deployment).

To Roll back the update using kubectl command

kubectl rollout undo deployment nginx-deployment-rolling-update -n nginx-app

Check the roll out status

kubectl rollout status deployment nginx-deployment-rolling-update -n nginx-app

Describe the deployment

kubectl describe deployment nginx-deployment-rolling-update -n nginx-app

describe kubernetes deployment after rollback

Steps

Behind the scenes, Kubernetes takes the following actions:
When using a Rolling Update deployment strategy in Kubernetes, the following actions occur.

First, the Deployment will create a ReplicaSet that has nginx:1.16-perl as the container image.
Then, ReplicaSet creates 4 pods to achieve the desired state.
Then, on the update of the container image to nginx:1.18.0-perl. It changes the image in the deployment to the same.
ReplicaSet will roll out 1 pod of new image as maxSurgeis 25% (25% of 4 = 1).
Then, delete 1 pod running the previous image version as maxUnavailableis 25% (25% of 4 = 1)
Goes on until all are updated.

When to use

As we know the main drawback of using Recreate is having downtime between the scaling down of the first ReplicaSet and scaling up of the second ReplicaSet. This strategy remove this drawback by slowly rolling out the new pods, so preventing the downtime.
We use this strategy when you want the application to have zero downtime.

Example code can be found on the following gist:
Template for deployment using the Rolling Update strategy