CODEWITHSUNDEEP
kubernetes
Tobias
Tobias

Reputation: 465

service selector vs deployment selector matchlabels

I understand that services use a selector to identify which pods to route traffic to by thier labels.

apiVersion: v1
kind: Service
metadata:
  name: svc
spec:
  ports:
  - name: tcp
    protocol: TCP
    port: 443
    targetPort: 443
  selector:
    app: nginx

Thats all well and good.

Now what is the difference between this selector and the one of the spec.selector from the deployment. I understand that it is used so that the deployment can match and manage its pods.

I dont understand however why i need the extra matchLabels declaration and cant just do it like in the service. Whats the use of this semantically?

apiVersion: apps/v1 
kind: Deployment
metadata:
  name: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 1 
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx

Thanks in advance

Upvotes: 32

Views: 14499

Answers (3)

tpaz1
tpaz1

Reputation: 333

In the Service's spec.selector, you can identify which pods to route traffic to only by their labels.

On the other hand, in the Deployment's spec.selector you have two options to decide on which node the pods will be scheduled on, which are: matchExpressions, matchLabels.

Upvotes: 20

ton
ton

Reputation: 4577

why i need the extra matchLabels declaration and cant just do it like in the service. Whats the use of this semantically?

Because service spec only support equality-based selectors and the deployment is a newer resource that supports two syntax (equality-based and set-based).

The API currently supports two types of selectors: equality-based and set-based. A label selector can be made of multiple requirements which are comma-separated. In the case of multiple requirements, all must be satisfied so the comma separator acts as a logical AND (&&) operator. Reference

The Service spec uses just the "equality-based" label selector syntax.

Newer resources, such as Job, Deployment, ReplicaSet, and DaemonSet, support set-based requirements... Reference

My understanding is that earlier the only supported syntax was the equality-based one, like we have on the service spec, and that now, when the resource you are using supports the new syntax, you are required to use matchLabels or matchExpressions.

Upvotes: 10

Jonas
Jonas

Reputation: 128827

How Deployment uses spec.selector

When a Deployment is changed, a new ReplicaSet is created. The ReplicaSet is responsible to manage the Pods. It uses the spec.selector to know what Pods it should manage.

Example:

If the replicas: 1 is changed in the Deployment to e.g. replicas: 2 a new ReplicaSet is created, and it observes the Pods using spec.selector to match Pods with matching labels. It only see 1 replica initially, but its desired state is now replicas: 2 so it is responsible for creating additionally one Pod from the template in the Deployment.

Selector syntax

There is two ways to declare the labels under the spec.selector in `Deployment.

  • matchLabels - you declare the labels
  • matchExpressions - you write an expression for labels

See kubectl explain deployment.spec.selector for full explanation of spec.selector alternatives.

Labels and Selectors

Labels and Selectors is a generic concept in Kubernetes and is used in multiple places. Another example is how you can filter what resources you want to see or use with kubectl. E.g. you can select the Pods for an app with:

kubectl get pod -l=app=myappname

(if your Pods is labelled with app: myappname.

Upvotes: 14

Related Questions