In the last section we spoke about how we're going to update an existing object.
We're going to take that existing conflict file.
Leave the name and kind the same and we can make any other change we want to to the file and throw that
back in the cubes DTL.
And our expectation is that we are going to update an existing object as opposed to creating a new one.
So let's flip on over to our config file.
Remember our goal right now is to update the existing pod to use the multi worker image instead of the
multi client.
Now a quick note here.
Remember that the multi worker image really expects to have a copy of red S available and so it's entirely
possible that when we do this update something is going to crash.
Or I should say the container that gets created might crash because there is no copy of read is available.
Nonetheless I just want to make sure that we have the ability to update the image that is being used.
I'm not really concerned about getting a pod successfully running.
I just want to update the image right now.
That's all.
All right so we're going to open up our code editor.
We're going to fund the client pod File.
We're going to leave the kind of the same and the name identical as well.
The only thing we're going to update inside of here is the image that we are using.
So instead of using multi client I'm going to use multi worker instead we'll leave everything else inside
of your identical.
I'm not going to change the port even though multi worker doesn't really expose anything on port three
thousand or anything like that.
Again I just want to update the image and make sure that we are updating a pod in place and not creating
a new separate pot.
All right.
So I made the change to multi worker.
I'm going to save the file I'm going to flip back over to my terminal going to make sure I'm it's still
inside my simple Cade's directory and then I'm going to feed this updated configuration file back in
the cube Seitel by using that apply command remember apply is the magic command.
It's how we make any changes to our kin to the configuration of our Cabinet these cluster cells say
cube Seitel apply dush f Wyant dash pod.
YAML and now you'll notice that when we hit enter and we submit that command we do not see something
that says like oh I'm going to update or I'm going to see man going to create a new pod or anything
like that.
Instead it says very specifically client pod has been configured.
When you see the message configured it means that we've updated the configuration that is applied to
client Dasch pot.
So we should now be able to run that get Pod's command and verify that there is still one pod that exists
inside of our entire cluster.
So I'll do cube see T.L. get pods and you'll notice that we now have still just one pod that's the name
of client pod.
There's one copy it's running.
There's two restarts currently because we just caused this thing to be restarted when we updated the
image that it's running now.
The only thing that's kind of awkward right now is that we can't really inspect this pod and verify
that it is in fact running the updated image.
So I want to figure out some way that we can actually look at this very specific POD right here and
look at the different containers that are running inside there and verify that 100 percent.
No two ways about it.
Yes we are running the multi worker image.
So in order to inspect this very particular pod right here we're going to learn a new command on Kube
CTO Ir's the new command.
Not there not there are to go here you go.
So to get detailed information about an object inside of our cluster we're going to use the cube seat
T.L. describe command.
Describe this use to print out a ton of information about a very particular object.
So we'll say cube Seitel describe.
Then pass in an object type and then the name of the particular object that we want to investigate.
Now just as a quick curiosity here or something that's kind of interesting.
You can actually omit the object name if you want to.
If you do that you'll get detailed information about every different object type of the specify or seeing
every different object with the specified object type.
But it's a ton of information.
So in general we usually use the full command which has cubes detail describe the type and the name
to just get information about that one particular object.
So let's try that out right now.
Again we're going to run this command to verify that the client pod is in fact running that updated
image.
So I'll do cube Seitel describe our object type is Pod's so we could simply say pod either one is fine
pods or pod and it'll put in the name of that very particular object which is client dash pod.
So it's going to print out a ton of very detailed information about that very particular part down at
the very bottom you're going to see a series of events right here very frequently.
This is going to be some of the most interesting information this is going to be events that are not
logs coming out of the containers but events that have occurred over the life cycle of the pot.
So you'll see messages about things that have crashed or pulling new images or changing images or stuff
like that.
Now if we scroll up a little bit higher there is a ton of information in here that's kind of outside
the scope of what we want to talk about right now.
But if you scroll up scroll up scroll up you will see containers.
We have a container with a name of clients recall that client name right there was provided inside of
our configuration file.
So there is name client right there and then we're told that the client container member that's the
name of the container.
This is kind of misleading because we have this these kind of conflicting names all over the place.
But essentially the image is the multi worker image.
That's exactly what we just updated our configuration file to use.
So without a doubt updating that configuration file and leaving the name and the kind identical found
an existing object that was already running inside of our cluster and it updated it in place as opposed
to trying to create a completely separate pod.
All right so that's it.
That's a quick example of this entire idea of declarative vs. imperative deployments.
So we like to use declarative as much as possible.
And the formula formula for doing a declarative update is always going to be the same thing over and
over.
We're going to go find our original config file.
We're going to make a change to it leaving the type or kind and the name the same what date some configuration
side the file and then we're going to throw it back into cube CTO and our master is just going to kind
of make the change for us and we don't have to worry about manually printing out a list of running pods
and issuing a command to update a very specific POD or anything like that.
We're going to see this declarative approach throughout this entire course just nonstop.
It's going to be all we're doing throughout the entire course.
Update the config file.
Throw it in the queue DTL verify that in fact everything works correctly.
OK so that's a good example.
Take a quick pause right here and we'll continue in the next section.