CKA & CKAD Series (Part 4): Deployment & roll out
Tags: kubernetes
Published: 2022-07-30 14:13:00


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

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/v4airtw4m6nhhohtf08q.png)
 
**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. 

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/17c4eott2gewmp2jrrwq.png)
 
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. 
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/nh5ed7kab5zpng2tprh8.png)
 

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.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4xqed7ag6z5ji41a7iwf.png)

When you create a deployment, automatically a replcaset is created and automatically the replicaset creates pods.
Lets create a deployment:
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zis8almu6o2n9znds2ru.png)

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 <yaml file>"

```
kubectl create -f deployment.yaml
```
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hsn6fy8lusgkkakhjz28.png)
Lets check the deployments

```
kubectl get deployments
```
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2z9tl9aikbju72n21i0j.png)

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

```
kubectl get pods
```
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2aica75jf1qamwpdibfz.png)

lets check more informations

```
kubectl describe deployment myapp-deployment
```
myapp-deployment is the deployment name. 
 
 ![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/bm3ia480rob892c1j5hp.png)

Now use this command 

```
kubectl get all
```

Other than the service, all of the things are related to the deployment
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/x4dhbwy60rp7u5nnp43k.png)
 

**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. 
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/c70drhxf4zcvrd8pnw0v.png)
 

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.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/cq52cfqfkkgjcmu87c5x.png)
 
This strategy is known as the **Recreate strategy**, and thankfully this is NOT the default deployment strategy


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/q0sfn96xg5kjfxg55un8.png)
 
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/30kmg8gu23j68xc2z02d.png)
 
2. 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.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/tgekopwgswa8fdmwxqvs.png)
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1nofohmie5ws4zx0du73.png)
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/nbu068ueaz7ygtvamoiv.png)
  
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.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xzgm9hpmgjxm19u2zyd1.png)

Commands:
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ks7cc0tn9pair79o1uhu.png)


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
```
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/95424ew67m679wsyfn1l.png)

Lets update our replicas to 6

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/or6fipjzs7beuz8569w0.png)
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1kit6q9zbco0p1qux9si.png)
Lets create the deployment

```
kubectl create -f deployment.yaml
```

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/pi0lo5ol98t0rxqdiqmh.png)
You can now check the status of deployment by watching the 6replcas (pods) getting created live :

```
kubectl get pods -w
```
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ew6wjzhq63yp1kg3wk74.png)
 

Lets use the rollout status command to see status:  

```
kubectl  rollout status deployment.apps/myapp-deployment 
```
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/66afof76nl8g1i9latka.png)
 
 
Did you realize what happened?
I guess no.Let's delete the deployment and create it fast . Then check the rollout status.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/lxgmix9pf0lyewysufvp.png)

Lets check the history of the deployment

```
kubectl  rollout history deployment.apps/myapp-deployment 
```
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ekanpabq5ojt1ywqjfcv.png)
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.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/s06z6si43rwh2yp2bcky.png)
 
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
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/epqdugnzot76hfb89bnd.png)
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
```
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8gzb3j1z8qia62esggai.png)


Lets change the image of the replicas (pods) :

```
kubectl edit deployment myapp-deployment --record
```

we are using --record to record whatever we are doing...
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4sitobvimw8e920t0bxy.png)

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. 
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3pfcz25wxuu5x16pxewm.png)
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/lj7g6nso9l6d5deldq1z.png)
 
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.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mm4ln8hwmi5vhmy4zo0c.png)
 
If you type this command within a very short time, 

```
kubectl  rollout status deployment.apps/myapp-deployment 
```
you may see something like this;

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3wfr1k661f6l5gvg9egq.png)
 
 Now check the pods or replicas;
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0avl8328fyuci7den0cc.png)

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

```
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/elflx3ypvdg7atczhdad.png)
You can see the image has been changed to nginx:1.22 and events . Also it is revision 2 now.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vk1svyzwgeft2xek7wsp.png)


Lets change the image to nginx:1.22-perl again. You may use 
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/abenrat8687i3vic2z3v.png)
 
```
kubectl edit deployment myapp-deployment --record
```
or,


"kubectl set image deployment <deployment name> <contaner name= image >"


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

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ltj7epres2h0a6l8wq42.png)

You can now check the rollout status
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/as88f0gdd08wbj520v14.png)
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
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xq9s9pg1t77rrx8cja6p.png)
 
Wait, a second. We now have 3 revisions (revision 1,3,4). Where is revision 2,Right?

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jyb927xouuq85smiuyq6.png)
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
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5k8trk5m5z1rchr30srn.png)

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!


<img src="https://media0.giphy.com/media/Nfs5y1kzJKfu/giphy.gif?cid=ecf05e472d3w835ptrri5m1p6ifnwl9mi7ope9pifvhpcxf6&rid=giphy.gif&ct=g">