So where's this error coming from?
What's this missing selector thing?
Well, we fix it by going to the specification
of our deployment
so not the specification of the pod
but the specification of the deployment.
And besides specifying the number of replicas
and our pods template here,
we also must add a selector key here.
And on this selector key nested below it
we can add a match labels key,
and then nested below that
a key/value pair of the pod labels
we wanna match with this deployment.
Okay, that sounds very triptych.
What does this mean?
Well,
we got a template here for this deployment
and therefore it should be obvious
which pods are created by this deployment.
And it kind of is.
The pod defined in this template will be created
when this deployment is applied.
But deployments are dynamic objects or dynamic things
in the Kubernetes world.
For example,
if you scale up the number of pods
after a deployment has been created,
these new pods which are created
will still automatically be managed
by the already existing deployment.
So a deployment continuously watches all the pods
which are out there
and sees if there are any pods it should control.
And it selects the to be controlled pods
with a so-called selector.
And you will see selectors
on pretty much all resources Kubernetes works with.
For example, Azure Services.
Now there are different types of selectors
here for a deployment
we can use two different kinds of selecting.
We can match labels and we can match expressions.
Now expressions are more complex selectors
so we'll not have a look at them right now
instead we'll match labels.
And then nested below that you simply have key/value pairs
of labels on the pods which should be controlled
by that deployment.
So in this case, we are trading these pots
which have this label on it.
And by the way,
they could have multiple labels.
Which as mentioned before are totally up to you.
Both the key and the value are up to you.
But you can have one or more labels
on a given object in this case on a pod.
And then you can connect that to another object
in this case,
to the deployment with a so-called selector
so that this deployment knows which pods
which are out there running in the cluster
should be controlled by it.
And you then simply add the key/value pairs of the pods
that should be controlled below match labels here.
So for example like this,
now I would tell this deployment
that all the pods which have a label of app
with a value of second app,
and which have a label with a name of tier
with a value of backend,
should be controlled by this deployment.
Other pods which only have app,
second app,
but not this tier
or which have a different app label
or which don't have the app and tier label at all
will not be controlled by this deployment.
I hope this makes sense.
It tells the deployment
which pods belong to it so to say.
And we'll see this again, when we later work on a service.
So for the moment let's save this updated file
and let's now try applying this file again.
And this now looks better.
Now, you'll see
this deployment was created.
And therefore,
if you run,
get deployments here,
you see that deployment up and running.
And of course, if we now call get pods,
we also see this up and running,
but now we didn't have to enter a command
in the command line
except for the apply command of course.
But instead,
all our configuration is encoded here in this conflict file.
Now at the moment we can't visit the app
because a services missing
but this is a huge step forward
since we now know about this declarative approach.
Let's now see how we can also declare a service resource.