So we now get started with the basics
of Kubernetes and of interacting
with our Kubernetes cluster.
We learned how to create a deployment
with the create deployment command.
We of course, also learned how to update the image
of deployment with the set image command.
And we saw a couple of other commands
like the expose command as well.
But there's one potential problem with all these commands.
For one, you of course have to memorize them.
But that's not too difficult,
since you'll use the same set of commands all the time.
But you also have to repeat them all the time.
It's a little bit like earlier in the course,
where we always execute a docker run.
And if we had a project with multiple containers in it,
we had to run docker run quite a lot.
That was when we learned about docker-compose,
which all of a sudden allowed us to write down
how containers should be built and started
in a compose yaml file, and docker-compose up
which then pick up that file and apply these instructions
and build and start multiple containers at once.
And therefore docker-compose could even be helpful
if we just work with one container, because we can put all
the run configuration into a file, and we don't have
to type long docker run commands all the time.
Now, that was earlier in the course,
now we have kind of a similar problem with kubectl.
Instead of writing all these commands manually,
it would be nice if we could write down our deployment
and Service Configuration into a file.
And we could then just apply that file to our cluster
to then create a new deployment based
on the configuration in the file, for example.
And Kubernetes supports that.
Kubernetes allows us to create
so called resource definition files,
which looks something like this.
And this is just one example of course.
We can write down configuration options in a yaml file,
and do that for different kinds
of objects Kubernetes understands.
For example, here on this slide for the deployment object
to define how a deployment should be performed,
which containers should be launched in this deployment,
how many instances of our pods we want, and so on.
And this is an alternative
to the imperative approach we saw before.
With the imperative approach,
we always ran these kubectl commands,
and we had to execute these individual commands
to trigger different actions on our Kubernetes cluster.
This is comparable to using only docker run,
as I mentioned a second ago.
Now with the declarative approach, it's different.
There, we will run another command,
which we haven't seen thus far, the apply command,
and will simply point at a yaml file,
which contains our configuration,
which we want apply to the cluster.
And that configuration could contain information
about a deployment.
And this conflict file is then used
to define our desired target state.
And whenever we apply it,
Kubernetes will use that target state
and do whatever it takes to make that the current state.
And if we then for example, change a configuration file
and reapply it, Kubernetes will have a look at what changed
and make the appropriate changes on our running cluster
and the running application there.
And therefore data is comparable
to Docker Compose in a certain sense,
because now we can use our configuration files
and we don't have to run a bunch of individual commands.
So let's see this in action now.