CKA & CKAD Series (Part 4): Deployment & roll out

What is a rollout?
A rollout is the process of
gradually deploying or upgrading your application containers.

What happens in a deployment?

When you first create a deployment, it triggers a rollout. A new rollout creates a new Deployment revision. Let’s call it revision 1.

In the future when the application is upgraded – meaning when the container version is updated to a new one – a new rollout is triggered and a new deployment revision is created named Revision 2.

This helps us keep track of the
changes made to our deployment and enables us to rollback to a previous version of deployment if necessary.

You can see the status of your rollout by running the command: kubectl rollout status followed by the name of the deployment.
To see the revisions and history of rollout run the command kubectl rollout history followed by the deployment name and this will show you the revisions.

When you create a deployment, automatically a replcaset is created and automatically the replicaset creates pods.
Lets create a deployment:

here we have just changed the kind to Deployment. Other than this, most of the things are same as replicaset.
We have given the file name as deployment.yaml.

Lets create a deployment:
"kubectl create -f "

kubectl create -f deployment.yaml

Lets check the deployments

kubectl get deployments

It shows we have 1 deployment and 3 out of 3 ready pods.
check the pods

kubectl get pods

lets check more informations

kubectl describe deployment myapp-deployment

myapp-deployment is the deployment name.

Now use this command

kubectl get all

Other than the service, all of the things are related to the deployment

Deployment strategy

1. Way 1 (Recreate strategy): There are two types of deployment strategies. Say for example you have 5 replicas of your web application instance deployed. One way to upgrade these to a newer version is to destroy all of these and then create newer versions of application instances.

Meaning first, destroy the 5 running instances and then deploy 5 new instances of the new application version. The problem with this as you can imagine,
is that during the period after the older versions are down and before any newer version is up, the application is down and inaccessible to users.

This strategy is known as the Recreate strategy, and thankfully this is NOT the default deployment strategy

1. Way 2 (Rolling update by default): The second strategy is were we do not destroy all of them at once. Instead we take down the older version and bring up a newer version one by one. This way the application never goes down and the upgrade is seamless.

Note: if you do not specify a strategy while creating the deployment, it will assume it to be Rolling Update. In other words, RollingUpdate is the default Deployment Strategy.

Commands:

Lets do it practically:

Lets delete our deployment thus no pods exist and we will modify our deployment and then use rollout and others here.

kubectl delete deploy myapp-deployment

Lets update our replicas to 6

Lets create the deployment

kubectl create -f deployment.yaml

You can now check the status of deployment by watching the 6replcas (pods) getting created live :

kubectl get pods -w

Lets use the rollout status command to see status:

kubectl  rollout status deployment.apps/myapp-deployment 

Did you realize what happened?
I guess no.Let's delete the deployment and create it fast . Then check the rollout status.

Lets check the history of the deployment

kubectl  rollout history deployment.apps/myapp-deployment 

You can see that, we have just 1 revision. You can seethe Cause change None as we did not set anything to record while deployment.

Lets delete the deployment and set this time.

Lets create the deployment with --record command to record the Cause of change this time.

kubectl create -f deployment.yaml --record

Now, check the rollout status & history too

You can see the cause of change.

As we have used the --record command, it has recorded the command "kubectl create --filename=deployment.yaml --record=true"
You can check the deployment information properly:

kubectl describe deployment myapp-deployment

Lets change the image of the replicas (pods) :

kubectl edit deployment myapp-deployment --record

we are using --record to record whatever we are doing...

first press "i" to get into insert mode and then change the image to nginx:1.22 which is a stable version and older one.

Once we have updated the image, you can press "Esc" then ":wq!" to exit

Now the old pods (Which had nginx image) are terminated and new pods are created using image nginx:1.22.

If you type this command within a very short time,

kubectl  rollout status deployment.apps/myapp-deployment 

you may see something like this;

Now check the pods or replicas;

They are completely new made of ngnix:1.22 image

If you check the description of the deployment now, you can see something like this

kubectl describe deployment myapp-deployment

You can see the image has been changed to nginx:1.22 and events . Also it is revision 2 now.

Lets change the image to nginx:1.22-perl again. You may use

kubectl edit deployment myapp-deployment --record

or,

"kubectl set image deployment "

SO, in this case

kubectl set image deployment myapp-deployment nginx=nginx:1.22-perl

Remember for this yaml file , we did set container name as nginx and image was set to nginx:1.22 which we are changing to nginx:1.22-perl

You can now check the rollout status

You can see the old replicas to be terminated.

Now, you may check the history of rollouts:

kubectl  rollout history deployment.apps/myapp-deployment 

There are totally 3 revisions. for the 1st time, when we created the deployment, 1 rollout happened and 1 version was created .

Then we edited the image t nginx:1.22 and thus another rollout happened and new revision appeared. Again, when we changed the image to nginx:1.22-perl, another rollout happened and another revision was created.

Now, assume that your boss told you that the revision 3 was a bad decision. You should have been in revision 2, then what should you do? You can undo changes . Use this command:

kubectl rollout undo deployment.apps/myapp-deployment

This will undo revision 3 and take you back . This will create revision 4.
Thus new pods will be created which will have image nginx:1.22

Now check out he description of the deployment and you can see the image nginx:1.22

Wait, a second. We now have 3 revisions (revision 1,3,4). Where is revision 2,Right?

Because the revision 2 actually the revision 4.

Hey! Did you notice that we were just applying RollingUpdate strategy by now?

kubectl edit deployment myapp-deployment --record

You will find a section under spec defining strategy

If you need to change it to Recreate or any other, you can change it to "Recreate"
For example, for the Recreate strategy, you need to edit it to:

 strategy:
    type: Recreate

This will do.....

Done! Congratulations boss!