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
- 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
- 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!
Top comments (1)
Very nice collection of information on CKA preparation. I also created a dedicated course on Udemy for CKA exam and more than 1k+ people get benefited
My CKA Course