Hello, and welcome to this lecture.
In this lecture, we will talk about updates
and rollbacks in a deployment.
Before we look at how we upgrade our application,
let's try to understand
rollouts and versioning 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 roll back 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 'kubectr rollout history' command,
followed by the deployment name,
and this will show you the revisions
and history of our deployment.
There are two types of deployment strategies.
Say for example, you have five 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 five running instances,
and then deploy five 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.
The second strategy is where 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.
Remember, if you do not specify a strategy
while creating the deployment,
it will assume it to be Rolling Update.
In other words,
Rolling Update is the default deployment strategy.
We talked about upgrades.
How exactly do you update your deployment?
When I say update, it could be different things,
such as updating your application version
by updating the version of Docker containers used,
updating their labels,
or updating the number of replicas, et cetera.
Since we already have a deployment definition file,
it is easy for us to modify this file.
Once we make the necessary changes,
we run the 'kubectl apply' command to apply the changes.
A new rollout is triggered,
and a new revision of the deployment is created.
But there is another way to do the same thing.
You could use the 'kubectl set image' command,
to update the image of your application.
Remember, doing it this way will result in the deployment
definition file having a different configuration,
so you must be careful
when using the same definition file to make changes in the future.
The difference between the Recreate and RollingUpdate strategies can also
be seen when you view the deployments in detail.
Run the 'kubectl describe deployment' command to see
the detailed information regarding the deployments.
You will notice when the Recreate strategy was used,
the events indicate that
the old replica set was scaled down to zero first,
and then the new replica set scaled up to five.
However, when the RollingUpdate strategy was used,
the old replica set was scaled down one at a time,
simultaneously scaling up the new replica set one at a time.
Let's look at how a deployment performs an upgrade under the hood.
When a new deployment is created,
say to deploy five replicas,
it first creates a Replica Set automatically,
which in turn creates the number of pods required
to meet the number of replicas.
When you upgrade your application,
as we saw in the previous slide,
the Kubernetes deployment object creates a new Replica Set
under the hood and starts deploying the containers there,
at the same time taking down
the pods in the old Replica Set, following a rolling update strategy.
This can be seen when you try to list the Replica Sets using
the 'kubectl get replicasets' command.
Here, we see the old Replica Set
with zero pods, and the new Replica Set
with five pods.
Say, for instance, once you upgrade your application,
you realize something isn't very right.
Something's wrong with the new version of 'build'
you used to upgrade,
so you would like to roll back your update.
Kubernetes deployments allow you to roll back to a previous revision.
To undo a change, run the 'kubectl rollout undo' command,
followed by the name of the deployment.
The deployment will then destroy the pods in the new Replica Set,
and bring the older ones up in the old Replica Set,
and your application is back to its older format.
When you compare the output
of the 'kubectl get replicasets' command,
before and after the rollback,
you will be able to notice this difference.
Before the rollback,
the first Replica Set had zero pods,
and new Replica Set had five pods,
and this is reversed after the rollback is finished.
To summarize the commands real quick,
use the 'kubectl create' command to create the deployment,
'get deployments' command
to list the deployments,
'apply' and 'set image' commands to update the deployments,
and 'rollout status' command to see the status of rollouts,
and 'rollout undo' command to roll back a deployment operation.