For the spec, the specification
of this object, we again have a nested key.
So we indent
below spec here,
and we then add a couple of pieces of information
about this deployment.
For example, the number of pod instances
we wanna have as a default.
Now, if you don't add any information
the default is one,
but you can also manually set it
by adding the replicas key here,
and give that a value of one, or two, or three, or even zero
if you initially don't want any pods to be launched.
I'll set it to one, but you could also set it to three
to start with three running pods,
three equal pods containing the same container,
right from the start.
Which of course could make sense for certain applications.
If you know that for the traffic which you expect
to arrive you will need three pods anyways,
you of course don't have to scale them after you created
the deployment, you can simply start with three.
But here we'll start with one, because of course,
for our local development, this will suffice.
Now as our next step, you need to add a template.
Here You will define the pods that should be created
as part of this deployment.
And that's of course, super important.
With the imperative approach, create deployment first app,
we added "dash dash image" to define
which image should be used for the container used
in the pod attached to this deployment.
Now we'll do kind of the same here.
Now with the template we define the pod
which should be created and therefor nested below template,
we now also, again, add "metadata"
because a pod is a new object in the Kubernetes World.
Deployment is an object, a pod is another object,
and therefore, we need new metadata here
for this new object.
To, for example, give it a name if you want to,
but in this case, we want to add a label
and we do this with the labels key.
I'll come back to why we need a label in a second.
For the moment, let's add it and nested below that,
you can give it any label you want.
And here both the key as well as the "value" value,
are up to you.
So here I'll name this app, "second dash app",
but you could have also named this here, "deployment"
or "depl"
or... "tier"
whatever you want.
I'll add a label named "app" and give it a value
of second app.
And again I will come back to
why labels are important metadata for some objects,
in a second.
Now, as a side note, you don't need to add the kind here
because the template of a deployment always describes a pod.
So this always is a pod object,
and that's why we don't need to add this pod kind here.
Indeed, if you have a look at the reference documentation,
here in the deployment spec, and then there
on the template,
you see, this is always a pod template spec
and therefor here, you see, you only can add two pieces
of data, and that's the metadata and
then the specification of the pod.
And you can't even add a kind here because it's not expected
by Kubernetes because this always has to be a pod.
So we added the metadata, but as we just saw the other thing
which we have to add for this pod template is
the specification for how this pod should look like.
We did add a specification before, this one,
but that was the specification for the overall deployment.
Now we add another spec on the same level
as metadata inside of the template,
so indented below template and here we now define
how this pod should be configured.
So this spec is the configuration of the deployment,
which basically sets up which pod we want and how many pods.
Now we have to specification of the individual pods
which are created for this deployment.
And here it's one type of pod per deployment.
So you can have multiple pods if you increase the replicas
but it's always the same pods then
with the same containers inside of it.
If you want different pods with different containers,
you need different deployments.
And we'll see that in action later as well.
So here in this specification for the pod,
we now basically need one important key
and that's the containers key.
And again, you can always look this up
in the official documentation.
If we have a look at the pod spec,
we see that there's a lot we can configure,
many things which you will rarely need,
and basically nothing we need right now.
But we do need this containers key here
which allows us to define the containers
or the single container, which should be part of this pod.
Now we'll have a look at some of the other options later.
For the moment, let's just add containers
and there, we now have a list of containers,
which means we need dashes.
Without a dash it's just a nested key below another key.
Now here, we can have multiple containers in the same pod,
so you can have multiple containers to find
with multiple dashes here, with multiple list items.
And every container then can have a name,
which is up to you.
I will name it,
"second node".
Not because it's on the second worker node
or anything like that, but because it's a Node.js app
and it's our second app and the container
for this second app.
The name is up to you, of course.
Very important is another key which you now don't add
with a dash because it's still for the same container,
just in a new line.
And that's the image which you want to use here.
And of course, that's the image you would have specified
with "dash dash image" here
when creating a deployment imperatively.
There, as a side note, you could have also
added multiple images by separating them
with commas to create multiple containers.
Here in the declarative approach, as mentioned before,
you could add multiple containers like this
by adding multiple dashes.
Not something we need to do here though,
so I'll comment this out.
Here the image I want to use, of course,
is the first...
app image I deployed before.
So the "kub dash first app" image.
And it needs to be an image on a registry,
so that's why I'm using my registry account name here
slash and then the image name.
So overall the repository name on that image.
And you can, of course, also specify a tag here
like that latest version we deployed
in one of the last lectures.
And that's it, that's the bare minimum configuration
we need here to create a deployment,
which will create one pod with that one container
inside of it.
That of course leaves only one question.
How can we now apply that deployment?
How can we now make the cluster aware of it
and have it create that deployment and pod
and launch that container?
Well for that, we use the command line
and we still use the kube control command here
because that is our communication device
with the master node.
But now we don't call, create something, but instead, apply.
That's another command built
into this kube control command tool here,
and it's simply applies a configuration file
to the connected cluster.
You identify the file with the dash F...
option here
and you can have multiple dash F options,
if you wanna apply multiple files at once.
Here, it's only one file though.
And then you simply add an equal sign and then the file name
or the path to the file, which should be applied.
So in this case kube control applied
dash F equals deployment dot yaml.
And if we now hit enter, it tries to apply this.
But you see, I get an error.
I'm getting a missing required field "selector" here.
And I did this on purpose because selectors are
a key concept in the Kubernetes world,
especially when using the declarative approach.