30

From Kubernetes documentation:

The selector field defines how the Deployment finds which Pods to manage.

But, when creating deployment, I already specify the pod template as part of the deployment. So, why will I need the selectors as well?

Is it supposed to be used like services, where pods are already being started separately, but later brought under the umbrella of Deployment to be managed together?

2 Answers 2

18

Answer for this question we can find in section Deployments from kubernetes.io

So, why will I need the selectors as well?

Quotes below from documentation for k8s v 1.14

.spec.selector is an required field that specifies a label selector for the Pods targeted by this deployment.

.spec.selector must match .spec.template.metadata.labels, or it will be rejected by the API.

In API version apps/v1, .spec.selector and .metadata.labels do not default to .spec.template.metadata.labels if not set. So they must be set explicitly. Also note that .spec.selector is immutable after creation of the Deployment in apps/v1.

A Deployment may terminate Pods whose labels match the selector if their template is different from .spec.template or if the total number of such Pods exceeds .spec.replicas. It brings up new Pods with .spec.template if the number of Pods is less than the desired number.

Pods are already being started separately, but later brought under the umbrella of Deployment to be managed together?

Simply speaking, No

Note: You should not create other pods whose labels match this selector, either directly, by creating another Deployment, or by creating another controller such as a ReplicaSet or a ReplicationController. If you do so, the first Deployment thinks that it created these other pods. Kubernetes does not stop you from doing this. If you have multiple controllers that have overlapping selectors, the controllers will fight with each other and won’t behave correctly.

6
  • 6
    So what is it used for? It seems like you should always make the selector match the labels of the spec… Is there some case where it is useful not to do so? Aug 28, 2018 at 10:11
  • 5
    Doesn't really answer the question Why? - Why matchLabels exist and must match .spec.template.metadata.labels? What's the point of it, as spec is anyway defined below Deployment so it's clear what Pods are started for the Deployment.
    – Ivan
    Jan 15, 2019 at 20:07
  • 2
    Anyone who bumps into this discussion should check the latest documentation. For example, currently, .spec.selector is not an optional field. It is a required field. kubernetes.io/docs/concepts/workloads/controllers/deployment
    – honor
    Jun 10, 2019 at 11:34
  • Thanks a lot for your comment. I think that in new documentation authors have corrected optional to required, because in old docs this field was told as optional but on next line authors added that this field must be set explicitly:) So effectively this field also was required Jun 10, 2019 at 12:06
  • 7
    Yeah it still does not make any sense. If they must "match exactly spec.template.metadata.labels" then it makes absolutely no sense to have to define them at all. Since it's self-explanatory that they're at least equal to one another. So the question remains, what's the actual point of having to write them at all, if there's a requirement of them having to be equal with something else exactly? Why not default the behavior of having them equal to the template labels and have the user to define them explicitely? This is just bad UX/UI
    – Eksapsy
    Mar 22, 2020 at 13:53
1

while spec.template.metadata.labels can have extra labels which you can annotate the pod with , the selector section need to pin few of them so it know which pods are under its governance

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.