Now, to see this in action,
for the moment,
I will stick to this application we worked on thus far
in this course.
Just make sure that you've got no ongoing deployments
with kubectl get deployments
and you shouldn't see anything here.
If you do, use the kubectl delete deployment command
and then specify the name of the deployment to delete it.
Also, make sure you've got no pods,
which you shouldn't have if you have no deployments.
And you've got no services,
except for that default Kubernetes services,
which is fine.
Of course, also ensure that minikube is still up
and running but if it wouldn't be,
these commands I just showed you would have failed anyways.
And with that, let's now create a config file
for the deployment,
which we created in the command line before.
For this, I'll add a new file in this project
and I'll name it deployment.yaml.
The file name is totally up to you though.
The only thing that matters
is that it's a YAML file
but the file name is up to you.
Now, in this deployment.yaml file,
we now specify how our deployment should look like,
how it should work,
how it should be configured.
And there is a certain syntax you have to use
in these Kubernetes config files.
First of all, no matter which kind
of resource you are configuring,
if it's a deployment or a service,
whatever it is, you need to specify an apiVersion
by adding such an apiVersion key written like this.
Now, there are different apiVersions available
and like everything in the world,
Kubernetes, of course,
also is under active development.
To find out which apiVersion to use here,
my personal approach is that I dive into the docs
or that I simply google for Kubernetes deployment YAML
or something like this.
You could also search for service.yaml
if you would want to define a service
and then somewhere in the docs,
you will find an example snippet like this one
and you'll see the apiVersion here.
This is a quick way of finding out
what the currently latest apiVersion is.
Though, of course, you should keep in mind
that if you always use the latest version,
of course, some features might change over time.
Here, I can use the latest version though
and therefore, I set the apiVersion here
to apps/v1 for this deployment resource,
which I'm gonna create.
And that's the next important piece
of information we need here.
Just because we named the file deployment
does not mean that Kubernetes will treat it
as a file that creates a deployment
because we could have chosen any file name.
Instead, you have to let Kubernetes know
what you want to create
by adding a kind key here.
And that's super important.
Here you define the kind
of Kubernetes object you wanna create.
And here, we wanna create a Deployment
and of course, this value is not up to you.
There's only a certain set of possible values here,
like Service or Job, which we haven't used thus far.
But in this case, we need a Deployment.
And again, the official docs are a place
where you can learn about all possible resource types
and also very useful,
in the official docs,
at the very bottom here on the left, the reference.
If you dive into the latest API reference here,
you also find a full reference
of all supported objects and configurations
and for example, here, we can also dive
into the Deployment object.
Here we also see that it's apps v1 as a version.
And then here, you see what you can configure
in this YAML file.
For example, here you also see the kind configuration,
which here, of course, should be Deployment.
So that's the next thing we set.
Now, with that, we're telling Kubernetes
that we wanna create a new deployment object.
As a next step, you typically need
to add some metadata.
Now, this is not some random data you come up with
but instead, this includes crucial things like the name
of the object you're creating.
And keep in mind, we chose a name
in the imperative approach as well.
There we created a deployment like this
and we gave it a name like this.
And here, we're basically doing the same.
This deployment here is basically replaced
by setting a kind here.
And now we also need to give it a name
so that we can identify it later.
And we do this by adding the metadata key
and then nest it in there
and therefore, since it's YAML, indent it
because that is how you nest things
in a YAML document.
We set a name.
And now this name is totally up to you.
I will name is second-app-deployment
but this name again is up to you.
Now, there is more metadata, which you can add.
As you can see in the reference docs here
on metadata, if you click on this type definition.
It's not possible for all types
but for many it is.
And here you then see, if you scroll down below that list
of objects which support this type,
her you see what you can add.
There you see you can add a lot,
for example, the name, which we just added
but also, other things,
though I will say, many of these things don't need
to be added for the vast majority of objects.
And I will highlight some other things,
which you can add whenever we have an object
where it makes sense.
So with that, I'll go back to my deployment definition here
and just add the name here.
Okay, so now we tell Kubernetes
that we wanna create a deployment
and that it will have a name of second-app-deployment.
Now we need to add the so-called spec,
the specification of this deployment.
And that's the meat of this object
because here, we will define how this deployment
should be configured.
So here, all the interesting things are being added
and therefore, let's now dive into this.