In a real scenario, the applications which are running on a kubernetes cluster have some versions and these versions change regularly as per the requirements.

So how we can upgrade, or downgrade the application without any server downtime. This can be achieved by using the deployment concept in kubernetes.

In the easiest term, deployment is a high-level abstraction that manages replica sets and it provides features such as rolling updates, rollback, versioning of the application, and reducing downtime.

When we create a deployment it creates a rollout, rollout means - Introducing a new version of the application.

When we want to upgrade our application from version let's say v1.0 to v1.1 this is called as rolling update mechanism. And if something went wrong and we want our application back with version v1.0 is called as rollback mechanism.

• Rolling Updates: v1.0 ---> v1.1

• Rollback: v1.1 ---> v1.0

Let the deployment manifest file name as deployment-manifest.yaml in which all specifications are written to create a deployment. Now to upgrade our application we need to modify this manifest file as per the requirement and run this manifest file so that the changes can be applied.

To check the status of the rollout :

> kubectl rollout status app/myapp-deployment

app-deployment is the name of the deployment. app/ is the path where the app-deployment is located in the directory.

To check the history of the rollout :

> kubectl rollout history app/myapp-deployment

This command will show a list of previous application versions.

In real-time how k8s do these deployments let's have a look at this a little deep, there are two types of deployment strategies.

[1]. Recreate Strategy

In this strategy, the deployment will destroy all the pods of the current replicaset (replica set-1) at a time and create all pods in a newer replicaset (replica set-2). This is a critical issue because the users will not able to access the contents of the application as the application will be down in between recreating the pods for some time. Below is the picture through which we can visualize this situation more easily.

[2]. Rolling update strategy

In this strategy, the deployment will down one pod from the current replicate set -1 and creates one pod in a new replica set -2 with a newer application version one by one so that the application will never go down. Rolling update is the default deployment strategy while creating the deployment.

In the above picture, we can observe that one pod is getting down, and one pod is created so that users will not feel any downtime and they can access the contents of the application smoothly.

We can update our application in many ways like

• Updating the application version by updating the version of the docker container used.

• Updating the labels.

• Updating the number of replicas etc.

we can modify these from the manifest file that is used to create the deployment and then use the apply command on this manifest file so that the changes can be applied.

How to create a rollout

> kubectl apply -f deployment-manifest.yaml

How to check the difference between the recreate & rolling update strategy through the terminal also.

> kubectl describe deployment deployment-manifest.yaml

How to check the replica sets

> kubectl get replicasets

How to get back the previous version of the application - Rollback

> kubectl rollout undo app/myapp-deployment

This command will down the newer (v1.1) pods of the replica set -2 and brings up the older pods (v1.0) up of the replica set -1.

Thank you so much for taking your valuable time for reading.

I have tried my level best to explain as much information as possible in the easiest manner. Any feedback for further improvement will be highly appreciated! WeMakeDevs

We can connect at Rahul Kumar Verma | LinkedIn Rahul Kumar Verma (@RahulKu28171925) / Twitter