And now another benefit that we get from using a deployment object is the benefit of rolling updates.
The rolling updates are really important because they eliminate downtime between application upgrades.
So let's assume our applications are currently running version one.
And we want to upgrade our applications to version two.
Now what our deployment object.
Simply eliminate all of the old pod replicas and then create new pod replicas.
That wouldn't be very ideal, because after destroying all of the old pods, the time that elapses in
which the new pods are still being created, our clients don't have access to any of our apps, so we
call this downtime.
And the purpose of rolling updates is to eliminate downtime, and it does that by gradually removing
old pods and gradually adding new pods, ensuring that while the new pods are being created, the old
pods are still ready to serve traffic.
Um, this rolling update, we get that automatically.
Okay, we get it out of the box with the deployment controller is going to do when we update the pod
template is it's going to preserve the replica set where each pod is running version one of my app,
and it's going to create a new replica set where the pods will be running version two of my app.
It's going to gradually scale down the first replica set to zero pods, and gradually scale up the new
replica set to three pods.
The replica set controller will respond in kind by gradually removing old pods and gradually adding
new ones, therefore eliminating downtime and ensuring that clients always have access to some version
of my application.
Now I want to show you the benefit of rolling updates.
So let's go ahead and, um, can't duplicate.
Huh?
Oh, I can copy this folder and paste it.
And I'm going to call it section five.
All right.
And now what I'm going to do is.
So I've got two versions of the great submission API.
The stateless version and the stateful version.
And what I'm going to do is update my pods to run the stateful version of my great submission API application.
And I'm going to show you how gradual this update is, how it essentially rolls the update from using
old pods, from using old versions of my app to new ones.
So I'm going to reapply.
Well, we'll CD out of section four CD into section five.
I'm going to say kubectl apply Life.
I can reapply the grade submission API deployment dot YAML.
Kubectl get pods dash n grade submission.
I'm not fast enough.
Uh, notice how it's creating a new pod?
Terminating old pods, essentially gradually upgrading our application so it didn't just delete all
of the old pods.
It in this case, what it did is it created two new pods and then it deleted the old ones.
This is actually ideal because it didn't remove any old pods in this case until it ensured that the
new pods were running first.
So the rolling update will always be different depending on the situation.
But it's not just going to destroy old pods and then create new ones.
You're always going to have some apps running ready to serve requests, okay?
And we're good.
Now we've got two pods running the stateful version of my application.
And if I were to test this out, localhost 3200.
Submit a grade for Harry.
We'll give him a 99 and Quidditch submit that.
And oh no, the new API isn't working.
Ah, what are we going to do now?
Well, thankfully, Kubernetes or the deployment controller, in this case, it doesn't just forget
about the old set of pods.
It keeps them all right.
Because that way, if the new version of our application doesn't end up working, we can roll back to
using the old version of our app.
So if we want to roll back, a new replica set is created that runs the same version that the first
replica set of pods had.
It's going to be scaled up to three pods and the replica set of pods whose version didn't work.
It's going to be scaled back down to zero pods.
So essentially.
So we essentially roll the update back.
Okay.
Um, so I can simply say cube CTL rollout undo deployment.
And the deployment is called great submission API and great submission.
And it's been rolled back.
Beautiful.
Kubectl get pods dash n great submission.
Once again the update is going to be gradual.
It's going to gradually run new ones.
All right.
Now let's try it out to make sure that we're using the old version of our app.
Harry 99 potions.
We are golden
All right.
Now you can actually control the rolling update strategy.
You can control how the update happens under spec where we specify the behavior of a deployment object.
We can specify how the rolling strategy will happen.
So the strategy we're going to modify is of type rolling update under rolling update, what I can do
is specify the maximum number of pods that can be unavailable at a time and set that to 50%.
So this basically means that the maximum number of pods that can be unavailable during the update is
50% of our desired pod replica count.
Okay, so we have to have at least one running pod throughout our update.
Another thing we can modify is the max surge.
We can set that to something like one.
Max surge is the maximum number of pods that can be scheduled above the desired number of pods.
So you'll remember before that, while the update was happening, it created two new pods running the
updated version on top of the old pods.
So essentially we had four pod replicas and then it started deleting the old pods.
Okay, well this ensures that we only have one additional pod above the desired number of pods.
So we essentially ensure that we do not have more than three pod replicas running at a time.
In this case, the reason you'd want to set a max surge is just in case you don't have enough resources
to have all the pods running at once.
So you say, you know what?
Once we reach three pods, start deleting old pods before adding new ones.
Okay.
And we I'm pretty sure we rolled back to using the stateless app.
So if we reapply this deployment.
We should get a rolling update.
Kubectl get pods and great submission.
And we don't really see anything interesting, but we're not really breaking any of the rules we specified
in the rolling update strategy.
All of the pods are 100% available, so we satisfy the following.
And we don't have more than three pods running at a time.
We've got the two pods running here.
I'm guessing one of them was terminated while we were still writing this command, and now both of them
are being terminated.
Anyways, rolling updates simply ensure that there that downtime is eliminated between application upgrades.
There's always one version of your app running at a time.
Okay, now I want to mention that the default strategy, the default rolling update strategy for a deployment
is fine, but I'll just leave it here for reference and I'll see you in the next section.