- [Instructor] In this section
we are going to perform an application upgrade,
and we're going to upgrade our deployment
from one version to another, and later on
we're also going to do a rollback.
So let's take a look at the deployment
that we are going to initially push.
Vi helloworld-black.yaml.
Basically, this is similar to the hello world applications
we've been deploying so far,
but the image name here is helloworld black,
and we also have the service associated with this,
and we're going to call this the navbar-service
and the navbar-deployment.
So we're going to do a kubectl create -f
helloworld-black, and I'm going to add
this --record, which basically means
that we're going to try and record
our rollout history, and that's something
I'll talk about in a little bit later.
This creates our regular deployment, our service,
and to see this up and running in our web browser
we can type minikube service navbar.
We've exposed it as a node port
so minikube can open this navbar service
in the web browser.
This looks very similar to what we've seen before.
We're going to take the navbar
and change the color a bit
in a different deployment.
We've already deployed this application,
and we have a black colored navbar
behind the scenes.
We want to update this to a blue navbar,
and in order to do that I already have an image
called helloworld blue,
and I'm going to update that image
by doing a kubectl
set image
deployment.
We've called this the navbar-deployment.
And I'm going to change this to helloworld.
Well, apparently I can't type,
so I'm going to go and actually type this correctly.
Deployment, and we see
that the image has been updated.
Let's take a look at our deployments.
See a desired three, current four, available three.
If you go back to our UI and refresh our UI,
there we have it.
We've gone from a regular gray background
to now what seems to be more of a blue
slash purple background.
So what actually happened here?
Let's take a look at our replica sets real quick.
Kubectl get rs.
We notice that we have multiple replica sets here
both associated with the navbar-deployment,
however, they have two different GUIDs
associated with them.
We notice that this replica set
has a desired, current, and ready status,
or ready values of three.
and if you look at our pods
we'll also have three different pods running for this.
Now let's take a look once again
at our deployment.
Ctl.
Once again we have three, three, three, and three.
Basically, behind the scenes,
what's happened in this scenario
is our deployment,
when we do a deployed
with a new image, we got a new replica set
that matches the second set of images
that we had, and we had pods rerolled for that.
If we take a look at our rollout history,
kubectl rollout history,
for the actual deployment,
which was navbar,
we'll notice that we have two revisions here.
First, when we actually created it,
and this is our kubectl command that we created
with a record of true.
The second revision, which is what we set the image to,
we had navbar deployment,
and then we set the image to helloworld blue.
The reason we initially added
the record equals true
is to see the actual cause changes
that we see in this list.
And that's how we do an in place upgrade.
Now what if we wanted to rollback
to the first version?
That we can do with this specific command.
Just like we did a rollout, we can do a rollout undo.
Kubectl rollout undo,
the deployment name,
navbar-deployment,
and this will revert our changes
back from two to one.
So if you look back at our site, there we go.
We are back to our first version.
A lot of times in this scenario
you might want to actually go back
to a specific version, and to that
you can rollout undo
and then you can add a --to-revision
and add whatever version number
you want over here that you saw on the list.